Re: Comments on Tutorials from WCAG

Dear WCAG group,
hi Andrew,

[Sorry for sending this out soooo late, it somehow didn’t get 
through.]

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.

Best, Eric



--

Eric Eggert, Web Accessibility Specialist
WAI-ACT Project

I’m yatil on IRC.

Received on Tuesday, 13 January 2015 16:05:21 UTC