Disposition of comments for the Accessibility Guidelines Working Group

https://github.com/w3c/wcag/pull/8

Refer to the technique "H80: Identifying the purpose of a link using link
text combined with the preceding heading element" at
http://www.w3.org/TR/WCAG-TECHS/H80.html.

Under User Agent and Assistive Technology Support Notes, note the sentence
- 'The command to take advantage of this technique in JAWS is "JAWS KEY +
T".'

Now, Ins + T or the JAWS key + T is a command that announces the page
title, and has no bearing on this technique whatsoever. The command to be
used here is the list of headings, which is the JAWS key + F6. Consider
revising it to reflect the correct JAWS command.

It seems pretty important to note that most user agents do not support navigating between headings, and not a single one support navigating frames (H70) or maps (H50). To my understanding that means that in practice none of these techniques can be relied upon except in the extremely rare situation where someone is on a closed network using Opera (which has no screen reader support as far as I’m aware). It seems to me that a warning for this would be in order.

This comment is part of the project for the Accessibility Support Database.

This technique is a great idea, but it’s not sufficient to meet success criterion 1.4.1. There is no allowance in 1.4.1 for information to be conveyed through color alone as long as those colors have a large contrast ratio. There is simply nothing in the criterion that mentions any such thing. So even though this makes sense as a technique, this exception is not permitted by the normative part of WCAG and so it can not be considered sufficient. Since this is still a pretty good idea, it’s best to make this technique an advisory technique.

Proposed Change:

Dear Shawn, dear group,

The major question that we have as developers of accessibility
evaluation tools is whether the XML source documents [1]
are also updated synchronously with this and future releases of the
techniques' documents.

It would also be very important for us to find out whether the
repository [2] can also be considered as the official techniques
repository. And whether GitHub can also be used to report issues. We
would welcome such approach to support traceability of any change.

[1] http://www.w3.org/WAI/GL/WCAG20/sources/
[2] https://github.com/w3c/wcag/
--
Best Regards,

Dr Carlos A Velasco
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center: http://imergo.com/ · http://imergo.de/
Schloss Birlinghoven, D53757 Sankt Augustin (Germany)
Tel: +49-2241-142609 · Fax: +49-2241-1442609

Comment (Including rationale for any proposed change):
NOTE: Below is a rough summary of EOWG participants' comments, which EOWG did not have time to polish and approve. Please see the direct perspectives archived at <https://www.w3.org/WAI/EO/wiki/WCAG_Comments_February_2014#alt_issue>

EOWG is glad that the WCAG WG is developing more WAI-ARIA Techniques. However, in reviewing the issues around ARIA10 and F65, we have significant concerns that misunderstandings would lead to lack of appropriate alternative text for many users. Allowing aria-labeledby and not requiring the HTML alt attribute could lead to misuse of aria-labeledby when the alt attribute is a better solution.

The use cases cited and the examples in ARIA10 do not seem compelling enough balanced against the risk of misunderstandings that could lead web authors to conclude that aria-labeledby can be used interchangeably with the HTML alt attribute. Additionally, if HTML alt attributes were no longer a clear requirement, it would "muddy the water" for less careful developers and more of them would just not put any alternative text at all.

Givens: 1. aria-labeledby is not supported by the tools that many people still use today. 2. Many developers don't understand accessibility-support. 3. Some developers like to use the latest hot markup just for the sake of it. Thus a likely scenario: some developers use aria-labeledby in cases where the alt attribute is a better solution, just because it's new, and not realizing its limitations. We also find compelling that alt attributes display onscreen when images are disabled and aria attributes do not, thus the outcomes are not equivalent.

EOWG asks the WCAG WG to continue to consider how this issue is addressed. Perhaps allowing aria-labeledby instead of HTML alt attribute is not worth the risk? If the WCAG WG decides to leave ARIA10 and amend F65, we strongly urge you to provide very clear guidance about use and cautions, for example, advising authors that the alt attribute is the best solution for providing alternative text in almost all situations, and should be used whenever; and including the cautions about using aria-labeledby instead of the alt attribute. (Probably this goes in Understanding and linked to from the Techniques?)

https://github.com/w3c/wcag/issues/17

http://www.w3.org/TR/WCAG-TECHS/F17.html and https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml

The expected result is formulated wrongly:

"If step #1, step #3 or step #4 is true or step #2 is false, then this failure condition applies and the content fails the success criterion."

# Proposal:

"If step #1 is true or step #2 is false or step #3 is false or step #4 is false, then this failure condition applies and the content fails the success criterion."

In the file:

https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml

i.e.:

http://www.w3.org/TR/WCAG-TECHS/F17.html

"For client-side image maps, check that the value of the usemap attribute has a corresponding id value if the usemap attribute is not a URI."

According to the HTML 4.0.1 specification the usemap attribute must be an URI and must match the value of the name attribute of another map element.

https://github.com/w3c/wcag/pull/9

This technique doesn’t test for anything specific in HTML. The proposed solution in this technique can be applied in any technology. There is actually nothing in this technique other then it’s identifier that would have to change for this technique to be a general technique. Making this a general technique would mean it would be applicable to other technologies.

This comment is part of the project for the Accessibility Support Database.

This technique doesn’t test for anything specific to CSS. Changing the style of components on a web page using some kind of style switch can be done in any technology using the method described in this technique. Making this a general technique would mean it would be applicable to other technologies.

This comment is part of the project for the Accessibility Support Database.

This technique doesn't test for anything specific in HTML. Many technologies can reflow the way is described in this technique. Making this a general technique would mean it would be applicable to these technologies.

This comment is part of the project for the Accessibility Support Database.

Refer to the failure technique, 'F76: Failure of Success Criterion 3.2.2
due to providing instruction material about the change of context by change
of setting in a user interface element at a location that users may bypass'
at http://www.w3.org/TR/WCAG-TECHS/F76.html.

Note the title of the failure technique and then note that the failure is
not due to providing instructional material but due to lack thereof.

Suggested change: 'F76: Failure of Success Criterion 3.2.2 due to lack of
instruction material about the change of context by change of setting in a
user interface element at a location that users may bypass.'

-Devarshi

G183: Using a contrast ratio of 3:1 with surrounding text and providing
additional visual cues on focus for links or controls where color alone is
used to identify them

URL: http://www.w3.org/TR/WCAG-TECHS/G183.html

#A. Under Note 2, where it says, "e.g., black text in a paragraph on a
white background with the links shown as one of the colors in the list
below," the sentence would be better understood when 'list' is replaced by
'examples.'
#B. Under Procedure - #1, remove the repetitive word 'used.'

G200: Opening new windows and tabs from a link only when necessary
url: http://www.w3.org/TR/WCAG-TECHS/G200.html

Under description:
A. What does 'outside of the secured scope' imply in #2?
B. 'It is recommend' should be 'It is recommended.'

G192: Fully conforming to specifications

URL: http://www.w3.org/TR/WCAG-TECHS/G192.html

Under Examples, correct the sentence "It is run though ..." to "It is run
through ...."

Refer to technique "G178: Providing controls on the Web page that allow
users to incrementally change the size of all text on the page up to 200
percent" at http://www.w3.org/TR/WCAG-TECHS/G178.html.

1. Under Description, first para, second sentence: "Many people with low
vision do not use magnifying software, and they may not be familiar with
browsers text size adjustments.." The word "browsers" is incorrectly used
here. Depending on its usage, consider replacing it with either [browsers']
or [browser's].
2. Under Description, first para, last sentence: "It may also be true of
some people with cognitive disabilities who also require increased font
size." The second occurrence of 'also' is not required.
3. Fourth para, replace 'ex' by 'e.g' and spell check 'hight'.
4. In the fifth para (sentence), spell check 'situtions.'

Comment Type: editorial
Summary of Issue: minor editorial: In ARIA Techniques<http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140107/complete-diff.html#wai-aria_ua_suppor
Comment (Including rationale for any proposed change):
minor editorial: In ARIA Techniques<http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140107/complete-diff.html#wai-aria_ua_support>, capitalize "W3C Recommendation" in:
"
Accessibility Support for WAI-ARIA
Using technologies in an Accessibility Supported way is required for conformance claims. Read more about Accessibility Support. The WCAG Working Group plans to review which WAI-ARIA techniques are sufficient when Accessible Rich Internet Application specifications reach W3C recommendation status. ...

A number of the PDF example documents supporting the PDF techniques remain incorrect. Digital Access at Vision Australia have previously notified the W3C of the specific errors within these documents. The incorrect examples are likely to cause confusion for those that are new to implementing these techniques so we would suggest the examples are updated.

It appears that this HTML technique is a duplicate of http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20051123/#H93, however, this H93 is of a different subject matter compared to the H93 referenced in the URL above.

Proposed Change:
Change in numbering of this (or the other H93) to keep both techniques as their own separate technique.