Disposition of comments for the Accessibility Guidelines Working Group

Further to my email on the same subject sent last week:
It appears from reading the 'understanding' material for SC 1.3.2 and 2.4.3, and associated techniques, that the expected reading order determined visually is key to identifying correct reading sequence from an accessibility standpoint.
G59(Placing the interactive elements in an order that follows sequences and relationships within the content) states:
"When the order of the HTML source matches the visual order of the Web page, tabbing through the content follows the visual layout of the content. When the source order does not match the visual order, the tab order through the content must reflect the logical relationships in the content that are displayed visually".
Then C27: suggests making the DOM order match the visual order.
“The objective of this technique is to ensure that the order of content in the source code is the same as the visual presentation of the content”.
Then it goes on to describes the problems if the DOM order does not match visual order. These are accurate and very valid. So if above stated objective is not attained, then does the content not fail the SC?
Comment:
For every page there is only one intended reading order and the author sets out the page in that manner. This will generally be the order one might reasonably expect based on a visual inspection of the page. The focus order of nav elements should follow that reading order.
It is the user’s prerogative to read / navigate it in a different order if he so chooses. And he may do so because the alternate order helps him to better understand the content or simply because only certain blocks of content are of immediate relevance / interest. Proper structural markup would support this.
If these techniques are to be applied to make content comply with SC 1.3.2 then can one conclude that if actual reading and focus order do not follow expected visual order, then there is a problem and content fails SC 1.3.2 / SC 2.4.3?

I agree that CSS can be used to change presentation. But it should not suggest a reading / focus order that is different from DOM / actual order that is programmatically determinable.

I feel that the 2 sufficient techniques for SC 2.4.1 should be 'and' not 'or'.

I had originally read this that 1 and 2 were exactly that an 'and', then someone I know who does accessibility testing for a living, pointed out to me that I was wrong. They are not 'and', ie you can do one or the other. However I see a problem with that:

Skip links are of main benefit to sighted users who navigate via the keyboard and are of only very limited benefit to screen reader users. However H69 (heading elements) is only of use to screen readers and provides no help whatsoever for sighted users navigating via the keyboard. (I don't know enough about map, frame and scripting to comment on those, but as they have been grouped with H69, I suspect that they too are of little or no benefit to sighted people who navigate with the keyboard.)

Nonetheless, if someone writes a web page to H69, they would be deemed to have passed SC 2.4.1, even though they have not provided any method for sighted keyboard users to bypass blocks of content that are repeated on multiple pages. The most number of hits of the tab key that I counted before getting to the main page content on one web site was 69 each time I went onto a new page.

Proposed Change:
Please make it 'and' so that both sighted keyboard users and screen reader users are helped. At the moment it's perfectly possible to help only one of those groups and not help the other and still pass this SC.

SC 4.1.1 requires limited validity checks for markup: unique ID values, proper tag nesting and closing and a check for duplicate attributes.

However, the WCAG 2 Understanding documentat suggests that conformance claim could include something along the lines of:
"The documented set of accessibility-supported content technologies relied upon for this claim includes XHTML 1.0 (Transitional), CSS 2 and JavaScript 1.2. "
Refer: example conformance claims on http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head
Does this imply that one can make such a statement only after ensuring that markup / CSS / JS code is valid?
Please clarify whether validating the code for CSS / JS / XHTML beyond what is suggested in SC 4.1.1 is required for a conformance claim if for instance, all three technologies are used.

The Government of Canada has pointed out an ambiguous note: read our correspondence below

From: Pirthipal.Singh@tbs-sct.gc.ca [mailto:Pirthipal.Singh@tbs-sct.gc.ca]
Sent: September-14-10 10:19 AM
To: David@eramp.com
Subject: Quick Question

Hi David

Hope things are going well.

We have a question: In success criteria 3.3.2 (http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/minimize-error-cues.html), there is an ambiguous note at the end of sufficient techniques which states

Note: The techniques at the end of the above list should be considered "last resort" and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group.

The use of the terms "last resort" and "techniques at the end of the above list" are causing confusion. For example, are techniques 4+5 fine or does one follows sufficient techniques from the top (and only use latter ones if the earlier ones cannot be met).

Would you be able to clarify?

P.S. My recommendation would be not to put in ambiguous terms like that for sufficient techniques. If a sufficient technique is not considered sufficient, it should not be in the sufficient techniques.

Pirthipal Singh
Team Leader - Web Standards Office | Chef d'equipe - Bureau de normes web
Information Technology Division | Division de la technologie de l'information
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Pirthipal.Singh@tbs-sct.gc.ca
Telephone | Téléphone 613-948-1888 / Facsimile | Télécopieur 613-946-9342 / Teletypewriter | Téléimprimeur 613-957-9090
Government of Canada | Gouvernement du Canada
Hi Pirth

You are probably right... I actually don’t remember when that got added ...

I think they are talking about these two techniques in the note:
• H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
• G167: Using an adjacent button to label the purpose of a field

The Title attribute has flakey support in User agents... It’s not really the author’s fault... but JAWS does allow the user to set the Title attribute for different settings ... although most blind people don’t know that and it’s also not the best behaviour anyway... so that’s why I think they added the note but let the techniques stand. For G167, screen readers are pretty smart about looking around a field for something that might be a label so it would probably read ok, but again it’s not really a programmatic association. Giving advice like this is pretty ambiguous. The note telegraphs that the committee was not thinking that the techniques were going to become mandatory...

I’ll add your comments, and suggest the techniques be demoted to advisory.

Cheers
David MacDonald




Proposed Change:
Change H65 and G167 to advisory techniques for 3.3.2

And review H71 (using fieldset) to consider whether it should be sufficient or advisory

SC 2.4.6 requires a label to describe purpose, meaning purpose of associated components including interactive controls.
But this is not clear from reading the content for Understanding SC 2.4.6. The SC refers to headings and labels but the examples that follow do not contain an example for form labels. (The definition of label is wider than HTML form label).
Only G131 in the "How to" doc seems to clearly suggest that label refers to labels for interactive components. SC 3.3.2 only requires a label ... does not say label's purpose is clear.
I often see form controls with poor labels / title attributes and I flag SC 2.4.6.
Suggestion: The Understanding SC 2.4.6 and examples should explicitly refer to labels for form controls and interactive components.

Issue 1: For SC 3.2.5 (AAA) it says in the "Understanding" doc that: " ... eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of
forms after selecting an item from a list, etcetera."
Comment: Auto submission of form after making a selection from a list should not be listed under SC 3.2.5 as it needs to be fixed in order to comply with SC 3.2.2.
If a form auto-submits and refreshes the page's content as one tabs off a SELECT control after navigating up and down the choices and making a selection, it is a violation of SC 3.2.2.
H84 explains how a button placed after the SELECT will fix the issue.
The "Understanding" doc explains that the intent of SC 3.2.2 is to ensure that entering data or selecting a form control has predictable effects. So there is no doubt that this is indeed an SC 3.2.2 issue.

Issue 2: Refer to Understanding doc for SC 3.2.2.
One of the items under benefits is:
"• Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected."
Comment: This refers to a new browser window and not just a pop-up in the same page like for an advertisement. A new browser window popping up is an SC 3.2.5 (AAA) issue and should not be listed under SC 3.2.2. The item has already been listed under benefits for SC 3.2.5.
By the way, the browser does convey to AT that a new window is being launched.

The first two list items(out of six) following Examples repeat the text under Intent verbatim. I do not understand why.
The fifth list item says the left nav links are made to appear before main content via CSS but the left nav links actually main content in the code. And this helps navigating to main content directly and this passes SC 2.4.3.
Comment:
I think it fails SC 2.4.3.
A sighted keyboard user will be confused if he cannot tab to a set of links that appear before main content. In a left to right and top-down system one might expect tab focus to go to left nav links first. For a screen reader user too, this may pose problems: there may be an h1 before main content and no heading before left nav links. So it may be difficult to identify end of main content. If the page layout has been explained to a blind user, he too will be confused if he cannot navigate to left nav before main content.
(If left nav appear after main content visually and in tab order, it is another matter).

In example 4, we translated the example of text that is easy to read. In French it counts more words than in English, 134 words. We tried to keep it as simple as possible.
As suggested by Shadi in an e-mail exchange, we submit this change to the working group to find out if it still acceptable as translated in the French language.
See direct link at:
http://www.braillenet.org/accessibilite/comprendre-wcag20/CAT20110222/meaning-supplements.html#meaning-supplements-examples-head

Many techniques in the Understanding doc (e.g. from http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html) seem to link to the 2001/11 version of the Techniques (eg http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G93) rather than the latest release (ie http://www.w3.org/TR/WCAG20-TECHS/)

Proposed Change:
Update links to always link to "Latest Version"

The overview document for the Understanding document
http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html

should have a link to the single file version.
http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete.html


Proposed Change:
Place a link somewhere near the top of the file that says something like:
The Understanding document is available as a single file here:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete.html

SC 3.2.1 uses "focus", not "keyboard focus". My understanding is that this SC is applied to mouse focus as well. However "Examples of Success Criterion 3.2.1" and the one and only Sufficient Technique G107 mention only keyboard users. This could mislead readers to misunderstand that this SC is applied to keyboard use only.

Proposed Change:
If this SC is also applied to mouse users, for example, please add a failure about it. "When a user moves the focus to a text field by clicking on it, a new window or a popup window is opened." or something like that.

Also having a note which explains that mouseover doesn't move focus to the element would be helpful.

Is this guidance contradictory and confusing?

"How to meet WCAG 2.0" doc states:
"Authors are encouraged to apply all techniques that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users".

On the other hand, refer to "Sufficient and Advisory Techniques" under Intro to Understanding WCAG 2.0, which states:
"In order to provide guidance and examples for meeting the guidelines using specific technologies (for example HTML) the working group has identified sufficient techniques for each Success Criterion that are sufficient to meet that Success Criterion. Sufficient techniques are provided in a numbered list where each list item provides the technique or combination of techniques that can be used to meet the Success Criterion".
"Most Success Criteria have multiple sufficient techniques listed. Any of the listed sufficient techniques can be used to meet the Success Criterion".

So in the above, one doc says any one technique is sufficient and the other doc encourages more than one technique to be implemented. So which is it. I do realize one uses "encourages". But:
Specifically, consider SC 2.4.1 for skipping blocks of content:
There are two groups of sufficient techniques: one for an actual skip nav link and the other set for proper structural markup like heading, frames, etc.

One may conclude that if headings are implemented (H69) of group#2 of sufficient techniques, then SC 2.4.1 is met.
But user agent notes for H69 acknowledge that this does not work in all situations. The actual skip nav link technique does work for a wider set of situations.

Then are individual techniques of the second group really sufficient?
So while group# 2 of the sufficient techniques for SC 2.4.1 is helpful and enhances navigation abilities, they are not sufficient by themselves given today's user agent scenario.

As for me, besides skip nav, I recommend headings and use of landmark roles too to clients.

Please can you share your thoughts?

Understanding Success Criterion 1.3.2

"(None currently documented)" stands at the beginning of examples, although examples are available

This sentence should be removed as examples are available.

Proposed Change:
Remove the sentence. We did this in the CAT translation as agreed with Michael Cooper.


http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0007.html:
Understanding Success Criterion 3.1.5

"None currently documented" should not be there.
The sentence stands here although examples are available.

Proposed Change:
Remove sentence. We did this in our CAT version as agreed with Michael Cooper.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0008.html:

In Understanding Success Criterion 2.2.1:
Link to SC 3.1.2 links to Guideline 3.1;
the link does not directly point to SC 3.1.2 but to the Guideline above. Located in the quotation of SC 2.2.1.consistent-behavior.html#consistent-behavior-receive-focus

Proposed Change:
Link to: consistent-behavior-receive-focus.html
Note: we changed the link in the French CAT translation.

Hello all,
During the translation process of Understanding WCAG 2.0, one reviewer found that it may be useful to expand the acronym WCAG 2.0 the first time it occurs in the document, that is in the H1 of the overview file. That would mean:
<h1><a name="title" id="title"> </a>Understanding WCAG 2.0 </h1>
replaced by:
<h1><a name="title" id="title"> </a>Understanding <acronym title="Web Content Accessibility Guidelines">WCAG</acronym> 2.0 </h1>

For your information:
In the French translation of Understanding this success criteria, we changed the examples of two words:
In intent of this success criteria, original version gives the example of the French word rendez-vous that does not require any language identification in English. In order to make this better understandable for French speaking reader, we replaced this example with an English word parking.
We also changed the word voiture which is not pronounced correctly in English if language change is not specified, and took the example of the word "flour" which would not be pronounced correctly in French if language is not specified.
We ask the working group if this changes is accepted.

Hello all,
While translating Understanding WCAG 2.0, we had an issue raised by a reviewer about a better identification of document titles in text.
She thinks that it would be useful to quote the title or to write it with italics.
Example where this occurs:
"Specific techniques for meeting each
Success Criterion for this guideline are listed in the understanding sections for each Success Criterion (listed below)".
The suggestion is to write in the "understanding" sections or to write understanding with italics.

During the review process of the French translation of Understanding WCAG 2.0, the French reviewers noted that punctuations would not be used in an appropriate way, in particular at the end of each item of a list ul li. They request that punctuations should be reviewed in a future version of the document.

Proposed Change:
In particular, concerning the three items list, just before heading 3 "sufficient and advisory techniques" the three items list should end with a full stop, as we reach the intent of a section.
Actual wording:
"descriptions of the intent of the Success Criteria, including benefits, and examples" should be changed in:
descriptions of the intent of the Success Criteria, including benefits, and examples."
We inform the Working Group that we added this full stop at the end of the list, but only for this particular issue.

While skimming the document, it would be easier for the reading to see document titles if they are emphasised through italics or with quoting.

Proposed Change:
See for example, in heading "sufficient and advisory techniques" following sentence:
"for an explanation of how this document fits in with other Web Content Accessibility Guidelines (WCAG) 2.0 documents.
Emphasize "Web Content Accessibility Guidelines".

> "Extended audio description can provide the additional information they needed to understand the video"

It should either read:

"Extended audio description can provide the additional information needed to understand the video"

or:

"Extended audio description can provide the additional information they need to understand the video"

————

> "A live text caption service will enable live audio to be accessible to people who are Deaf or hard of hearing, or who cannot otherwise hear the audio."

"deaf" should be written with a lower case "d".

————

> "In these cases there are number of different reading orders for a Web page that can satisfy the Success Criterion."

There is an "a" before number missing.

————

> "The arrow is clearly labeled with "Next" and the instructions state, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the lower right below the last survey question." This example uses both positioning, color and labeling to help identify the icon."

Shouldn't it be "…in the lower right corner…"?

————

> "The intent of this Success Criterion is to encourage authors who are using technologies that are capable of achieving a specific visual presentation to enable people who require a particular visual presentation of text to be able to adjust the text presentation as required."

What are authors encouraged to do? It's not said in this sentence.

————

> "Rather, it means that content that uses analog, time-dependent input cannot conform to this Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA."

Shouldn't that be path-depending instead of time-depending?

————

> "An essential animation can be paused without effecting the activity"

Shouldn't it be "affecting the activity"?

————

> "A test is designed so that time to complete the test does not effect the scoring"

Shouldn't it be "affect the scoring"?

————

> "This allows access by people with cognitive limitations or attention disorders to be able to focus on the content."

Seems like there are two sentences that were connected without rearraging the verbs.

————

> "Some common examples of technical terms include: Homo sapien, Alpha Centauri, hertz, and habeas corpus."

Must read Homo sapiens

————

> "A skip to navigation link is provided to navigational content at the end of a page. The link is consistently located at the top of each page so that keyboard users can easily locate it when needed."

First it says that the link is at the end of the page, then it says it's at the top?

Also: is "to navigational content" correct or should it read "to navigate content"

————

> "If the references to the next page read "page 1", "page 2", "page 2" etcetera, the labels are not the same but they are consistent."

Is it correct that page 2 is repeated? Schouldn't that read "page 3"?

————

> "In the case of an unsuccessful form submission, users may abandon the form because although they may be aware that an error has occurred, they may be unsure of how to correct the error even though they are aware that it has occurred."

even though they are aware that it has occurred. <- this is repeated in this sentence!

————

> "whether there are no workarounds if the Success Criteria is not met"

"… criteria are …" or "… criterion is …"

————

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Jan/0013.html:

> Major sections of the document are pages titled title "Understanding Guideline X" and "Understanding Success Criterion X."

..."pages titled title..." – the second title should be deleted here.


From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0000.html:

> Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size.

What is ex in this context supposed to mean? Or should it read e.g.?


> For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.

Shouldn't "large-scale" not be in front of tex? ..."to successfully present images of large-scale text to a user."


From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0002.html:


during the translation of the latest version of "Understanding WCAG" <http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/complete.html> into German we found some link errors:

> (Success Criteria <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-pause">2.2.3</a>, <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-no-exceptions">2.2.4</a> and <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-server-timeout">2.2.5</a> may also apply.)

2.2.3 links to 2.2.2, 2.2.4 links to 2.2.3, whereas 2.2.5 is correct


The following link points to the wrong definition / fragment identifier (two instances)

> (no <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#videodef" class="termref">audio</a> and no interaction)