W3C

List of comments on “Techniques for WCAG 2.0” (dated 3 January 2012)

Quick access to

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

1-20 21-39

question comments

Comment LC-2582: adjacent multiple image links
Commenter: Makoto Ueki <makoto.ueki@gmail.com> on behalf of JIS (archived message)
Context: H2: Combining adjacent image and text links for the same resource (H2 "Combining adjacent image and text links for the same resource")
Not assigned
Resolution status:

H2 title reads "Combining adjacent image and text links for the same resource". There can be a case that there are two a elements with img element which have the same href attribute and the same description, and they are adjacent. For example, One has image of text and the other is iconic photo.

Proposed Change:
Will H2 also be applied to this case? In other words, do authors have to put those images together in one link?

WAIC needs to clarify this in order JIS to harmonize with WCAG.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2684: Select roles in H91
Commenter: Kristjan <kristjanile@gmail.com> (archived message)
Context: H91: Using HTML form controls and links
assigned to James Nurthen
Resolution status:

Im not able to understand one thing in
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H91

<select> have roles “combobox, list, or dropdown list”.
There is only example when select is combobox.

Could you add an example when select has a role “list” or “dropdown list”? Im sure im not the only one with that question.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2773: ARIA1: Using the aria-describedby property to provide a descriptive label for input controls
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message)
Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...
Not assigned
Resolution status:

Refer URL: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/ARIA1
Note the statement made under 'User Agent and Assistive Technology Support
Notes' which states that IE 8 does not support aria-describedby at all. I
tested the aria-describedby property using JAWS 13 and IE 8 and it did work
barring minor issues. Therefore, I question the credibility of this
statement. Note that in IE 8, the aria-describedby property on the text
programmatically tied to the control is spoken twice (which could be due to
the use of landmark roles).

Proposed Change: Change the latter part of the sentence to read, "IE 8
partially supports aria-describedby ..."

-Devarshi
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2610: Procedure #2 & Note in Expected Results
Commenter: Makoto Ueki <makoto.ueki@gmail.com> on behalf of JIS (archived message)
Context: F61: Failure of Success Criterion 3.2.5 due to complete change of main con...
Not assigned
Resolution status:

It is difficult to interpret and translate the following parts:
--
Procedure #2.
Leave the content open for a length of time 10 times what a user could reasonably be expected to keep the viewport open for. For instance, a site's web analytics may indicate that average user visits last 1 hour and most return users visit once per day. 24 hours could be considered an appropriate length of time for the procedure.
--
Note:
Regardless of the time span used at step 2 of the procedure, if step 3 tests true after any length of time, then step 4 must be confirmed and the expected results evaluated as at 1.
--

Could you explain what you meant?

Proposed Change:
Need to clarification for us to translate and share the procedures with JIS X 8341-3.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2728: Visual styling
Commenter: Andrew Maier <andrew@uxbooth.com> (archived message)
Context: G182: Ensuring that additional visual cues are available when text color d...
assigned to Michael Cooper
Resolution status:

It appears the heading for this page is broken, failing to clear the navigation elements at the top of the page. Additionally, I believe that the footer shouldn't contain the elements "[begin add]" and "[end add]."


Proposed Change:
Fix the display of the header and remove extraneous elements from the footer.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2584: The description of what is sufficient to pass as a simple table is insufficient
Commenter: Charles Belov <charles.belov@sfmta.com> (archived message)
Context: in (H51: Using table markup to present tabular information)
assigned to Kathleen Wahlbin
Resolution status:

The text only indicates that use of the proper tags will constitute an accessible simple table. There is nothing addressing:

1. What headings are sufficient.
2. Where they must go.
3. What must be in them.
4. What distinguishes the table as simple.

I have seen tables with an occasional blank column 1 in a body row, or with the same content repeated for several rows in column 1 where the contents of column 2, being unique, would be suitable for the row heading.

Also, I have encountered misunderstanding that the heading for a row is the contents of column 1 of that row; that is, the word "heading" in English, as opposed to in the specification, is taken to only mean what the specification would consider a column heading.

It would be better for the specification to be explicit.

Proposed Change:
Tests
Procedure

Add:

3. Check that row 1 column 1 is either blank or describes the contents of the entire column 1.
4. Check that row 1 subsequent columns are not blank (i.e. contain "column headings"), describe the contents of the entire column, and allow the reader to distinguish the difference in meaning between that column and immediately preceding and following columns.
5. Check that column 1 subsequent rows are not blank (i.e. contain "row headings"), describe the contents of the entire row, and allow the reader to distinguish the difference in meaning between that row and the immediately preceding rows.

Expected results

Add:

If tests 4 and 5 cannot be met, either a complex table may be required or this table would need to be broken into multiple simple tables.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2703: Provide Technique(s) using PDF/UA
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
assigned to Loretta Guarino Reid
Resolution status:

PDF/UA provides technical detail pertaining to accessibility in PDF that developers find useful. PDF/UA covers a subset of WCAG 2.0 SC. AIIM's "Achieving WCAG 2.0 with PDF/UA" document is a good place to (at least) start in terms of establishing (from the WCAG WG's point of view) how PDF/UA can be used to meet selected WCASG 2.0 SC. In addition, PDF/UA provides a clear means of failing WCAG 2.0.

Proposed Change:
Create one or more Techniques that refers explicitly to one or more provisions of PDF/UA as an implementation-neutral means of providing specific technical advice for a wide variety of Success Criteria. Create a Failure Technique specifying that failure to meet PDF/UA (with whatever caveats) shall be considered Failure to meet WCAG 2.0.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2595: Older Versions - Informing Users
Commenter: Kerstin Probiesch <k.probiesch@googlemail.com> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

It seems that there are some problems concerning different versions of techniques which might be confusing for users. Two examples:

Example 1:

* T3 (older version, Working Draft?): http://www.w3.org/WAI/PA/WCAG20/WD-WCAG20-TECHS/text.html#T3

* T3 (new version): http://www.w3.org/TR/WCAG-TECHS/T3.html


Example 2:

* H69 (Editor's Draft): http://www.w3.org/WAI/GL/WCAG20/NOTE-WCAG20-TECHS-20090105/H69

* H69 (http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H69)

As long as users are following the links (recommendation -> SC -> How to meet) they won't come along other versions (working drafts?, example 1) or older Editor's Drafts. But if they come along through a search engine, there is no information about the status of the single documents as long users don't follow the link "contents" and scroll to the top where they find "Editor's Draft January - July 2009".


Proposed Change:
Adding a clear note about the status of older documents.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2628: Test not effective since it ignores invisible timings
Commenter: Detlev Fischer <detlev.fischer@testkreis.de> (archived message)
Context: G5: Allowing users to complete an activity without any time limit
Not assigned
Resolution status:

Since timings affecting the user may be hidden (a meta refresh or a server side timeout) and become only apparent after interaction, e.g., when the site responds with a time-out message after a form is submitted, the test in G5 is not really effective. It would either need to limit itself to clearly visible time-dependent interactions (as in interactive games) and openly represented timings (as in online banking numerical or visual count-down displays that are reset with every activity) or it would need a test procedure as complex as the one recently suggested for F61 (Wait 10 times the average duration, check whether content / context is still available).

Proposed Change:
Limit G5 to visible timed events, or extend test procedure to account for hidden (e.g. server side) time-outs that may affect the user interactions (such as form submission) but are not observable without a procedure as lengthy as the one recently suggested for F61.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2601: G63 Description Difficult to Understand
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message)
Context: G63: Providing a site map
Not assigned
Resolution status:

The last sentence, "A Web page that does not link to all the sections of a site, that presents an organization that is different from the site's organization, or that contains links that are no longer valid is not a valid site map." is not easy to follow. It should be better understood as a bulleted / numbered list.


Proposed Change:
A Web page is not a valid site map when:
1. It does not link to all the sections of a site, or
2. It presents an organization that is different from the site's organization, or
3. It contains links that are no longer valid.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2648: Test does not require check whether user-entered data is re-displayed
Commenter: Detlev Fischer <detlev.fischer@testkreis.de> (archived message)
Context: G83: Providing text descriptions to identify required fields that were not...
Not assigned
Resolution status:

The description of this technique (the same point applies to technique G85) mentions "re-display the form (including any previously entered data)".
The test does not check whether previously entered data is actually re-displayed.

Proposed Change:
Add a third line to test:

Procedure
(1) Fill out a form, deliberately leaving one or more required (mandatory) fields blank, and submit it.

(2) Check that a text description is provided identifying the mandatory field(s) that was not completed.

(3) Check that other data previously entered by the user is re-displayed.



Expected Results

#2 and #3 are true
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2647: Test does not require check whether user-entered data is re-displayed
Commenter: Detlev Fischer <detlev.fischer@testkreis.de> (archived message)
Context: G85: Providing a text description when user input falls outside the requir...
Not assigned
Resolution status:

The description of this technique (the same point applies to technique G83) mentions "re-display the form (including any previously entered data)".
The test does not check whether previously entered data is actually re-displayed.

Proposed Change:
Add a third line in the test:

Procedure
(1) Fill out a form, deliberately enter user input that falls outside the required format or values

(2) Check that a text description is provided that identifies the field in error and provides some information about the nature of the invalid entry and how to fix it.

(3) Check that other data previously entered by the user is re-displayed.

Expected Results

#2 and #3 are true
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2730: Why is there a test for CSS?
Commenter: James Nurthen <james.nurthen@oracle.com> (archived message)
Context: G134: Validating Web pages
Not assigned
Resolution status:

4.1.1 makes no requirements on CSS as CSS is not a markup language so it makes no sense to have a test procedure for CSS.

Proposed Change:
Remove the test procedure for CSS
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2745: Adding an Example 4: Validating PDF
Commenter: Kerstin Probiesch <k.probiesch@gmail.com> (archived message)
Context: G134: Validating Web pages
assigned to Andrew Kirkpatrick
Resolution status:

Accessibility of PDF is becoming more and more important. The examples in this SC are limited to HTML and XML. I feel next updates of WCAG 2.0 should also give guidance about validating PDF.

Proposed Change:
Include an Example 4: Validating PDF.

Include a section "Validating PDF" (Ressources) and PDF accessibility checker (PAC) as a Ressource and also the .Acrobat Accessibility Checker (Full Check)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2622: Under Test > Expected Results #5 should also be true (why test it otherwise)
Commenter: Detlev Fischer <detlev.fischer@testkreis.de> (archived message)
Context: G178: Providing controls on the Web page that allow users to incrementally...
Not assigned
Resolution status:

I think in response of an earlier comment the test procedure of G178 was updated to set the viewport size.
Under Test > Expected Results #5 checks whether users can return to the original size.


Proposed Change:
#5 should also be true (why test it otherwise) so it should be included in the statement under "Expected results".
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2724: Contradiction in techniques - F73 & G182, and G183
Commenter: Steven Miller <StevenMiller@finance.gov.au> on behalf of Australian Government Information Management Office (archived message)
Context: G183: Using a contrast ratio of 3:1 with surrounding text and providing ad...
Not assigned
Resolution status:

Also logged at http://lists.w3.org/Archives/Public/public-comments-wcag20/2012Nov/0011.html

I am hoping to resolve an inconsistency in WCAG 2.0 techniques for WCAG conformance of Criterion 1.4.1, where there is a direct contradiction between techniques F73 & G182, and G183.


F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision



Failure technique F73, clearly states “If the non-colour cue only happens when the mouse hovers over the link or when the link receives focus, it is still a failure”



The test then confirms this by stating

Procedure

1. Check that each link within text that is part of a sentence or paragraph (or other area where they could be mistaken as non-linked text) in the page is underlined or otherwise visually identifiable (i.e., bolded, italicized) as a link without relying on color (hue).

Expected Results

· If check #1 is false, then this failure condition applies and the content fails this Success Criterion.



I think the key terminology of the test being “visually identifiable” – this would exclude mouseover’s, hover, or on focus which would all require some form of interaction to make the link visually identifiable. Of course it could be argued that by interacting with the link “mouseover’s”, “keyboard focus”, etc, then becomes visually identifiable and therefore passes the test. I would suggest updating the test with:



….. otherwise visually identifiable (i.e., bolded, italicized) as a link without relying on color (hue) or preceding interaction such as “hover” or “keyboard focus”.



This technique is supported by G182 and accepted through recent discussion on the WAI-IG mailing list (November 2012) at http://lists.w3.org/Archives/Public/w3c-wai-ig/2012OctDec/subject.html


G182: Ensuring that additional visual cues are available when text color differences are used to convey information



Sufficient technique G182, which states “The intent of this technique is to provide a redundant visual cue for users who may not be able to discern a difference in text colour”



Though the use of the word “redundant” muddy’s the meaning of the sentence, it seems obvious that the intent is meant to provide an additional (or complementary) visual cue for users who cannot identify a link visually.



The test confirms this interpretation by stating

Procedure

1. Locate all instances where the color of text is used to convey information.

2. Check that any text where color is used to convey information is also styled or uses a font that makes it visually distinct from other text around it.

Expected Results

· Check #2 is true.



The key terminology this times is “makes it visually distinct from other text around it”, this would again exclude mouse over’s, hover, or on focus which are not visually distinct from other text around it. Like F73 some form of interaction is required to make “hover”, etc, visually distinct.



Unfortunately these techniques are contradicted by G183.


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



Sufficient Technique: G183 provides for “a relative luminance (lightness) difference of 3:1 or greater with the text around it can be used if additional visual confirmation is available when a user points or tabs to the link”



The test confirms this point by allowing

Procedure

1. Locate all instances where color alone is used to convey information about text.

2. Check that the relative luminance of the color of the text differs from the relative luminance of the surrounding text by a contrast ratio of at least 3:1.

3. Check that pointing (mouseover) to the link causes a visual enhancement (such as an underline, font change, etc.)

4. Check that moving keyboard focus to the link causes a visual enhancement (such as an underline, font change, etc.)

Expected Results

· Checks #2, #3, and #4 are all true.



Points 3 and 4 of the procedure clearly allows for the use of “mouseover” or “keyboard focus” for links that are otherwise identifiable by color alone (providing in meets minimum contrast ratios with surrounding text).



This technique is identified as applying to Success Criterion 1.4.1.


SC1.4.1: Use of Color



The principal of Success Criterion 1.4.1 provides for users to be able to access information that is conveyed by color. The criterion alludes to this further by indicating “providing the information conveyed with color through another visual means ensures users who cannot see color can still perceive the information”.



I believe the intent of this criterion is to ensure that all users can perceive any information presented on screen programmatically or visually (without interaction). Otherwise many color impaired users will need to interact with all the content of every page to determine whether or not there is information conveyed that they are unaware of. Note: In the case of links it is difficult to hover over the link text, to determine whether it is the link text, when you don’t first recognize it as the link text!


Recommendation



In line with the intent of Success Criterion 1.4.1 (explained above), then it should be a reasonable expectation that sufficient technique G173 be removed or adjusted so that there is no contradiction with other techniques or the intent of the associated criteria.



NOTE: Aside from being confusing for developers, as to which technique to apply when developing an accessible site; and in particular for claiming WCAG 2.0 conformance. Many governments are now adopting WCAG 2.0 as a form of governance for web accessibility. For Governance to be applied effectively, it is imperative that there are no contradictions in the definitions and measure of conformance (techniques); and preferably no ambiguity.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2625: no value for adapted leading contained in test procedure
Commenter: Detlev Fischer <detlev.fischer@testkreis.de> (archived message)
Context: G188: Providing a button on the page to increase line spaces and paragraph...
Not assigned
Resolution status:

The test procedure does not require that the increased leading achieved by using the mechanism is actually better than 1.5 (150%). A value is only included for in-between paragraph space.

Proposed Change:
Chenage #3 of test procedure:

"3. Check that the feature increases the line height to at least 1.5 (150%)"

An added comment reg. 'feature': The test uses first 'button or link', then refers to either of these as 'feature'. Other tests simply use 'mechanism'.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2605: H4 Example 3 seems to fail the test procedure in F44
Commenter: Mark Rogers <mark.rogers@powermapper.com> (archived message)
Context: H4: Creating a logical tab order through links, form controls, and objects
Not assigned
Resolution status:

I can see what example 3 is trying to demonstrate, but if this example is used verbatim I think it would lead to a failure (because the tab order doesn't match the presentation order)

Worth noting that H4 example 3 is also almost identical to F44 failure example 1 (so it's pretty confusing)




Proposed Change:
Perhaps adding some CSS classes that imply layout is different from source order would make this clearer:

<a href="" class="topNav" tabindex="1">one</a>
<a href="" class="subNav" tabindex="2">three</a>
<a href="" class="topNav" tabindex="1">two</a>
<a href="" class="subNav" tabindex="2">four</a>

The other alternative would be placing the code in table like example 1.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2620: Reference to the title attribute on a techniqu that deals with abbr
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message)
Context: H28: Providing definitions for abbreviations by using the abbr and acronym...
Not assigned
Resolution status:

Note that a screen reader like JAWS allows users to set 'expand abbreviation' and 'expand acronym' in their configuration settings, which goes against the user agent notes that cite the title attribute. The fact is that this technique is about acronyms and abbreviation.
The first two pointers do not seem to be in the right place follow:
">Assistive technologies provide different levels of support for speaking title attributes. Some do not include features that allow users to access information provided via the title attribute.
>Implementing this technique with the title attribute is only sufficient if the title attribute is accessibility supported. The content of the title attribute needs to be available to all keyboard users (not only those with text-to-speech software) for this attribute to be accessibility supported."


Proposed Change:
Replace the first two pointers with:

> Assistive technologies provide different levels of support for speaking abbreviations and acronyms.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2596: support notes are incorrect
Commenter: Steve Faulkner <faulkner.steve@gmail.com> (archived message)
Context: H45: Using longdesc
Not assigned
Resolution status:

The user agent notes state:

"Some older assistive technologies do not support the longdesc attribute."
This is factually incorrect. A number of current versions of assistive technology software does not support does not support longdesc including VoiceOver 4.0
NVDA 2012


Proposed Change:
JAWS 13 - supports
Window Eyes 7.5 - supports
VoiceOver 4.0 - does not support
NVDA 2012 - does not support
Orca (latest)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-39

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:00 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org