W3C

List of comments on “Techniques for WCAG 2.0 (Public Review Draft)” (dated 21 June 2011)

Quick access to

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

1-20 21-28

question comments

Comment LC-2569: Example 2
Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message)
Context: SCR20: Using both keyboard and other device-specific functions
Not assigned
Resolution status:

The note reads "Even though this is currently invalid, it is provided as a transitional technique to make this function work."
Was this technique used before? This example looks very strange because none of WAIC working group members have used this technique before. We would simply use <a> element for this. This example is not useful.

Proposed Change:
Could you tell us the reason why this example is needed?
In our opinion, this example should be deleted.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2511: Technique G167 not well supported by Assistive Technology
Commenter: Detlev Fischer <fischer@dias.de> (archived message)
Context: G167: Using an adjacent button to label the purpose of a field
Not assigned
Resolution status:

Our screen reader tests of Technique G167 has shown that it is currently not sufficiently supported by Assistive Technology and therefore should not appear in the list of WCAG techniques. In our tests (compare http://testcases.bitvtest.de/index/html/form/g167.html ), it surfaced that currently only NVDA interprets the button as label of the input field before it.


Proposed Change:
Remove G167.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2512: Example 3 does not fit (because here, the text container does resize)
Commenter: Detlev Fischer <fischer@dias.de> (archived message)
Context: G179: Ensuring that there is no loss of content or functionality when the ...
Not assigned
Resolution status:

Example 3 does not fit the technique which relates to fixed-size containers, because here, the text container *does* resize (size defined in em).
Actually, I think what is *really* meant would have to be called "G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not <del>resize</del> <ins>change width</ins> - at least this is what examples 1 and 2 refer to.

Proposed Change:
* Delete example 3
* Change name of technique to make it clear that the topic is *fixed width* containers that expand at the bottom through reflow of text when the text size is increased to 200%
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2550: H91, Example 7: Textarea
Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message)
Context: H91: Using HTML form controls and links
Not assigned
Resolution status:

Both of example 7a and 7b has the value "Four score and seven years ago" inside the textarea element. These examples are misleading some authors.

The value is not necessarily required. HTML spec doesn't require authors to provide the value by using the body of the textarea element.

Proposed Change:
Add "The authors don't necessarily need to provide the value by using the body of textarea element." to the descriptions for example 7a and 7b.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2551: H91, Example 6: 'selected' attribute
Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message)
Context: H91: Using HTML form controls and links
Not assigned
Resolution status:

The 'selected' attribute is not necessarily required. This example is misleading some authors. Does SC 4.1.2 require authors to set the 'selected' attribute to "selected"? The answer would be "No".

Proposed Change:
Add "The 'selected' attribute is not necessarily required." to the description.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2555: H91, Example 3: value attribute
Commenter: Makoto Ueki <makoto.ueki@gmail.com> on behalf of WAIC (archived message)
Context: H91: Using HTML form controls and links
Not assigned
Resolution status:

This is also misleading the authors who read this document. The value attribute is not necessarily required.

Proposed Change:
Add "The value attribute is not necessarily required." to the description.

WAIC needs an answer from WCAG WG in order to harmonize with WCAG 2.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2570: Technique for a decorative image?
Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message)
Context: SCR2: Using redundant keyboard and mouse event handlers
Resolution status:

SCR2 is confusing. This technique is about a decorative image. Why don't you add "a decorative image" to the title? It would make the difference between "SCR2: Using redundant keyboard and mouse event handlers" and "SCR20: Using both keyboard and other device-specific functions" clearer.

Proposed Change:
Change the technique title to "SCR2: Using redundant keyboard and mouse event handlers on a decorative image" or "SCR2: Using device independent events to change a decorative image".
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2508: Linking to old version of Inspect Objects
Commenter: Guy Moreau <guy.moreau@hrsdc-rhdcc.gc.ca> (archived message)
Context: SCR37: Creating Custom Dialogs in a Device Independent Way
Not assigned
Resolution status:

Note: this also affects Flash2 since it points to the same resource.
The link "http://msdn.microsoft.com/en-us/library/ms695716.aspx" Microsoft Active Accessibility 2.0 SDK points to an much older version of the tool.

Note: Documentation should also be provided on what to look for with the tool. I will submit a separate item for this.

Proposed Change:
Change link to point to Microsoft Windows SDK Version 7.0 (for Windows XP) and 7.1 for Vista and Up.

7.0 URL: http://www.microsoft.com/download/en/details.aspx?id=18950
7.1 URL: http://www.microsoft.com/download/en/details.aspx?id=8279

Note: while SDK v7.1 can be installed on Windows XP, it's version of Inspect Objects is not compable with Windows XP as it only supports iAccessible2 while the 7.0 version supports MSAA as iAccessible2.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2509: Documentation for Inspect Objects (part of the Windows SDK)
Commenter: Guy Moreau <guy.moreau@hrsdc-rhdcc.gc.ca> (archived message)
Context: SCR37: Creating Custom Dialogs in a Device Independent Way
Not assigned
Resolution status:

Add what you are looking for with the Inspect Objects tool as it provides many technical features. This could be included as a note or as a separate link / new technique.

Note: I have been using Inspect Objects for several years as an testing tool to determine accessible name (labels) in applications, flash and web pages. I would be happy to elaborate more if required.

Proposed Change:
recommended configuration:
1. Options Menu:
a) Unset Watch Cursor (performance and allows to test tab order because only keyboard focus works afterwords)
b) optional but recommended: Show Highlight Rectangle (helps find missing focus rectangle by clearly showing focus separately)
c) optional but recommended: Show information tooltip. This is useful for single screens as it shows the required information in a tooltip on top of your webpage.
2. Settings Menu:
a) (optional) In the list of "Diplay in main windows" select Name, Value, Role and State only.
b) required if using Information Tooltip: select Name, Value, Role and State only.

Usage:
1) Tab through a web page or embedded object,
2) check if there is a name property
3) if there is a name property, check if it matches the appropriate label.

If 2 and 3 are true this is a pass, all else fails.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2553: PDF6 Technique Title
Commenter: Shawn Henry <shawn@w3.org> (archived message)
Context: PDF6: Making tables accessible in PDF documents by using table elements
Not assigned
Resolution status:

There are issues with current wording, which have the already been addressed. I think this technique title can be changed to avoid those issues, as well as be more consistent with the titles of the other techniques and more descriptive. This proposed change is based on quickly skimming the technique content and other titles. There may be a better one...

Proposed Change:
PDF6: Marking up table elements within PDF documents
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2536: CSS Technique: Using an invisible header text in the sidebar navigation
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message)
Context: in
Not assigned
Resolution status:

Dear Editors – Thank you for the feedback. I have a few comments.



1. This is not a sufficient technique for SC 2.4.6, which requires
that headings
and labels be descriptive, but does not require that they be present on the
page. As such, SC 2.4.6 addresses the text used for the heading or label.



Devarshi: Agreed. This should probably be listed as an advisory to Guideline
2.4. Any suggestions are welcome.





2. This could be an advisory technique, that is, a technique that is
not sufficient
for one of the success criteria, but which may make the contents more
accessible. However, it is still not clear which success criteria this
should be advisory to. Possibly to Success Criterion 2.4.10 (Section
Headings are used to organize the content) or to Guideline 2.4 (Provide ways
to help users navigate, find content, and determine where they are).



Devarshi: It can be an advisory to Guideline 2.4.





3. We have some concerns about using invisible text in CSS, especially with
ARIA landmarks on the horizon. The CSS for hiding them is not 100% stable.
Especially in right-to-left layouts, there are problems which left-to-right
layouts don't have. There are also ever changing decisions by screen readers
about what patterns they support. This technique would need to include the
technical details for how to hide the text using CSS.



Devarshi: Use of landmark roles and what this technique proposes are two
different things. Landmark roles are great, but their presence should not
undermine this technique.



I am not clear why this instability of text hidden using css is pointed out
here. Please note that the current w3 and wai pages use a h2 header called
<Site Navigation> hidden via css; refer to http://www.w3.org/ and
http://www.w3.org/WAI/. So far, it has worked, and more importantly without
users even noticing that this header was hidden.



Regarding the technical details needed, I will only be able to provide the
basic CSS required to hide the text.



Regarding issues with rtl layouts, I am not in favor of this technique
encompassing multiple design styles. This technique is for ltr layouts, and
if not including rtl will be a concern, a note stating this could be made in
the technique. I personally feel the most fundamental idea should be
conveyed, and then it is upon the designers and developers to supply a CSS
that hides text in an rtl layout, based on their understanding of this
technique.



Regarding differing screen reader patterns, I am not aware of this, not
since I started using them, though I cannot rule out changing user
patterns. Please clarify this point.



4. We also have concerns with requiring level 3 headings, rather than whatever
heading element works in the context of the page structure.



Devarshi: Agreed. This should be open to any header element.





5. The related techniques do not seem relevant to this technique, in that they
are not presenting alternative techniques for addressing this requirement.



Devarshi: G148 seems to be the most relevant. Any suggestions are welcome.



6. The test procedure should describe what needs to be true of the coding,
not how to test operationally. While we find it necessary to provide
operational tests for general techniques, they are less reliable than tests
that focus on the underlying technology. See the published CSS techniques
for examples of how to describe CSS tests.



Devarshi: Agreed.



Basically, except 3, the rest is fine with me.



Thanks,

Devarshi

Response from WG:
This could be an advisory technique for Guideline 2.4.

If you want to limit this technique to left-to-right layouts, please make that clear in the description.

Differing screen reader patterns would surface as accessibility support notes. You may wish to include a note similar to Note 1 in "C7: Using CSS to hide a portion of the link text". The technique of using CSS to hide text are very similar in C7 and in your proposed technique, and you may be able to borrow from other parts of that technique.

Fesponse from commenter:
1. This is not a sufficient technique for SC 2.4.6, which requires that headings and labels be descriptive, but does not require that they be present on the page. As such, SC 2.4.6 addresses the text used for the heading or label.

Devarshi: Agreed. This should probably be listed as an advisory to Guideline 2.4. Any suggestions are welcome.

2. This could be an advisory technique, that is, a technique that is not sufficient for one of the success criteria, but which may make the contents more accessible. However, it is still not clear which success criteria this should be advisory to. Possibly to Success Criterion 2.4.10 (Section Headings are used to organize the content) or to Guideline 2.4 (Provide ways to help users navigate, find content, and determine where they are).

Devarshi: It can be an advisory to Guideline 2.4.


3. We have some concerns about using invisible text in CSS, especially with ARIA landmarks on the horizon. The CSS for hiding them is not 100% stable. Especially in right-to-left layouts, there are problems which left-to-right layouts don't have. There are also ever changing decisions by screen readers about what patterns they support. This technique would need to include the technical details for how to hide the text using CSS.

Devarshi: Use of landmark roles and what this technique proposes are two different things. Landmark roles are great, but their presence should not undermine this technique.

I am not clear why this instability of text hidden using css is pointed out here. Please note that the current w3 and wai pages use a h2 header called <Site Navigation> hidden via css; refer to http://www.w3.org/ and http://www.w3.org/WAI/. So far, it has worked, and more importantly without users even noticing that this header was hidden.

Regarding the technical details needed, I will only be able to provide the basic CSS required to hide the text.

Regarding issues with rtl layouts, I am not in favor of this technique encompassing multiple design styles. This technique is for ltr layouts, and if not including rtl will be a concern, a note stating this could be made in the technique. I personally feel the most fundamental idea should be conveyed, and then it is upon the designers and developers to supply a CSS that hides text in an rtl layout, based on their understanding of this technique.

Regarding differing screen reader patterns, I am not aware of this, not since I started using them, though I cannot rule out changing user patterns. Please clarify this point.

4. We also have concerns with requiring level 3 headings, rather than whatever heading element works in the context of the page structure.

Devarshi: Agreed. This should be open to any header element.

5. The related techniques do not seem relevant to this technique, in that they are not presenting alternative techniques for addressing this requirement.

Devarshi: G148 seems to be the most relevant. Any suggestions are welcome.

6. The test procedure should describe what needs to be true of the coding, not how to test operationally. While we find it necessary to provide operational tests for general techniques, they are less reliable than tests that focus on the underlying technology. See the published CSS techniques for examples of how to describe CSS tests.
Devarshi: Agreed.

Basically, except 3, the rest is fine with me.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2535: H1 elements should be used for titling the web site ...
Commenter: Jon Gunderson <jongund@illinois.edu> (archived message)
Context: in
Resolution status:

Loretta,

Thank you for your response.

Thank you for submitting this technique. The working group has reviewed it and has the following feedback:

1. We do not feel this is a sufficient technique for SC 2.4.2. In the absence of the <title> element, this would not satisfy the success criterion. So at most it would be an advisory technique for SC 2.4.2. It might also be considered an advisory technique for SC 2.4.10.
I am not sure what you mean here.
My technique requires the use of title and H1 element.
Could you clarify why you think the technique I submitted does not require the title element?
See reference on the rules for implementation: http://html.cita.illinois.edu/nav/title/title-rules.php

1. This technique itself contains no content, only references to other resources on the web. The details of the technique need to be included inline, so that the technique stands on its own. Links to other resources can supplement the technique but cannot define it.
Is this a better example?
http://html.cita.illinois.edu/nav/title/title-example.php

1. We feel that many of the recommendations in the referenced sources are over-restrictive. Whether we would include them in a WCAG advisory technique would depend on exactly how the requirements of the technique were defined.
My understanding is that the techniques document is informative.
This is a technique we have been using for over 8 years and has wide adoption and a technique that many developers and people with disabilities have found very useful.
Maybe this techniques does not work for everyone in all situations, but shouldn't there be more than one way to meet a success criteria, especially if it provides richer information that the current technique?
Shouldn't the techniques document provide people with useful alternatives, let developers choose the ones that work for them and their customers?
Jon
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2562: Misinterpretation of list of assistive technologies and versions supporting PDF techniques
Commenter: Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
Context: Document as a whole
Not assigned
Resolution status:

Readers may interpret this list as Ëœonly these versions and later" support PDF accessibility.

Proposed Change:
AGIMO requests urgent clarification on the versions of the assistive technologies (AT) that fully or partially support PDF accessibility through the proposed Techniques. This is already done, in part, for WindowEyes.

To assist organisations and governments establish when PDF is suitably "Accessibility Supported" (http://www.w3.org/TR/WCAG20/#accessibility-supporteddef) for their audience, a table of AT version by PDF techniques is highly desirable. This table may only require a few versions older than the current release, where applicable (i.e. support is available in those releases).

It will be difficult for the Australian Government to determine the use of PDF as a WCAG 2.0 conforming technology, under the definition of Accessibility Support for our jurisdiction, without this clarification.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2568: Inclusiveness of examples in PDF Techniques
Commenter: Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
Context: Document as a whole (PDF Techniques)
Not assigned
Resolution status:

PDF Techniques - The examples with the illustrations are very useful, but we note they are exclusively from Word, OpenOffice Writer and Acrobat, and not necessarily the latest versions.

Proposed Change:
The W3C may like to consider including examples and illustrations from other common PDF authoring tools such as WordPerfect and InDesign.

The guidance would greatly benefit the use of a hide/reveal option (or link to a separate URI), displaying only examples and illustrations that are of particular use to the reader. This functionality is already available in other portions of the W3C site, to great value, such as the "How to Meet WCAG 2.0 Quick Reference" and "Diversity of Web Users".

In regards to Acrobat, the examples and illustrations refer exclusively to Acrobat 9 Pro. Acrobat X Pro is available and may need to be included in examples and illustrations. We are aware of many organisations that are also still using Acrobat 8 Pro, so examples with this version would also make a welcome addition if there are any differences in the capabilities or processes from Acrobat 9.

Similarly in regards to Microsoft Office Word, examples and illustrations refer mostly to Word 2007 and sometimes to Word 2003. In other places Word seems to be used generically with no version indicated. With Word 2010 in common usage, this needs to be included in the examples and illustration. Where Word is just referred to, it would be useful to indicate the version that the discussion is relevant for. Word versions for Mac OSX should also be included.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2549: G140, Example 2
Commenter: Shawn Henry <shawn@w3.org> (archived message)
Context: G140: Separating information and structure from presentation to enable dif...
assigned to Andrew Kirkpatrick
Resolution status:

G140: Separating information and structure from presentation to enable different presentations says: "Following this technique allows user agents to:... Modify the presentation of content by substituting alternate presentation rules attached to structural features."

There is a problem with Example 2 and I think it should be deleted. Currently with PDF users cannot substitute alternate presentation rules to structural features.


Proposed Change:
Delete Example 2.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2534: Audio Captcha and G144
Commenter: Roberto Scano <r.scano@webprofession.com> (archived message)
Context: G144: Ensuring that the Web Page contains another CAPTCHA serving the same...
assigned to Michael Cooper
Resolution status:

Hi, an issue that comes out here in Italy (where in the next month we will
have approved the government law upgrade for follow WCAG 2.0) about the
audio captcha.

http://www.w3.org/TR/WCAG20-TECHS/G144.html

a lot of audio captcha are in English language so there is need to put
something in techniques / examples regarding that an alternative audio
captcha for visual captcha should (I prefer must) respect the primary
language of the page.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2540: About H40 Definition list usage
Commenter: Sailesch Panchang <spanchang02@yahoo.com> (archived message)
Context: H40: Using definition lists
Not assigned
Resolution status:

Right, it is meant to be used to define a term like in a glossary. But it can be used effectively to represent content of the type LABEL: DATA. ... I mean not form controls but just text like:
<dt>Name</dt> <dd>xyz i.e name of person</dd>
<dt>Phone #</dt> <dd>person's phone#</dd> and so on.

Often there is such content displayed on the page either one below the other or horizontally and the label is styled / boldfaced so that it is visually distinct. So DL-DT-DD works fine in these instances if one chooses not to use a 2-col data table. The DL may be styled as needed.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2538: UA and AT out of date.
Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived message)
Context: H90: Indicating required form controls using label or legend
Not assigned
Resolution status:

This note talks about older screen readers and browsers: jaws 7, window-eyes 5, firefox 1... It also only refers to windows compatible technologies. Could this part be more general and indicate that older UAs do not behave properly?
We tested explicit labels and titles on form fields with Voiceover with safari, jaws 11 and the open source screen reader NVDA, as well as Window-eyes 7.2 and it worked fine.

Proposed Change:
Reword this section to invite on caution inusing this and include newer technologies and user agents.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2533: Technique has poor and undocumented browser support
Commenter: Earl Cousins <earl@automatedculture.com> (archived message)
Context: FLASH17: Providing keyboard access to a Flash object and avoiding a keyboa...
assigned to Michael Cooper
Resolution status:

The techniques described in FLASH17 regarding keyboard access to a Flash object, and the working example, only work in Firefox and IE for Windows. They don't work in Chrome (Win/Mac) or either Firefox or Safari for Mac.

The technique makes no mention of these limitations, which seem unreasonable (doesn't seem to work in any webkit browsers at all).

Proposed Change:
Short term: Update the technique to reflect the current level of browser support.

Long term: Modify the techniques to increase the supported set of browsers (especially webkit).
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2564: Plethora of PDF generation tools not mentioned.
Commenter: Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office (archived message)
Context: PDF Technology Notes
Not assigned
Resolution status:

PDF Authoring Tools that Provide Accessibility Support - http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#pdf_notes_acc-sup_files_applications

Many PDF generators do not allow creation of accessible PDF files.

Proposed Change:
Consider adding a statement (or warning) in this section to indicate that many of the (inexpensive) PDF creation tools do not enable authors to create accessible tagged PDF files. Furthermore, there has been, or perhaps may still exist, an issue when people print to PDF from their word processing software and in the process create untagged files. Readers should also be warned about this issue if it remains unresolved.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-28

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org