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