EOTutorials review

From WCAG WG

Overview of Issues

Tables

http://www.w3.org/WAI/tutorials/tables/ Intro

We think the wording needs work in some of the 'Tables Concepts' intros. The brief overview of the problem/solution for data tables works ok when it is simple. As in simple tables, or even complex irregular tables. However, it breaks down for the 'Complex Multi level tables' the intro needs to be simple and clear.

Tables: http://www.w3.org/WAI/tutorials/tables/simple/ Table 2

Table 2, with row and column headings needs scope, per H63 ("Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.")

Need 2-tier table example

Needed but not a publication show-stopper: it will be a new example so I'm not sure about timelines, but I think very common and important enough for before pub. I think we need to address the issue of a two tier simple table which both JAWS and NVDA handle OK now. I think they should be allowed without headers and ids. I have an example here: Two Tier table example: http://davidmacd.com/test/two-tier-simple-table.html

Tables: http://www.w3.org/WAI/tutorials/tables/irregular/

Example 3: Table with headers spanning multiple rows or columns. Please verify syntax.

http://www.w3.org/WAI/tutorials/tables/tips/

Needed but not a publication show-stopper: I like the FAQs! However, because the first FAQ deals with the very question of layout tables I suggest remove the note, or merge it with the first question. "A note on layout tables: You shouldn’t use tables for layout purposes. If you do don’t use any of the structural elements and attributes discussed in this tutorial and add role="presentation" to the table element. It’s much better to use Cascading Style Sheets (CSS) for layout

http://www.w3.org/WAI/tutorials/tables/caption-summary/ Summary

Needed but not a publication show-stopper: Josh: The use of the term 'summary' is kinda loaded. It may be best to rethink this, especially as the attribute is deprecated in HTML5. Having said that, it is still @summary a valid HTML4 attribute so should WCAG supporting materials still reflect that? My own opinion is that we should use HTML5 type methods in our tutorials and add older developments methods as a footnote or aside, rather than giving them centre stage.

AWK: I agree but this can be adjusted later.

DM: To address Andrews comment I would just put a period after the talk about Caption. "Most tables benefit from the use of a caption to describe the overall topic of a table. On *some *complex tables a summary can provide orientation or navigation." This is based on conversations with a user born blind who finds Statistics data easier to understand by reading the summary paragraph before the table. She feels tables are a lot harder for people born blind than those who acquire blindness.

(editorial) Bruce: Agree with David's suggestion to break into two sentences. I suggest that the explanations say that captions should "describe topic or purpose" or "provide descriptive identification" rather than being a "succinct description". That way we are consistently reusing phrasing from parts of WCAG.

http://www.w3.org/WAI/tutorials/tables/caption-summary/ misleading text

The following two sentences in Caption & Summary are misleading: Captions are recommended in WCAG 2.0 technique H39: Using caption elements to associate data table captions with data tables<http://www.w3.org/TR/WCAG20-TECHS/H39> Summaries are recommended in WCAG 2.0 technique H73: Using the summary attribute of the table element to give an overview of data tables<http://www.w3.org/TR/WCAG20-TECHS/H73> Neither technique recommends the use of the feature; they should be used when appropriate for the table. (And the tutorial seems to do a good job of explaining when they might be appropriate). The techniques explain how the technology should be used to communicate this information, e.g., the caption element should be used for the table caption rather than a heading element.

Table ABBR

Needed but not a publication show-stopper: Example two with Jul, Aug, Sept etc... should have the abbreviation tag on those short forms for months, or aria label. Short abbreviations are often confusing to listen to in JAWS, NVDA etc... 

<tr>
      <th scope="col">PayrollRef</th>
      <th scope="col">Name</th>
      <th scope="col"><abbr title="July">Jul</abbr></th>
      <th scope="col"><abbr title="August">Aug</abbr></th>
     etc.
   </tr>

Images

Images: http://www.w3.org/WAI/tutorials/images/groups/ role="group" not ready?

We're not sure that the grouping example for images with role="group" is quite ready. Neither JAWS nor NVDA reads this as I'd hope. JAWS makes mistakes and NVDA ignores the grouping as far as I can tell. Is this ready to advocate for people to use? For that matter, what benefit are we expecting from grouping this way? It seems that it is going to be difficult for users to remember what level of the grouping they are in for an example like this one.


Images: http://www.w3.org/WAI/tutorials/images/decision-tree/

Some of the wording in the decision tree is confusing.

  1. "Is this image the only content of a link or form control?" and "include the communicative text of the image"
* How about "Use the alt attribute to include the meaningful text in the image (not text included for visual effect)."

There is at least one common case that this tree would lead to the wrong result.

  1. Image in a link that carries redundant information (e.g. <a href="survey.html">2014 Survey report (PDF)<img src="pdf.png" alt=""></a>)
* This image does contribute meaning, but it is redundant to the link. Maybe another "yes" case on the third bullet?

ARIA in HTML4?

Loretta: Approach 3 states that the technique is only valid for HTML5. I thought ARIA could be used with HTML4.

AWK: I think that this is a bit confusing also, but think that they mean that the HTML4 DTD doesn't allow it and HTML5 does. Of course, to meet WCAG you don't need to have fully valid code...

Why is the 'Why is this important?' section

Needed but not a publication show-stopper: Josh: This should be at the top - the first thing they see. I really like the idea of these 'Why is this important?' sections, and would like to see more if possible.

http://www.w3.org/WAI/tutorials/images/functional/

Change the statement "The screen reader will announce the image filepath or the URL for the destination page @@which is unlikely to help users know where the link leads to."

ARIA in tutorial

We were surprised by the general lack of mention of ARIA attributes (and that the relevant ARIA techniques are not listed). I assumed this is because the tutorial is being conservative, and EO feels that ARIA is not sufficiently accessibility supported. But then the Images of Text page recommends using MathML. Is MathML better accessibility supported than ARIA? Similarly, is CSS3 (also from that page) more accessibility supported than ARIA? Or am I misreading the reasons that ARIA isn't mentioned in the rest of the tutorial (except for role=presentation, which is called out as a less desirable alternative to alt="", and several examples for complex images)

http://www.w3.org/WAI/tutorials/images/imagemap/

The note can be removed because it isn't an issue that affects WCAG conformance - the ability of image maps to work for any user on a mobile device is what this note is talking about and it isn't specifically related to accessibility.

Individual Comments

In this initial review we will aim to address high level issues that illustrate a disconnect or outright error in terms of WCAG advice. NOTE: [BEFORE PUB] is in front of the most important ones that should be addressed before initial publication.

AWK Comments

TABLES

1) I'm concerned that they say that "most tables benefit from... summaries" I'd say that most tables don't need or benefit from a summary.

1) [BEFORE PUB] Table 2, with row and column headings needs scope, per H63 ("Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.")

1) Example 1 is fine with scope, but H63 explicitly allows scope to be omitted.

1) Approach 3 indicates that aria-describedby is only valid in HTML5

IMAGES

1) There is little mention of aria and I get that this is a level that represents greater complexity so may be out of scope. However, I think that a sentence that indicates that there are advanced techniques that people may be interested in would be helpful somewhere.

1) a null (empty) alt text - how about "a null alt value" (or "a null alt attribute value")? 2) Link to ARIA technique for role="presentation"?

1) It would be nice if example one didn't need to be scrolled horizontally 2) Perhaps the long description link should include the #site-visitors-for-examplecom location-specific ID?

1) [BEFORE PUB] I'm not sure that the grouping example for images with role="group" is quite ready. Neither JAWS nor NVDA reads this as I'd hope. JAWS makes mistakes and NVDA ignores the grouping as far as I can tell. Is this ready to advocate for people to use? For that matter, what benefit are we expecting from grouping this way? It seems that it is going to be difficult for users to remember what level of the grouping they are in for an example like this one.

1) [BEFORE PUB] I find some of the wording confusing. "Is this image the only content of a link or form control?" and "include the communicative text of the image" a. How about "Use the alt attribute to include the meaningful text in the image (not text included for visual effect)." 2) There is at least one common case that this tree would lead to the wrong result. a. Image in a link that carries redundant information (e.g. < a href="survey.html">2014 Survey report (PDF)<img src="pdf.png" alt=""></a>) i. This image does contribute meaning, but it is redundant to the link. Maybe another "yes" case on the third bullet?

Gregg Comments

Tables Concepts

COMMENT: Looks good so far. But I think examples would help a lot.

Images

  • [Informative images] used to graphically illustrate concepts and information, typically pictures and illustrations: The text alternative should be at least a short description conveying the essential information presented by the image.

COMMENT: Put the advice under the item - indented one level

  • [Images of text] that provide readable text (sometimes used when special fonts are wanted) are discouraged except for logos. However, if images of text are used, the text alternative should contain the same words as in the image.

COMMENT: This is unclear. I’m not sure anyone will know what this means if they don’t already know what it is trying to say. Perhaps “Images of text that are used when a special look is desired for the text”

  • [Complex images such as graphs and diagrams] [...]

COMMENT: Do I put a full description in the ALT text?

  • [Groups of images used to convey] [...]

COMMENT: • What do I do with the rest of them??? Alt = “”  ? need to say.

Josh Comments

[BEFORE PUB]

1) I think the wording needs work in some of the 'Tables Concepts' intros. The brief overview of the problem/solution for data tables works ok when it is simple. As in simple tables, or even complex irregular tables. However, it breaks down for the 'Complex Multi level tables' the intro needs to be simple and clear.

[BEFORE PUB] 2) http://www.w3.org/WAI/tutorials/tables/caption-summary/ The use of the term 'summary' is kinda loaded. It may be best to rethink this, especially as the attribute is deprecated in HTML5. Having said that, it is still @summay a valid HTML4 attribute so should WCAG supporting materials still reflect that? My own opinion is that we should use HTML5 type methods in our tutorials and add older developments methods as a footnote or aside, rather than giving them centre stage.

3) Rather than " to display data in a grid and don’t apply to presentational (layout) tables." I'd say " to display tabular data and don’t apply to presentational (layout) tables." I don't think grid is a standard term for a data table. Or is it in some domains?

4) The use of 'user stylesheets' is ambiguous. The presence of user style sheets may not result in an a11y fail or poor user experience, it would if those styles resulted in poor colour contrast ration/luminescence but thats not a given. So the usage here is ambiguous and could be read as 'user style sheets are inherently bad for data table a11y.

5) http://www.w3.org/WAI/tutorials/tables/simple/ "Use header cell elements (th) to markup the header cells so that they are distinguishable from data cells and associated with the correct data cells.' The repetition of 'data cells' here sounds funny. It's also not a header cell element, it's a header element, right? "Use the th element to markup each of the data table header cells. This will distinguish them from ordinary data cells td and allow screen reader users to understand how they are related."

6) In 'Example 2', I would say instead of "All header cells are marked up as th cells." - "All cells in the first row and the first column are therefore marked up as th cells."

http://www.w3.org/WAI/tutorials/tables/irregular/ 7) Qualify why it is hard, rather than stating that it is just 'hard'. "In an irregular table extra care needs to be taken to associate columns and rows with any given header cell."

8) Regarding example 1. I'm not sure if it is the best introduction to the use of @scope. The Example 2 may be better as it is a more irregular table. Example 1, isn't really an irregular table.

http://www.w3.org/WAI/tutorials/tables/multi-level/ 9) For the line "[..] giving each th cell a unique id attribute, and each td a headers attribute that lists related id values, " should we call out that this is the headers attribute as distinct from the header element? Something like "giving each th cell a unique id attribute, and each td a headers attribute (which is different from the th headers element!) that lists related id values. Or is it clear as is?

10) In many cases it is worth considering ways to restructure the information <chg>in</chg> the tables to make them less complex for all readers, for example by separating the information <chg>into</chg> smaller, more manageable tables.

[BEFORE PUB] http://www.w3.org/WAI/tutorials/tables/tips/ 11) I like the FAQs! However, because the first FAQ deals with the very question of layout tables I suggest remove the note, or merge it with the first question. "A note on layout tables: You shouldn’t use tables for layout purposes. If you do don’t use any of the structural elements and attributes discussed in this tutorial and add role="presentation" to the table element. It’s much better to use Cascading Style Sheets (CSS) for layout"

Images

1) When resizing the browser view, I see the 'Jump to the navigation' option. Its sounds a little funny, suggest 'Jump to Navigation' may be better. However, should it just be 'Navigation'? Also when you get to the navigation menu, the 'Jump to [...]' menu is still there. This could be useful on mobile devices though, I guess - would have to test further.


2) Decorative images used to add visual interest to the page, rather than to convey information that is important to understanding the text: The text alternative should be null (alt=""). What about referring to using CSS background images for decorative images?


3) Functional images used alone as a link or button to activate a function – for example, icons for printing and submitting forms: The text alternative should describe the function rather than the visual image. Suggested edit "[...]The text alternative should describe the function rather than the <chg>appearance</chg> of the image."


4) "Images of text that provide readable text [...] " sounds funny - as it's implied that somehow some images of text may be designed to be unreadable. Suggest just 'Images of text are discouraged, except for logos." The point about special fonts can be left for deeper within the tutorial.

[BEFORE PUB] 5) Why is the 'Why is this important?' section at the bottom? This should be at the top - the first thing they see. I really like the idea of these 'Why is this important?' sections, and would like to see more if possible.

[BEFORE PUB] http://www.w3.org/WAI/tutorials/images/functional/ 6) The statement "The screen reader will announce the image filepath or the URL for the destination page which won’t help users know where the link leads to." isn't true. If the URL of the destination page is clear "../about_us.html" or something, then that info can be very useful. It's not a repair technique to rely on but the URL can provide a useful pointer for the end user if there is no @alt etc. It may be best to say something like: "The screen reader will often announce the image filepath or the URL for the destination page neither of which may help users understand the purpose of the link, especially if the URL is generated by a CMS or has the form of some random string like "../PGLVAKV&View_52554.html" or similar. Something like that.

http://www.w3.org/WAI/tutorials/images/textual/ 7) The second paragraph,"Actual text is much more flexible than images [...]" would actually be really good as a 'Why is this important?" callout.

http://www.w3.org/WAI/tutorials/images/textual/ 8) In the 'MathML' example, the paragraph: "If math forms are a substantial part of the page or website content, MathML should be used instead. MathML represents both presentation and content semantically, making it more accessible to a wider range of users. Many assistive technologies can interpret the code." could also be a 'Why is this important?" callout.

9) I'm not convinced that the longdesc example should go first. Should we not be promoting new ways of doing these things, especially where longdesc support in SRs is patchy etc? Maybe approach 5, should be the first. Am not going to labour this point but do want to raise it.

[BEFORE PUB] http://www.w3.org/WAI/tutorials/images/imagemap/ 10) The 'Note' - shouldn't it tell users how to do this, or what 'redundant text links' means?

http://www.w3.org/WAI/tutorials/images/tips/ 11) In the FAQ, the first question needs to be qualified a little "I've been told to remove the alt from most of the images in my template. Is that right?" Why?. Also say something like, adding alt="" will not affect how any images are displayed in the browser.

David MacD Comments

 http://www.w3.org/WAI/tutorials/tables/

[BEFORE PUB] 1) To address Andrews comment I would just put a period after the talk about Caption.

"Most tables benefit from the use of a caption to describe the overall topic of a table. On *some *complex tables a summary can provide orientation or navigation."

This is based on conversations with a user born blind who finds Statistics data easier to understand by reading the summary paragraph before the table. She feels tables are a lot harder for people born blind than those who acquire blindness.

[BEFORE PUB - it will be a new example so I'm not sure about timelines, but I think very common and important enough for before pub] 2) I think we need to address the issue of a two tier simple table which both JAWS and NVDA handle OK now. I think they should be allowed without headers and ids. I have an example here:

Two Tier table example: http://davidmacd.com/test/two-tier-simple-table.html

The summary attribute has been removed from HTML5 so it should be removed here, or qualified that it is being phased out.

The aria-describedby example Approach 3 should mention that the paragraph summary can be hidden with details/summary, or a conforming JavaScript show/hide for browsers that don't support details/summary yet. We've been dealing with this over on html5.

[BEFORE PUB] (3) I think example two with Jul, Aug, Sept etc... should have the abbreviation tag on those short forms for months, or aria label. Short abbreviations are often confusing to listen to in JAWS, NVDA etc... 

<tr>
      <th scope="col">PayrollRef</th>
      <th scope="col">Name</th>
      <th scope="col"><abbr title="July">Jul</abbr></th>
      <th scope="col"><abbr title="August">Aug</abbr></th>
     etc.
    </tr>

(4) Agree with Andrew. I'm beginning to think the figcaption might become the new longdesc, with no support and messed up implementation.

Kathy Wahlbin Comments

Images

This has been done for other sections so it should be included

reference to using role="presentation" for decorative images. I believe we decided against including this as a

For images of text, I think it should be more explicitly stated that images of text should not be used and that is it a WCAG 2.0 AA compliance issue when can be done using

May want to note that this can also be done using WAI-ARIA using flow to and flow from

The comments on SVG I don't think this should be included since it not accessibility supported.

Tables

the summary attribute is deprecated in HTML5; so this page should reference the alternative solution of aria-describedby as shown in Approach 4 on the Caption & Summary page

this example should have the scope attribute included since delivery slots could be either a column or row header

Loretta Comments

Tables

  • [BEFORE PUB] The following two sentences in Caption & Summary are misleading:

Neither technique recommends the use of the feature; they should be used when appropriate for the table. (And the tutorial seems to do a good job of explaining when they might be appropriate). The techniques explain how the technology should be used to communicate this information, e.g., the caption element should be used for the table caption rather than a heading element.

  • [BEFORE PUB] Approach 3 states that the technique is only valid for HTML5. I thought ARIA could be used with HTML4.

Images

  • [BEFORE PUB] I was surprised by the general lack of mention of ARIA attributes (and that the relevant ARIA techniques are not listed). I assumed this is because the tutorial is being conservative, and EO feels that ARIA is not sufficiently accessibility supported. But then the Images of Text page recommends using MathML. Is MathML better accessibility supported than ARIA? Similarly, is CSS3 (also from that page) more accessibility supported than ARIA? Or am I misreading the reasons that ARIA isn't mentioned in the rest of the tutorial (except for role=presentation, which is called out as a less desirable alternative to alt="", and several examples for complex images)
Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=EOTutorials_review&oldid=4709"