Comments on Tutorials from WCAG

Dear EO group,
Below are the issues that the WCAG group identified in your tutorial documents.  They are grouped into comments on tables, images, and a group of items that we feel should be addressed but it isn't imperative that they are before the initial publication.  Please let us know if you have any questions.

Tables


1)      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.


2)      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.")


3)      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.


4)      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


1)      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.


2)      Images: http://www.w3.org/WAI/tutorials/images/decision-tree/
Some of the wording in the decision tree is confusing.
"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.
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?


3)      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... Should be clarified to indicate the reality of using ARIA in HTML4.


4)      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.


5)      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


6)      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)


7)      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.

Issues regarded as important but not show-stoppers:


1)      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:


2)      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.


3)      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


4)      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.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

akirkpat@adobe.com<mailto:akirkpatrick@adobe.com>
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility