Tutorials/Feedback/WCAG-2014-06-04
DRAFT
Tables
1) http://www.w3.org/WAI/tutorials/tables/ IntroWe 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.
- [EOWG Response] We have clarified the wording and think the intro is now simpler and clearer:
For tables that are so complex that header cells can’t be associated in a strictly horizontal or vertical way, use id and headers attributes to explicitly associate header and data cells.
2) Tables: http://www.w3.org/WAI/tutorials/tables/simple/ Table 2Table 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.")
- [EOWG Response] We have reorganized the examples to reflect the importance of scope and used it so we’re in line with technique H63.
3) http://www.w3.org/WAI/tutorials/tables/caption-summary/ misleading textThe 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.
- [X][EOWG Response] We already had already identified that unclear wording in the EO WG reviewing process.
andSee WCAG 2.0 technique H39: Using caption elements to associate data table captions with data tables for advice on captions.
We also have changed the position of those two notes in the text.See WCAG 2.0 technique H73: Using the summary attribute of the table element to give an overview of data tables for advice on the summary attribute.
4) Table ABBRNeeded 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... PayrollRef Name Jul Aug etc.
- [EOWG Response] We have expanded the months to not distract from the main theme of the tutorial.
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.
- [X][EOWG Response] It was reported that role=group works well in NVDA and Internet Explorer. We have added a note on accessibility support. It now reads:
If a group of images has a caption, a figure element can be used to group those images. The WAI-ARIA attribute role with the value of group to indicate grouping to assistive technology. If individual images also have captions, figure and figcaption elements can be nested. The support for this particular WAI-ARIA attribute and value varies.
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?
- [X][EOWG Response] We have made some changes and introduced another yes on the third bullet.
Is the complete content of a link or button defined by this image (or multiple images)?
Review Comment:
- Wording aside, I think the visuals cause confusion or ambiguity in the decision tree. For example, it is not clear that the down arrow or pointer on the bottom left of each grid segment points down to the box right below it (the top right box on the next grid segment) or to the question below as a whole. I think that you can get the gist of the decision tree but I think the confusion slows down progress through the section. {Howard 17 July 2014}
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.
- [EOWG Response] Validity is often a requirement for people working on websites, but it should only be mentioned if something is deprecated in HTML5, so we removed the text from the document.
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.
- [EOWG Response] The “Why is this important?” section is secondary information. It has a prominent place on the concepts page of the tutorials and is now easier to find as we have introduced a “On this page” menu on the right side of the page.
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
- [EOWG Response] We have changed the text.
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)
- [EOWG Response] We used plain and simple HTML examples where possible, which left little ARIA examples for images and tables. We expect to cover a lot more ARIA in the more elaborate tutorials, starting with forms.
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.
- [X][NEW EOWG Response] In general the tutorials focus on accessibility. However, in this particular case using the technique – even accessibly – creates a conflict if designing for mobile is also a requirement. We want to avoid developers feeling that by implementing accessibility they have to compromise the experience for all users on mobile.
Review Comment:
- I wonder if it would be more clear to say something like: "While we are focusing on accessibility (not just WCAG conformance), there is a specific reason to include this particular note. Using this technique creates a conflict with mobile design. We want to avoid the case where someone follows our advice for accessibility, but is then surprised to get critiqued because it doesn't work for other (mobile) users." {Shawn 25 July 2014}
- [OLD] While the main objective of the tutorials is WCAG conformance, we want give developers some advice that goes beyond WCAG and cover other best practices. In this particular instance, the note on mobile compatibility is included as the solution is accessible but adapting it to mobile (i.e. in a responsive context) is not simple and other techniques might be more suitable. We think it is an important aspect to tell readers about the caveats of certain techniques as this should build trust in the validity of the information in the tutorials.
- [OLD 16 July version] While the main objective of the tutorials is WCAG conformance, we want give developers some advice that helps them to produce a better experience for the users. Also we think that it makes sense to include such information where possible and important to not give the impression of giving best practice information but not noting the caveats.
Review Comment:
- I think we need to say more about how we "drew the line" and why we are keeping this note. I disagree with "give developers some advice that helps them to produce a better experience for the users" and "makes sense to include such information where possible" -- or it is too vague. The scope of these tutorials does not include general best practice for user experience and for mobile. Instead, there was a specific reason for including this particular note. {Shawn 3 July 2014}
- Agree with keeping the note and rewording the rationale for why we are keeping it. Emphasize the general accessibility benefit rather than the mobile aspect. Something like "redundant text links provide a reliably accessible fallback for platforms where image maps do not render and operate as expected." {Sharron 16 July 2014}
- I also agree with keeping the note. If looking to reword the rationale, I guess I would argue that just because the issue with mobile image maps may also affect "non-disabled" users, it still becomes an access issue. If something is not usable as a whole, it's that much more inaccessible. {?Howard 16 July 2014}
Issues regarded as important but not show-stoppers:
1) Need 2-tier table exampleNeeded 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
- [EOWG Response] We have added such an example: https://w3c.github.io/wai-tutorials/tables/irregular/#table-with-two-tier-headings
2) Tables: http://www.w3.org/WAI/tutorials/tables/irregular/
Example 3: Table with headers spanning multiple rows or columns. Please verify syntax.
- [EOWG Response] We have edited the syntax and also described better what column and row groups are.
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
- [X][EOWG Response] We have removed the FAQ section of the page and integrated the answers into the tips.
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.
- [EOWG Response] This was already an outcome of the EOWG discussion, we have changed the wording to make that point more clear.
DRAFT response
Dear WCAG group,
thanks for the comments. See inline how we addressed the different issues. Feel free to let us know if there are any questions left.
On 4 Jun 2014, at 15:00, Andrew Kirkpatrick wrote:
> 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.
We have clarified the wording and think the intro is now simpler and clearer:
“For tables that are so complex that header cells can’t be associated in a strictly horizontal or vertical way, use id and headers attributes to explicitly associate header and data cells.”
> 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.")
We have reorganized the examples to reflect the importance of scope and used it so the example represents technique H63.
> 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.
We already had already identified that unclear wording in the EO WG reviewing process.
“See WCAG 2.0 technique [H39: Using caption elements to associate data table captions with data tables] for more advice on captions.”
and
“See WCAG 2.0 technique [H73: Using the summary attribute of the table element to give an overview of data tables] for advice on the summary attribute.”
We also have changed the position of those two notes in the text to improve clarity.
> 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>
We have expanded the months to not distract from the main theme of the tutorial.
> 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.
It was reported that role="group" works well in NVDA and Internet Explorer. We have added a note on accessibility support. It now reads:
“If a group of images has a caption, a <figure> element can be used to group those images. A nested <figcaption> element contains the caption for the whole group. The WAI-ARIA attribute role with the value of group indicates grouping to assistive technologies. If individual images also have captions, additional <figure> elements with individual <figcaption>s can be nested.”
>
> 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?
We have made some changes to the wording and introduced another yes on the third bullet. We also changed the layout to make the tree easier to parse.
“Is the complete content of a link or button defined by this image (or multiple images)?”
> 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.
Validity is often a requirement for people working on websites, however as we are using HTML5 as a base for the tutorials, validity should only be mentioned if something is deprecated in HTML5, so we removed the text from the document.
> 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.
The “Why is this important?” section is secondary information. It has a prominent place on the concepts page of the tutorials and is now easier to find as we have introduced a “On this page” menu on the right side of the page.
> 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
We have changed the text.
> 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)
We used plain and simple HTML examples where possible, which left little ARIA examples for images and tables. We expect to cover a lot more ARIA in the more elaborate tutorials, starting with forms.
> 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.
In general the tutorials focus on accessibility. However, in this particular case using the technique – even accessibly – creates a conflict if designing for mobile is also a requirement. We want to avoid developers feeling that by implementing accessibility they have to compromise the experience for all users on mobile.
> 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:
We have added such an example: https://w3c.github.io/wai-tutorials/tables/irregular/#table-with-two-tier-headers
> 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.
We have edited the syntax and also described better what column and row groups are.
> 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
We have removed the FAQ section of the page and integrated the answers into the tips.
> 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.
This was already an outcome of the EOWG discussion, we have changed the wording to make that point more clear.