W3C

List of comments on “Techniques for WCAG 2.0” (dated 6 March 2014)

Quick access to

There are 20 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2957: Remove layout table section from H39 and H73
Commenter:
Context: H39: Using caption elements to associate data table captions with data tables
assigned to Andrew Kirkpatrick
Resolution status:

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

H39 and H73 don't need to mention layout table cases because F46 describes common failure cases of layout tables.

H39: Using caption elements to associate data table captions with data tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H39.html

H73: Using the summary attribute of the table element to give an overview of data tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H73.html

F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F46.html

In this pull request,

Changed layout table sentence in description to a note
Added F46 to related techniques
Tweaked related techniques in H39 to align with H73 and F46
Removed layout table check procedures in tests
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2912: ARIA19 issue
Commenter: Alistair Hastings <alistairhastings@yahoo.com> (archived message)
Context: ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
assigned to Andrew Kirkpatrick
Resolution status:

Example 1 in ARIA 19 does not work with the latest version of JAWS and IE9/10/11. Is this a known issue, or is a there a more current technique for making dynamic DOM elements accessible?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2952: Remove SCR2
Commenter:
Context: SCR2: Using redundant keyboard and mouse event handlers
assigned to David MacDonald
Resolution status:

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

... as SCR2 is redundant.

SCR20 provides more generalized and comprehensive information. We should remove SCR2.

SCR2: Using redundant keyboard and mouse event handlers
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SCR2.html

SCR20: Using both keyboard and other device-specific functions
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SCR20.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2960: ARIA2 Remove "when there is a visual cue to this effect." from objective.
Commenter:
Context: ARIA2: Identifying a required field with the aria-required property
assigned to Andrew Kirkpatrick
Resolution status:

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

The application of ARIA2 should not be limited whether "there is a visual cue to this effect." Because there could be audio or other sensory cues if authors use CSS or JavaScript. Also, the "Tests" procedures don't check whether "there is a visual cue to this effect."

We should remove "there is a visual cue to this effect." from the objective.
takenspc ARIA2 Remove "when there is a visual cue to this effect." from object…
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2959: Remove "WAI-ARIA is a Working Draft" from ARIA2
Commenter:
Context: ARIA2: Identifying a required field with the aria-required property
assigned to Loretta Guarino Reid
Resolution status:

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

Because WAI-ARIA 1.0 is a Recommendation.
http://www.w3.org/TR/2014/REC-wai-aria-20140320/
takenspc Remove WAI-ARIA is a Working Draft from Notes
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2958: Remove ARIA4 and ARIAe
Commenter:
Context: ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
assigned to Andrew Kirkpatrick
Resolution status:

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

We should remove ARIA4 and ARIA5 because they are

too ambiguous for both authors and auditors
technically incorrect
Too ambiguous

Both techniques don't provide helpful information for authors and auditors considering that WAI-ARIA Rec. contains limited examples. We should provide more specific techniques like design patterns of WAi-ARIA Authoring Practices.

http://www.w3.org/TR/wai-aria/
http://www.w3.org/WAI/PF/aria-practices/

Technical correctness

For ARIA 4, people who use assistive technologies may unable to operate user interface components when

states and properties are not correctly exposed
focus is not correctly managed (ex. "application" role in a page which doesn't contain JavaScript)
For ARIA 5, people who use assistive technologies may unable to operate user interface components when

roles are not correctly exposed
focus is not correctly managed (ex. "aria-activedecendant" in a page which doesn't contain JavaScript)
We could add failure example like "incorrect roles are exposed" or "incorrect states or properties are exposed" but I don't think they are necessary.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2961: Remove example 1 from ARIA7
Commenter:
Context: ARIA7: Using aria-labelledby for link purpose
assigned to Jonathan Avila
Resolution status:

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

Changing accessible name from rendered/visible text generally causes accessibility issues. Especially, changing accessible name completely different one from rendered/visible text causes serious accessibility issues.

ARIA 1.0 Recommendation provides some examples of similar issues. In a note of |aria-hidden|
http://www.w3.org/TR/2014/REC-wai-aria-20140320/states_and_properties#aria-hidden

Note: Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control. Similar problems may also arise for screen reader users. For example, a sighted telephone support technician may attempt to have the blind screen reader user click the "Go to checkout" link, which they may be unable to find using a type-ahead item search ("Go to…").
As Example 1 of ARIA7 changes accessible name from "Read more..." to "Storms hit east coast", people who use voice control or who are blind and communicating with sighted person may face issues.

Thus we should get rid of Example 1 of ARIA7.
takenspc ARIA7 Remove Example 1
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2950: Clarify uniqueness of F17
Commenter:
Context: F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient info...
assigned to Andrew Kirkpatrick
Resolution status:

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

Currently uniqueness or necessity of F17 is unclear. F17 discusses

uniqueness of id attribute
correctness of referencing id or unique identifies (for, headers, usemap attributes)
uniqueness of accesskey attribute
However F77 and F62 discusses most of them.

F77 discusses uniqueness of id
F62 discusses correctness of referencing id or unique identifiers
F68 discusses that in for attribute
F90 discusses that in headers attribute
Remaining issue is uniqueness of accesskey attribute. So we should remove other issuse from F17.

F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML
F62: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine specific relationships in XML
F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association of label and user interface controls not being programmatically determined
F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID
F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content via the headers and id attributes
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2955: Clarify the diffrence between F40 and F41
Commenter:
Context: F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redire...
assigned to Andrew Kirkpatrick
Resolution status:

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

F41 discusses the reloading the page and F40 discusses the redirecting the page. Currently, however , the difference between the two common failures are not clear. We should clarify the difference.

F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redirect with a time limit
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F40.html

F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh with a time-out
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F41.html

In this pull request,

Changed summary of F41 to make its objective clear
Reloading without user permissions is an issue regardless of refresh interval
Removed Example 2 of F41 because it's an example of F40
Removed SVR1 from related techniques of F41 because SVR1 discusses redirecting not reloading
Added SVR1 and H76 to F40 as related techniques (now authors can fix their issues)
Changed tests in F40
Make the test fails in case content="0"
Reloading without user permissions is an issue regardless of refresh interval
Make the test not fail in case content attribute contains "; url="
It's a failure of F40
(bonus) Added lang attribute to html element
H76: Using meta refresh to create an instant client-side redirect
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H76.html

SVR1: Implementing automatic redirects on the server side instead of on the client side
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SVR1.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2951: Remove F42
Commenter:
Context: F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting e...
assigned to Andrew Kirkpatrick
Resolution status:

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

F42 discusses two issues; keyboard support and semantics. F54 and F59 discuss each issue. Thus F42 is redundant and we should get rid of it.

F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting events to emulate links in a way that is not programmatically determinable
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F42.html

F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F54.html

F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F59.html

Keyboard Support

In F42,

A control or link created in this manner cannot be tabbed to from the keyboard and does not gain keyboard focus like other controls and/or links.
This is discussed in F54.

When pointing device-specific event handlers are the only mechanism available to invoke a function of the content, users with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as users who must use alternate keyboards or input devices that act as keyboard emulators will be unable to access the function of the content.
Semantics

In F42,

If scripting events are used to emulate links, user agents including assistive technology may not be able to identify the links in the content as links.
This is discussed in F59.

Many HTML elements have well defined roles, such as links, buttons, text fields, etc. Generic elements such as div and span do not have any predefined roles. When these generic elements are used to create user interface controls in HTML the assistive technology may not have the necessary information to describe and interact with the control.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2956: Remove F48
Commenter:
Context: F48: Failure of Success Criterion 1.3.1 due to using the pre element to ma...
assigned to Loretta Guarino Reid
Resolution status:

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

Remove F48,

it's same as F34
considering CSS white-space property, it can be said that any HTML elements may have white-space formatted information
F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F34.html

F48: Failure of Success Criterion 1.3.1 due to using the pre element to markup tabular information
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F48.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2953: F55: Remove Example 3 as it's same as Example 2
Commenter:
Context: F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using scri...
assigned to Loretta Guarino Reid
Resolution status:

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

Remove Example 3 as it's same as Example 2.

F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F55.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2954: Clarify F68 is applicable for controls that use visible labels
Commenter:
Context: F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association o...
assigned to Adam Solomon
Resolution status:

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

F68 is applicable for controls that use visible labels.

Applicability

HTML and XHTML controls that use visible labels
F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association of label and user interface controls not being programmatically determined
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F68.html

Thus we should remove unrelated example, related techniques and check conditions.

Example 3 is the same example of H65 which is a technique for controls that cannot use visible labels. So this pull request removed Example 3.

H65: Using the title attribute to identify form controls when the label element cannot be used
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H65.html

The aria-label and title are techniques for controls that cannot use visible labels. Thus this pull request removed related techniques and check conditions. As the aria-labelledby can be used for controls that use visible labels such as controls in the data table, this pull request doesn't modify that.

Additional changes are

Updated first sentence of test procedures to match notes of description (applicable input type is not limited to radio, checkbox, text, file or password)
Replaced "input element" to "control element" in test procedure to match "For all input elements ... and all textarea and select elements"
Make sure that ids in aria-labelledby are ids of the text label element instead of the control control
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2963: F89 confusing
Commenter:
Context: F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to using null ...
assigned to Andrew Kirkpatrick
Resolution status:

F89 is confusing. The title and procedure are not well-matched.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2939: use of H37 listed under Situations A and B remains unclear
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message)
Context: H37: Using alt attributes on img elements
assigned to Loretta Guarino Reid
Resolution status:

I have a question regarding some situations listed under "Sufficient
Techniques for 1.1.1 - Non-text Content" --
http://www.w3.org/WAI/WCAG20/quickref/#text-equiv, namely, Situation A: If
a short description can serve (supported by G94 etc.)... and Situation B:
If a short description cannot serve (supported by G95 etc.)...

Question: Can someone decide on the basis of the length of text string if a
short description can 'serve' or 'cannot serve' the same purpose as the
non-text content? For example, wouldn't it be more helpful to know to use
Situation A when the short description is less than 200 char etc.? A case
in point - H37 is listed under both Situations A and B, which means that
although not suitable, a 1200 char length alt attribute on a chart
(Situation B) can be implemented to claim conformance. Basically, how short
should be a short description?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2916: Make H79 title clearer
Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message)
Context: H79: Identifying the purpose of a link using link text combined with its e...
assigned to Andrew Kirkpatrick
Resolution status:

Current: H79: Identifying the purpose of a link using link text combined with its enclosing
table cell and associated table headings

The words 'table headings' may be construed for the table's caption or title and not column / row headings for the cell.

Proposed Change:
Change to: H79: Identifying the context for a link in a data table from table cell's content and headings associated for the cell
Or
Change to: H79: Identifying the purpose of a link in a data table using link text combined
with the table cell's content and headings associated for the cell

In fact the first format may be used for other such techniques (G53, H77, H78, H80) to make them briefer
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2917: ARIA1 needs example
Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message)
Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...
assigned to Andrew Kirkpatrick
Resolution status:

ARIA1 does not include an example for links. SC 2.4.4 lists this as a sufficient technique.

Proposed Change:
Consider
<p id="weather">What's the weather like? <a href="weather.htm" aria-describedby="weather">Click here</a></p>
Note: In this example the contextual text is read by screen readers automatically when the
link gets focus upon tabbing to it. One does not have to additionally activate a screen
reader specific keystroke figure out the context.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2918: Title does not fully reflect intent
Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message)
Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...
assigned to Andrew Kirkpatrick
Resolution status:

The technique's title is 'Using the aria-describedby property to provide a descriptive label for user interface controls'.
But the intent / objective is much wider and refers to 'descriptive info' for UI controls.


Proposed Change:
Change title for ARIA1 to:
Using the aria-describedby property to associate related description for user interface controls'
(Or 'detailed' in place of 'related').
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2919: ARIA1 needs 2.4.4 linkage
Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message)
Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...
assigned to Andrew Kirkpatrick
Resolution status:

ARIA1 is listed as a sufficient technique for SC 2.4.4 but ARIA1 does not list this SC
under 'relates to'.

Proposed Change:
Add SC 2.4.4 under 'relates to' for ARIA1.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2920: improvement for ARIA7
Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message)
Context: ARIA7: Using aria-labelledby for link purpose
assigned to Andrew Kirkpatrick
Resolution status:

While the aria-describedby (ARIA1) test procedure actually describes how the attribute can be used to satisfy certain SC by providing additional contextual info, the test procedure
for aria-labelledby (ARIA7) does not do this and only tests for correctness of id values.
Current:
Check that each ID in the value of the aria-labelledby attribute matches an ID of a text
element used as part of the link purpose.


Proposed Change:
Add: The Text referenced by the aria-labelled attribute adequately describes the link's
purpose.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:40:07 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org