E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Isabel Holdsworth
Date: Fri, Apr 13 2018 3:01AM
Subject: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
No previous message | No next message

Hi Birkir,

> Maybe that's already true in HTML 5.2, unfortunately my browser/screen
reader combos all crash when I try to load that page.

Yes, me too. Do you know of any other way we can get access to this
valuable info?

On 06/02/2018, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> ON your first example, my understanding is that there are plans to
> change the <address> definition so that it can be used more widely.
> Maybe that's already true in HTML 5.2, unfortunately my browser/screen
> reader combos all crash when I try to load that page.
> Here is the MdN article:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/address
>
> I think your reading of WCAG 1.3.1 is correct.
> If no information is communicated visually it doesn't have to be
> communicated programmatically.
> Accessibility is about equal access, if something is not marked up as
> a heading for anybody it's a usability issue, not an accessibility
> issue.
>
> You can still recommend to use the appropriate HtML for the job for
> other benefits, and you could try to argue that 4.1.1 applies to some
> degree, though I think that is an overly liberal interpretation.
> And 4.1.2 is the catch all accessibility SC that we can use when all else
> fails.
> I also agree with you that 2.4.6 is one of the weakest success
> criteria. I"m not even sure if an empty heading violates 2.4.6.
> I've not used it often and I've ended up in long discussions with
> other experts in situations where I have.
> I like the intension and with a stronger set of technique examples,
> e.g. creaing a failure techniques under 24.6 for an empty heading
> element, this could be <addressed>.
> heading as a fila b
>
> On 2/6/18, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>> To what degree is conveying information and relationships a required thing
>> under WCAG Success Criteria (SC) 1.3.1 Info and Relationships
>> <https://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-programmatic>
>> ?
>>
>> As a reminder, that SC reads, "Information, structure, and relationships
>> conveyed through presentation can be programmatically determined or are
>> available in text."
>>
>> A strict reading of the text of 1.3.1 seems to indicate that the issue is
>> not *whether* information and relationships are conveyed, but rather that
>> any information and relationships that are *conveyed through presentation*
>> are also conveyed semantically or with text. An example of something that
>> you might think violates 1.3.1 but that, if you just look at the plain
>> words in the SC, is *not* wrong is when the <address> tag is used to mark
>> up any old address, when, semantically, it should only used to define the
>> contact information for the author/owner of a document. So, the tag is
>> used incorrectly there, but there is nothing in the presentation that
>> suggests this. Would this violate 1.3.1?
>>
>> Similarly, I have always thought that using asterisk characters to denote
>> bulleted lists violated 1.3.1, but, since the info and relationships are
>> "available in text" through the use of the asterisk character, one could
>> argue SC 1.3.1 is not violated.
>>
>> Another possible candidate that might catch this sort of thing is SC 2.4.6
>> Headings and Labels
>> <https://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive>,
>> which reads, "Headings and labels describe topic or purpose." Would
>> information about the type of element that is being exposed count as a
>> "label" under this success criteria? Reading the Understanding 2.4.6 page
>> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html>;
>> makes
>> clear they are not only referring to the <label> HTML element, but I find
>> it a little squishy, based on the wording there and the rather anemic
>> techniques listing, what *exactly* that term entails.
>>
>> Finally, it is possible that SC 4.1.2 Name, Role, Value
>> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html>; might
>> be
>> violated by this sort of thing, since it requires that the name and role
>> be
>> programmatically determined. However, this only applies to user interface
>> components, which lists and addresses are not.
>>
>> Another note: If we *do* decide to interpret SC 1.3.1 or SC 2.4.6 more
>> liberally to include incorrect or inadequate semantic encoding, where do
>> we
>> draw the line in terms of marking something as technically violating a
>> criterion? Does a failure to use definition lists, where appropriate, or
>> using unordered lists instead, count as a violation? How about <dfn> or
>> <cite>? Where do we draw the line?
>>
>> If you've gotten this far, you obviously have too much time on your hands
>> and should get back to work (winky face)! But, seriously, I'd appreciate
>> the community's thoughts on the matter. I feel like I might be missing
>> something obvious.
>>
>> Best,
>> Rob
>>
>> --
>> Rob Fentress
>> Senior Accessibility Solutions Designer
>> Assistive Technologies at Virginia Tech
>> Electronic Business Card (vCard)
>> <http://search.vt.edu/search/person.vcf?person54847>
>> LinkedIn Profile
>> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >