E-mail List Archives

Search E-mail List Archives for

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

From: Robert Fentress
Date: Tue, Feb 06 2018 7:19AM
Subject: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
No previous message | Next message →

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>

From: Birkir R. Gunnarsson
Date: Tue, Feb 06 2018 7:56AM
Subject: Re: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
← Previous message | Next message →

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.

From: Steve Faulkner
Date: Tue, Feb 06 2018 8:00AM
Subject: Re: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
← Previous message | Next message →

>
> ON your first example, my understanding is that there are plans to
>
change the <address> definition so that it can be used more widely.


The address element definition has changed:

The address element represents contact information for a person, people or
> organization. It should include physical and/or digital location/contact
> information and a means of identifying a person(s) or organization the
> information pertains to.

https://www.w3.org/TR/html52/grouping-content.html#elementdef-address



--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 6 February 2018 at 14:56, 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.
> > > > >

From: Bourne, Sarah (MASSIT)
Date: Mon, Feb 12 2018 1:48PM
Subject: Re: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
← Previous message | Next message →

Going back to Bob's original set of questions, what if you aren't really sure what structure is being conveyed by the presentation?

For example, I'm looking at the " Find Your Future Commonwealth Job" page on Mass.gov [1]. Two H2s, " What would you like to do?" and " What you need to know". Each of these has very attractive "tiles" with links to more specific information. Right now, these tiles have no semantic markup other than the A tag. You may have noticed that there is no "tile" tag in HTML. <smile> Visually, I would think they're most like paragraphs and should use the P tag. Functionally, I would think list mark-up would be more useful, for screen reader users anyway.

So, two questions here: Is this a violation of 1.3.1?, and What is the correct structural markup?

The next H2 (which looks different, by the way) is "Additional Resources" followed by text links (no tiles). Again, they are only marked up with DIVs. Surely they should be list items (even though they look more like paragraphs.) But is it a 1.3.1 failure that they aren't marked up as either a list or a paragraph? The last link takes you to another pages showing all additional resources [2] with the same problem.

Things like this are what make feel uncomfortable basing conformance just on what something looks like. If your H2s don't all look like each other, that doesn't necessarily mean they should be different heading levels. And designers are always going to come up with new designs, that may have things that don't look like the standard structural elements in HTML.3

[1] https://www.mass.gov/find-your-future-commonwealth-job
[2] https://www.mass.gov/find-your-future-commonwealth-job/resources
Sarah E. Bourne
Director of IT Accessibility
Executive Office of Technology Services and Security (EOTSS)
1 Ashburton Place, 8th Floor, Boston, MA 02108
Office: (617) 626-4502
= EMAIL ADDRESS REMOVED = | www.mass.gov/eotss

From: Jim Allan
Date: Wed, Feb 14 2018 9:18AM
Subject: Re: To what degree does failure to convey structure violate 1.3.1 or other success criteria?
← Previous message | No next message

Sarah,
Those "tiles" function as links and are marked up as links. That's
semantic. It would be useful to make them a list so the user would know -
How many Top Tasks there are, or How many things do I need to know. Links
in a list would be more useful semantics. They could still look like
"tiles". You could add some aria roles (list, list item) to add list
semantics.
I wish the ones that open pdf document would tell me that.

Jim


On Mon, Feb 12, 2018 at 2:48 PM, Bourne, Sarah (MASSIT) <
= EMAIL ADDRESS REMOVED = > wrote:

> Going back to Bob's original set of questions, what if you aren't really
> sure what structure is being conveyed by the presentation?
>
> For example, I'm looking at the " Find Your Future Commonwealth Job" page
> on Mass.gov [1]. Two H2s, " What would you like to do?" and " What you
> need to know". Each of these has very attractive "tiles" with links to
> more specific information. Right now, these tiles have no semantic markup
> other than the A tag. You may have noticed that there is no "tile" tag in
> HTML. <smile> Visually, I would think they're most like paragraphs and
> should use the P tag. Functionally, I would think list mark-up would be
> more useful, for screen reader users anyway.
>
> So, two questions here: Is this a violation of 1.3.1?, and What is the
> correct structural markup?
>
> The next H2 (which looks different, by the way) is "Additional Resources"
> followed by text links (no tiles). Again, they are only marked up with
> DIVs. Surely they should be list items (even though they look more like
> paragraphs.) But is it a 1.3.1 failure that they aren't marked up as
> either a list or a paragraph? The last link takes you to another pages
> showing all additional resources [2] with the same problem.
>
> Things like this are what make feel uncomfortable basing conformance just
> on what something looks like. If your H2s don't all look like each other,
> that doesn't necessarily mean they should be different heading levels. And
> designers are always going to come up with new designs, that may have
> things that don't look like the standard structural elements in HTML.3
>
> [1] https://www.mass.gov/find-your-future-commonwealth-job
> [2] https://www.mass.gov/find-your-future-commonwealth-job/resources
> Sarah E. Bourne
> Director of IT Accessibility
> Executive Office of Technology Services and Security (EOTSS)
> 1 Ashburton Place, 8th Floor, Boston, MA 02108
> Office: (617) 626-4502
> = EMAIL ADDRESS REMOVED = | www.mass.gov/eotss
> > > > >



--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964