Disposition of comments for the Accessibility Guidelines Working Group

The example of technique G191 makes it clear that the link or mechanism to load a non-blinking version of the page should be at the top of the page:

"A link at the very top of the page reloads the page with the blinking text replaced with text that is styled to be highly visible but does not blink"

Proposed Change:
Include a check that the mechanism is located at the top of the page - placed elsewhere, it is not helpful. Instead of
"1. Check that there is a mechanism to reload page to turn off blinking."

change to:

"1. Check that there is a mechanism at the top of the page to reload page to turn off blinking.

The test for the correct use of longdesc should be conditional on its application in the first place. The first check

1. Check that the img element has a longdesc
attribute.
is not meaningful for any img and redundant for those that actually carry the longdesc attribute.

(The descripton may also mention the drawback that alternative text via longdesc is not usually accessible to sighted users and might therefore be supplied redundantly.)



Proposed Change:
So the test in my opinion should start with a conditional:

"If longdesc is used on images to supply alternative text:"

...then test #2 and #3 (as #1 and #2)

To test if noembed fulfills its purpose, a test for the equivalence of content inside the noembed element is necessary

Proposed Change:
Add:

3. Check if the content of the noembed element is an adequate alternative for the non-text content it replaces.

(#1 or #2) and #3 are true.

The test prescribes in
1. Check that all th elements have a scope attribute.

The scope attribute, however, is only necessary for complex data tables, the test gives the impression that it must be present in every th element.

Proposed Change:
Qualify the test by expressing ast the outset that it applies to complex data tables only, i.e.:

"For complex data tables where the relationship between heading cells and content cells must be explicitly specified because the table uses hierarchical headings or headings apply to multiple columms or rows (colgroup, rowgroup):"

Both the first sufficient technique quoted in "How to meet SC 1.4.4" as well as the fourth, G179, allow for designs where containers may be defined in px.

Proposed Change:
Unclear. The four options / sets of techniques offered to meet 1.4.4 seem somewhat contradictory.

Possibly qualify:

"When liquid layout techniques are chosen to satisfy SC 1.4.4:"

The lack of styling through CSS does not create in itself a real problem if semantic HTML markup is adhered to. Testing whether CSS has been applied appropriately seems difficult to do for all possible purposes.

When saying "Check whether CSS properties were used to control the visual presentation of text" the problem remains that this does not in itself show that CSS has been used correctly without further tests.

Proposed Change:
Test for use of deprecated elements (e.g., font, center, strike, i, b, u) instead.

In addition to the comment regarding the test case spec. in G178, it should be noted that for most web pages using several columns, the requirement for a 200% increase of text size will be impossible to meet (the same goes for browser based text-only resizing) and is therefore likely to be ignored. Such ignorance is helped by the interpretation of alternative options to meet Success Criterion 1.4.4 (Resize text), since option 1 (G142) suggests that supporting zoom resizing (which most modern browsers offer out of the box without any effort by the designer) is already sufficient. This appears as a disincentive regarding the provision of text-only resizing and the additional effort of creating fluid layouts that resize gracefully.

Proposed Change:
The (additional) requirement to allow a more modest text-only resizing (say, 150%) might raise the bar in a meaningful way and not de-incentivise designers in the same way as the current all-to-easy way of meeting success criterion 1.4.4 *without any effort*.

To decipher a heading, a screen reader user will have to remember the rule: "two blank lines preceding the heading" and "a blank line following a heading". This rule can easily get complex when other formatting options are introduced in the document structure to convey the structural meaning to different user groups. What happens when a hyperlink, underlined text, or a caption is to be expressed using plain text? The list goes on when we factor in other ways documents are currently presented. It only makes sense to have its plain text counterpart elicit same structural meaning using more intuitive encodings than line breaks and non printing characters.

Proposed Change:
Use mnemonics instead. Remove references to non printed characters and line breaks. There are richer ways to convey this information to all user groups.
For example, to express a heading in a plain text document, using (H)This is a Heading(H) will be easier to follow than the blank line format. Note that the enclosed character is a mnemonic for heading.
Using the same rule, a underline can represented as (U)This is an underline(U).
A hyperlink will be (HY)This is a hyperlink(HY).
This way even users groups will be able to understand a plain text document by visually parsing it.

If I understand this correctly, this is a technique to assist screen reader users. If that is true, there is no mention of the supporting assistive technology applicable to this technique. We should also state, if possible, where and how to obtain these scripts.

There is a good chance that a user may question the applicability of screen magnification software to decipher headings in plain text documents using formatting conventions.

On a sidebar, does this technique satisfy SC 1.3.1 on the basis that only a screen reader user can understand the underlying structure of the document?

Proposed Change: In the ‘Applicability’ section, add a sentence something like – “Only applicable to screen readers.”

I believe H93 and H94 are out of place. They are not HTML techniques but are evaluation techniques and must be listed under Failure techniques.
All HTML techniques explain how an element / attribute should be used to meet an SC and are positive like: Do this ... to accomplish this.
But H93 and H94 are: Do not do this else you will fail ...

There are serious deficiencies noted under user agent notes for H89 and it concludes with:
"Note: Current user agents and assistive technologies do not always provide the information contained in the title attribute to users. Avoid using this technique in isolation until the title attribute has wide-spread support." ... under Description.

The title attribute is as old as the hills and browsers and AT are not going to change their behavior in a hurry any time soon.
Context sensitive help text cannot be given via the title attribute. (In fact I tell clients this does not work and disuade its usage).
If it is not AT supported how is it a sufficient technique?
I suggest this technique be moved to advisory.

The behaviour described in F9 - changing context such as opening new windows or submitting the form - also seems to apply to the requirements of SC 3.2.2 "On Input".
The behaviour described: "removing focus from a form element, such as by moving to the next element, causes a change of context" is arguably even more disrupting than the more specific Failure F36: "Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value" - in the latter, the form might at least have been completed.

Proposed Change:
Extend applicability of F9 to SC 3.2.2 On Input AND SC 3.2.5 Change of Request

Opening a new window as a result of user text input is clearly an unexpected change of context and would seem to violate not just SC 3.2.5 (Change on Request) but also the A-level SC 3.2.2 (On input)

Proposed Change:
Either:
* Preferably, make F60 applicable also to SC 3.2.2 (On Input)
* Specify that the change in response to text input should be expected / explained before it occurs, include that in the test procedure
* Differentiate between opening a new window proper (i.e., a browser window) and opening a pseudo-window (e.g. a lightbox) which would not necessarily constitute a (disorienting) change of context

The FLASH17 technique can't be associated with this success criteria since the criteria says : "If keyboard focus can be moved to a component of the page using a keyboard interface,..."

And the FLASH 17 technique description says : "... it is not possible to move keyboard focus between the Flash content and HTML content without using a mouse ..."

So, it's not possible to move keyboard focus from HTML content to Flash content using a keyboard interface and SC 2.1.2 isn't applicable

Proposed Change:
remove FLASH 17 of sufficient technique list or change it for additional techniques

I have noticed a discrepancy between Technique "G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content" and the test included at its end.

While the technique proposes the use of descriptive labels which are exposed to sighted users, the test at the end checks for text alternatives for non-text content that would only be exposed if the not-text content cannot be displayed.

I think the currently included test does not apply to the technique as described.

Proposed Change:
New Test
Check whether descriptive label matches / correctly describes live audio-visual content

The first of the conditions may not apply (for example if the for is on one page). The second condition ("Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.") must be met in any case to ensure that input is checked and may be corrected. Therefore "Expected Results: Either #1 or #2 is true" seems inadequate.

Proposed Change:
1. If user data are collected in multiple steps, the user is allowed to return to previous steps to review and change data.

2. Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.

Expected Results

Checks #1 and #2 are true.

To remove the conditional (and possibly confusing) 'if'-clause at the beginning of check #1, the single test might need to be turned into two separate tests.

As it stands, the test in technique G166 only checks whether a link to the audio alternative is provided. It does not check the equivalence of the audio alternative. Testing just for the link is not sufficient

Proposed Change:
Add a second checkpoint #2 for checking whether the audio alternative is adequate.
Both Check #1 and Check #2 must be true.

The text of this technique describes in both examples provided that the styleswitcher should be at the "top of the page". This requirement, however, is neither included in the description nore is it checked in the test section of the technique.

Proposed Change:
Add a further (fourth) requirement for the technique to be used successfully, preferably in second place:

"2. The link or control on the original page must be placed at the top of the page"

Following the provision of Technique G4: "If keyboard shortcuts are used, they are documented" the test in G187 should include a check whether the function to turn off blinking content is documented (e.g., press the "Escape" key to turn off blinking)

Proposed Change:
Add a fourth checkpoint and extend the final statement:

4. Check if the browser's stop animation command (usually the Escape key) is described in the immediate context of the blinking content.

Check #3 and #4 are true.

The test mandates the use of fieldset for any logically related group of input elements while the description of the same technique allows:

"When a small group of related radio buttons includes clear instructions and distinct selections it may not be necessary to use fieldsets and legends"

Proposed Change:
Have a conditional at the beginning of the tests:

"For any group of logically related input elements that is not small easily identified in its labels or titles"

..or similar

Since there are three dfferent ways to set font sizes that can be enlarged via text scaling in IE, testing any one of them seems not very meaningful.

The same comment refers also to C13 and C14.

Proposed Change:
The test for techniques C12, C13, C14 should encompass %, em, font size names or alternatively, exclude the use of px and pt

The test as it stands is not particularly useful as it does not specify the viewport size, which will have an effect on scalability and occurrence of clipped text and text overlapping. It also does not specify what it means that "text size can be increased to 200% of the original size" - is the requirement that the text is still legible / not clipped?

Proposed Change:
If the test is to determine whether enlarged text is still usable / legible (and this is the only meaningful test), the viewport / window size to be used in the test must be specified (WAT and Web developer toolbar allow the setting of the window to 1024 x 768 px, for example), and criteria for compliance must be given (e.g. "the text is still fully legible (i.e. no parts are clipped, boxed do not overlap).

The description of SCR21 has it that "the innerHTML property is not part of the DOM specification and thus should be avoided".
innerHTML is part of the (emerging) HTML5 spec
(http://www.w3.org/TR/html5/apis-in-html-documents.html#innerhtml) and also used widely in JS-Frameworks.

Proposed Change:
Check whether the use of innerHTML creates any accessibility problems. If not, the description and test procedure should be updated to allow innerHTML.

I think it is time that G1 along with the "NOTE:" at the end of the description be modified and made more forceful. Presently, it does not give the impression that the "Skip to..." MUST be visible. I would like to see the description reworded to make it more assertive.
*******************
Currently, G1 with the note (and the ensuing wording), comes across as a weak technique.
*******************

Proposed Change:
The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating the VISIBLE link sets focus beyond the other content to the main content. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.

Note: VISIBLE LINKS MUST BE VISIBLE AT ALL TIMES, ESPECIALLY for KEYBOARD USERS. KEYBOARD USERS INCLUDE switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.

Also: http://lists.w3.org/Archives/Public/public-comments-wcag20/2010Sep/0023.html
Update on my earlier post - G1: Adding a link at the top of each page that goes directly to the main content area

I think the verbiage with the word "Must" would be incorrect in my previous post.

Sorry about that...

thanks,
Devarshi

Proposed Change:
please note the updated text (changes highlighted in UPPERCASE):

*********************
The objective of this technique is to provide a mechanism to bypass REPETITIVE NAVIGATION MENUS AND OTHER PAGE ELEMENTS on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating THIS link sets focus INTO ONE OF THE PAGE ELEMENTS IN THE main content AREA. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.

Note: Visible links are IMPORTANT for USERS navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.
*********************

It might be useful to clearly indicate the definition of the words "should" and "must" for the purpose of requirements versus recommendations. This would apply to all parts of WCAG 2.0. I mentioning it here on this technique (G141), because this is where I recently had a debate about what "should" means versus what "must" means.

Proposed Change:
Make it obvious that "should" is recommended while "must" is required. You could use the definitions found at http://www.ietf.org/rfc/rfc2119.txt. You could also consider making the words "must" and "should" hotlink to the definition. Or, not. Just an idea.

See old exchange on this topic below.
Now I refer to Techniques working draft (latest) of Oct 2010.
See http://www.w3.org/TR/WCAG20-TECHS/html.html
H42 refers to proper use of headings for SC 1.3.1 and H69 for use of headings to skip blocks (SC 2.4.1).
But part of the description under H69 which was correctly placed under h42 is now moved to h69... and is completely out of place.
Refer to:
"In some technologies, headings are designed to convey logical hierarchy. Skipping levels in the sequence of headings may create the impression that the structure of the document has not been properly thought through or that specific headings have been chosen for their visual rendering rather than their meaning. Authors are encouraged to nest headings hierarchically. When headings are nested hierarchically, the most important information is given the highest logical level, and subsections are given subsequent logical levels.(i.e., h2 is a subsection of h1). ..."
Again this Web page is about HTML techniques so why does this description start with "In some technologies"? Does it apply to HTML / XHTML or not?
And the note for example #2 of H42 refers to skipping blocks of content.
Refer to:
"Note: It is important to note that the example code below is intended to show how headings can be used to bypass blocks of information. It is not intended to prescribe what level of heading should be used for a particular section of the web page."
So why is this note and example under H42?
Completely out of place again.

The technique is one and the same: proper use of headings. And it serves two purposes and SCs. So merge the techniques into one instead of running around in circles. I had suggested this in 2009.
There are several techniques that refer to multiple SC. So I fail to understand your resistance for this one.

Sailesh Panchang
Web Accessibility Specialist
www.deque.com

--- On Mon, 12/1/08, Loretta Guarino Reid <lorettaguarino@google.com> wrote:

From: Loretta Guarino Reid <lorettaguarino@google.com>
Subject: Re: HTML Headings technique: duplicated
To: "Sailesh Panchang" <spanchang02@yahoo.com>
Cc: public-comments-wcag20@w3.org
Date: Monday, December 1, 2008, 5:58 PM

On Fri, Nov 14, 2008 at 1:23 PM, Sailesh Panchang <spanchang02@yahoo.com> wrote:



H42: Using h1-h6 to identify headings

relates to SC 1.3.1

H69: Providing heading elements at the beginning of each section of content

relates to SC 2.4.1



Comment: Both descriptions are essentially the same. I suggest they be merged into a single technique and reference both SC

Thanks,

Sailesh Panchang

================================
Response from the Working Group
================================

H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have moved the discussion and examples of ways to use headings to organize content from H42 to H69. See http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H42.html and http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H69.html .

Failure F3 looks specifically at using CSS to include images that convey important information. Part of the rational of this is 'Embedding information into a background image can also cause problems for people who use alternate backgrounds in order to increase legibility and for users of high contrast mode in some operating systems. These users, would lose the information in the background image due to lack of any alternative text.'

I totally agree with this rational, however very recently there has been a trend to either code images as background in the HTML or create them as backgrounds using scripting. It doesn't matter what method is used, the effect is still the same, when those of us who need to over-ride specified colours do so we lose the image and when those images have functionality, eg buttons on plug-in editors (I've been in contact with the AGAT 2 people), we really are stuffed.

Personally I time this trend with the advent of IE8, in that it no longer displays the alt attribute text as a tool tip. To get over this web designers seem to have taken to coding the images as backgrounds to be able to use the title attribute instead. Fine if you're using a mouse and not over-riding specified colours, but a nightmare for those of us with colour access needs. When the images are multiple and set close together, as with the editor buttons, it becomes impossible to work.

Proposed Change:
Either expand F3 to include all methods of coding images in such a way that they disappear when in over-ride or create a new failure to cover these additional issues.

Re FLASH15 technique -

Example 1, last sentence - it seems the link should be "source of Using
tabindex to navigate a column structure" since it links to a fla file and
the working version is already provided by the link in the previous
sentence.

Expected results - #4 is missing. Should be "Checks #2 and #4 are true".

The last two lines of the test in G123 convey the same thing.

Proposed Change:
Delete list item 5 of the test: "Check that after activating the link, the keyboard focus has moved to the content immediately after the block."

Refer to the text, "In the content call the up the class" in Examples 1 and 2 respectively.

Proposed Change:
First Instance:
In the content call up the class = "left"
Second Instance:
In the content call up the class = "right"

The header text "Failure Example 4: Specifying only background color with CSS" does not reflect the correct code snippet. Instead, the code following this header highlights the use of foreground color using CSS.

Proposed Change:
Failure Example 4: Specifying only foreground color with CSS

I am not clear about the use of the word, "proved" in the description, "The alt attribute must be proved and have a null value (i.e., alt="" or alt=" ") to avoid a failure of this Success Criterion."



Proposed Change:
1st suggestion:
"The alt attribute must be used and have a null value (i.e., alt="" or alt=" ") to avoid a failure of this Success Criterion."
2nd suggestion:
"The alt attribute must be provided and have a null value (i.e., alt="" or alt=" ") to avoid a failure of this Success Criterion."

Procedure #2 reads "leave the content open for 24 hours". I can live with this, but leaving the content open for 24 hours is not a realistic way. 1 hour or even half an hour would also be fine.

Proposed Change:
Why "24 hours"?
Had better change it so that the authors can test the content in reality.

Comment (Including rationale for any proposed change):
Procedure #1 reads "Check that a procedure and policy is in place to ensure that text alternatives are delivered in real-time." Does this technique require having the procedure and policy only? Can we meet SC 1.2.9 by only having them? This technique should ensure that the text based alternatives for live audio-only content are provided.

Proposed Change:
Need clarification.

Is "WAI(Web Accessibility Initiative)" NOT acceptable to meet SC 3.1.4? This also can be used "to make the expanded form of an abbreviation available by associating the expanded form with its abbreviation". In Japanese, this is usually used to provide its expanded form.

Proposed Change:
If acceptable, please add the description to G97. If not acceptable, JIS might need to have different criterion from WCAG 2.

Comment (Including rationale for any proposed change):
It should have links to SC 1.2.4 documents as G93 is listed as one of the sufficient techniques on Understanding SC 1.2.4.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-real-time-captions.html#media-equiv-real-time-captions-techniques-head

Proposed Change:
Add links.

Expected Results should be "#3 is true." as well as SM6.

Proposed Change:
Change it to read "#3 is true."

Both SM6 and SM7 should have links to SC 1.2.5 documents.

They are also listed at:
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/media-equiv-audio-desc-only.html#media-equiv-audio-desc-only-techniques-head

Proposed Change:
Add links.

Please add (or move) the summary or Collections of Techniques currently found in the "Overview"page to the Contents page. It would fit nicely after the Abstract and inside or just before the Table of Contents. Having a collapsed list of the types of Techniques would help with the extra long contents list.

Proposed Change:
Add (or move) this "Techniques Collection" summary section from the Overview page
http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/intro.html#intro-tech-types
to the Contents page
http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/
to improve the readablilty and use of the extra long table of contents.

One suggestion for G164.
• G164: Providing a stated period of time after submission of the form when the order can be updated or canceled by the user
Suggested title for G164:
Clearly indicating the time within which an online request (or transaction) may be amended or cancelled by the user after first making the request
Another example for consideration:
A bank permits users to pay bills or transfer funds between accounts by submitting online requests. A link that allows users to edit or cancel requests is available against every request. The link is disabled one business day prior to the scheduled transaction date. The form for submitting online requests has the following notification just before the submit button:
You can amend / cancel this request up to two days before the scheduled transaction date.

Refer to example-1 under H63
The table below is the code for the Contact Information table but the heading above it says "A simple schedule". This is incorrect. Maybe it should be:
"Contact Information table"

I believe SCR 19 helps one to comply with SC 3.2.2 too.
SCR19: Using an onchange event on a select element without causing a change of context
At present this technique is only linked to SC 3.2.5. But if one reads the description and examples for SC 3.2.2, the need for the suggested linkage will be clear.

Hello,
We are currently completing the translation of Understanding WCAG 2.0 based on changes made in the October 14, 2010 version.
One part of the work of our group is to translate the titles of the new Flash techniques.
In our opinion, the title of technique Flash34 is too restrictive as it only talks about screen reader detection.
However, in the technique itself, note 3, it stands that "Other assistive technology tools, including screen magnifiers, or tools not used as assistive technologies may also utilize MSAA in ways that result
in Accessibility.active being set to true.
".
As the property accessibility:active does not only concern screen readers, we suggest that "screen readers" be replaced by "assistive technologies", to prevent from confusing the reader who may think that this technique is only related to screen readers.

Proposed Change:
Using assistive technology detection to turn off sounds that play automatically

Is there a reason why Technique H82 is missing from the latest versions or is this an oversight?

Dear all,

during the translation of Flash Techniques for WCAG into German we found a few more errors or omissions.

Thanks for clarification,

Tomas Caspers



----

> Each following role contains a question and a radio button in each cell corresponding to answer choice in the three columns.

Shouldn't that be "row" instead of “role“?

----

> Check that a label element associates the text with all input elements of type "radio", "checkbox", "text", "file" or "password", for all textarea elements, and for all select elements

Shouldn't that be "with all textarea elements, and with all select elements"?

----

> The id reference list contains one or more unique element id's.

id's ist not a Genitive - it's just a plural so there shouldn't be an apostrophe I think.

----

> Note: Note: At this time, WAI-ARIA is a Working Draft.

Note appears twice.

----

> Flash player is often used to display video, and it provides support for text tracks which can be used to provide closed captions or subtitles in any language, and it also support multiple tracks of audio, thereby enabling support for video description, and support for multiple video tracks, enabling the delivery of sign language interpretation for audio-visual content.

...it also support... there is an "s" missing in the word support - should read "supports".

The last part of the sentence would be easier to understand if it would either be: " ... and it supports multiple video tracks.." or else " ...and it provides support for multiple video tracks.... "

----

> The Flash Player supports the ability for authors to control which graphics appear to assistive technologies using the silent property of the accessibility opbect, as indicated in the examples below.

object is spelled wrong (obpect)

----

> The hotspot are implemented as invisible Flash buttons, which are each given an accessible name that describes the hotspot's target.

Should either read "the hotspot is" or "the hotspots are"

----

> When focus has been placed inside the Flash movie, press the tab order repeatedly to traverse its contents by keyboard.

Should one press the Tab key?

----

> The objective of this technique is to demonstrate how to invoke a scripting function in a way that is keyboard accessible by attaching it to keyboard-accessible, standard Flash components provided by the Adobe Flash Profressional authoring tool.

Should be Professional (without the r after the Prof)

----

> 'swfNext-<next ID>', where '<next element>' should be the ID value of the next element in the tab order.h

What is the h after the period supposed to mean?

----

> The working example of Providing a button in the HTML before the Flash object to stop sound is available.

Should read: The source of ....

----

> The working version of A thick blue border to indicate focus is available.

Should read: The source of ....

----

> This example is the same as example 2, except using ActionScript instead of the accessibility control panel in the Flash Professional authoring tool.

This text is the text of example 2 - so it can't be the same as example 2

----

> Ensure that the textual descriptions for each form control within the flash application is placed adjacent to the control itself.

textual descriptions is a plural form, the verb (is) is singular.

----

> Open a web page containing an embedded flash objects

Flash objects should either be in the singular or the verb should be plural

----