W3C logo Web Accessibility Initiative (WAI) logo

WAI Web Content Accessibility Guidelines Issues List

Last revised: $Date: 2001/08/16 00:28:06 $:

This page tracks issues raised since the publication of the WCAG 1.0.

If there is an issue that is not on this list, or that is misrepresented or inadequately summarized, please send your comments to w3c-wai-gl@w3.org list or contact the editor, Wendy Chisholm, at wendy@w3.org.

Table of Contents of Issues

Open Issues

Issues that need to be addressed in Errata page

  1. Use of META to describe conformance level
  2. Guideline 11 - implications for PDF, deprecated elements, etc.
  3. Addressing the needs of the graphically-dependent
  4. Flicker
  5. Conflicts between checkpoints for layout
  6. Dealing with unsupported technologies
  7. Clarification required for 14.2

Issues that will be resolved when work begins on next draft

  1. Order of Guidelines
  2. Priority of image map checkpoint (9.1)
  3. Version 1.1
  4. Chat
  5. Split the guidelines based on human or machine need.

Closed issues

  1. Issues raised during Proposed Recommendation and their resolutions.
  2. Table of issues raised during last call and their resolutions.
  3. List of issues raised during last call and their resolutions. This is a linearized version of the table.
  4. Issues raised during production of working drafts. Resolved before last call.
  5. Eliminating priorities
  6. Test each post 1.0 suggested change or errata for inclusion in FAQ, errata, or techniques.
  7. Maintenance of "until user agents" page
  8. How do relative units affect images?
  9. Label position (checkpoint 10.2)
  10. Implications of spaces in links for I18N

Open Issues

Order of Guidelines

Issue raised by: Daniel Dardailler - 19 May 1999


It should be explicitly noted in the guidelines that the order in which they appear is not relevant of any global priority. Second, even though this is true, people still present them starting with number 1, then number 2, and the order subjectively matters.

Proposed resolution:

1. Provide equivalent alternatives to auditory and visual content.
9. Design for device-independence.
3. Use markup and style sheets and do so properly.
6. Ensure that pages featuring new technologies transform gracefully.
5. Create tables that transform gracefully.
11. Use W3C technologies and guidelines.
2. Don't rely on color alone.
4. Clarify natural language usage
7. Ensure user control of time-sensitive content changes.
8. Ensure direct accessibility of embedded user interfaces.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
10. Use interim solutions.
14. Ensure that documents are clear and simple.

Priority of image map checkpoint (9.1)

Issue raised by: Daniel Dardailler - 18 May 1999


If someone provides redundant text links for each active region of a server-side image map (checkpoint 1.2), then the author should not have to provide a client-side instead of server -side (checkpoint 9.1 - Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.)

Proposed resolution:

Make 9.1 a p3

Use of META to describe conformance level

Issue raised by: Ian Jacobs - 20 May 1999


In addition to putting an icon in documents to indicate conformance, can we also put meta information in the document, e.g., via META.

Proposed recommendation:

Create a PICS schema

Version 1.1

Issue raised by: Coordination Group - 1 June 1999


Due to the types of comments we are receiving, we will need to release a follow-up version of the guidelines. We don't want to do this too soon, because we will have to go through the whole Recommendation process, but we ought to consider the timeline we would like to work towards, as well as what process we need to complete. During the Coordination Group meeting, it was proposed that more user tests need to be conducted to ensure we catch all of the major bugs. The results that Helen and Chetz published during the working draft phase was very beneficial. Follow-up investigations seem like a good idea. Questions are:

  1. Who would do this?
  2. What information do we want to find out?
  3. Timeline for user testing?
  4. Timeline for next release?

General consensus seems to be (as of 10 June meeting) that a new version is not immediately necessary. Discussion about if next version is 1.1 or 2.0. General feeling seemed to be that it depended on the issues that are raised and their seriousness.


Issue raised by: Coordination Group - 1 June 1999


We need to begin identifying needs for future work in this area, such as chat and other real-time technologies. What are our recommendations for the future?

Guideline 11 - implications for PDF, deprecated elements, etc.

Issue raised by: Coordination Group - 1 June 1999, Robert Neff - 28 May 1999 (on IG list)


  1. (From Robert's message) "As I interpret the WAI Content Guidelines, Guideline 11, PDF is a non-W3C format and if PDF alone is used, we cannot obtain "AA". Therefore to obtain a "AA" we must provide a HTML document and proof it! That is a lot of work!!!"
  2. Daniel raised an issue about the use of deprecated tags when there is not another workable solution. We need to share our interpretation that some use of deprecated is o.k. The CG feels we should either address this in errata or the next version. See the discussion about post 1.0 changes for the proposed test to use to determine which document changes should go in .

Addressing the needs of the graphically-dependent

Issue raised by: Jonathan Chetwynd - 7 Jun 1999 on the IG list.


Sites that are primarily text-based may be inaccessible to non-readers with a cognitive disability. Anne Pemberton states:

If it's an accessibility issue to choose to turn off the graphics, then turning on the graphics is also an accessibility issue. But you can't turn on what isn't there, and the guidelines as David listed them, would insure that the graphics are indeed there for those who need and want them. Without them, the information is _denied them because of their disability_.

Proposed resolutions:

expand the scope to read something like: "ensure that pages are as readable/processable as possible to ......and those with special processing needs. guidelines:

  1. illustrate pages with meaningful graphics and symbology. (this should be done in such a way as to allow for comprehention of the page without reading the text on the page by individuals who are totally graphically oriented).
  2. use multimedia whereever possible to either speak the text of a page or sho a demonstration which in an animated way explains the text on the pages. (this gets at those with limitations of atention, focus and other types of cognative processing which may interfere with visual processing).

Note: Making pages comprehensible after all is what we really hope to achieve. providing these curbcuts and doing a good job of it may well assist many of the rest of us as the medium and the environment evolve to a more real time paradigm much the way tv is now or trafic flow. I see this as moving to a situation where we will get our information entertainment, instructions and assistance all from one bag connected permenantly and irrevocably to a network, we wil be exploring our world more and more through this filter. If in this process, we should look away for a second, we don't want to miss something critical. This then that I propose will help to ensure less data loss.

Charles took an action item on July 8 to do this. The timeline for this issue is "in the future" after we have completed the browser support, impact matrix, and next round of techniques. This issue will impact the next version of the guidelines, and techniques.


Issue raised by: Jon Gunderson - 18 June 1999 (on GL/UA lists)


We recently had an issue raised in the UA group related to range of flicker frequencies that can trigger seizures in people with photosensitive epilepsy. Could you send to the UA list how the range of frequencies was determined and any reference materials that you used to formulate the range of frequencies.

Conflicts between checkpoints for layout

Issue raised by: Kynn Bartlett - 4 July 1999.


  1. Checkpoint 3.6 and 5.3 seem to conflict.
  2. Checkpoints 5.3 and 5.4 seem to conflict.

Proposed resolutions

  1. Replace 5.3 and 5.4 with
    Tables can be used for data and layout. For data, here is what you need for a Priority 1 and then list checkpoints that must be done to btain AAA level. For layout, tables must use do not use structural mark-up and you can only obtain AA conformance level.
  2. Charles had the following comment on 13 June:
    Using style sheets is an HTML/XML-specific techique for "Use methods which can be over-ridden by the user to control presentation". It is, in fact, probably a P1 requirement, although it needs the qualification of guideline 6 - Transform gracefully. And Lo, I looked there and found 6.1 ensure pages are usable without style sheets... This becomes a question of what features can be controlled by user agents - in other words, it says when there are good enough user agents, feel free to use anything you can think of.
    Which seems to imply that we need to abstract these checkpoints a bit.

Dealing with unsupported technologies

Issue raised by: This issue is more of a "theme" that has been developing throughout several threads. In particular: Adam Guasch-Melendez - 6 July 1999.


Several people have written with questions about "how do I meet a compliance level if the technology you are suggesting I use is not supported?"

Proposed resolution

This seems to be a matter of interpretation. The working group as taken an action item to investigate the following venues:

  1. In the immediate future, the Techniques document, the errata, and FAQ will contain information.
  2. The issues will be addressed in future versions.
  3. There may be the need for a separate document to go through these issues.
  4. Some of this info might be addressed in the Browser Support page in discussions of which browsers do what and thus what an author might need to do to work a specific browser.

Split the guidelines based on human or machine need.

Issue raised by: Jonathan Chetwynd - 8 July 1999


Some guidelines are meant for human consumption, others are for machines. For example, Guideline 1 (provide equivalents to auditory and visual content) is needed by humans whereas Guideline 3 (use markup and style sheets and do so properly).

Just as the techniques have been separated, peoples needs and machine abilities must be separated.

Clarification required for checkpoint 14.2

Issue raised by: Ian Jacobs - 24 August 1999


  1. Is an all-text document accessible?
  2. What clarification to 14.2 is necessary to emphasize author responsibility in determining whether graphics are required for accessibility?
  3. Is this really a P3?

Closed issues

Eliminating priorities

Issue raised by: Robert Neff - 5 July 1999


Including both the idea of priorities and as well as conformance levels is confusing. Instead of prioritizing each checkpoint, label it as to which conformance level it applies to.


This is part of making the guidelines easier to digest by a variety of groups who are not technical. We believe this is the task of the EO working group. Priorities and conformance levels are defined so that the document may be used not only by human developers but by automated checking tools.

Test each post 1.0 suggested change or errata for inclusion in FAQ, errata, or techniques.

Issue raised by: Coordination Group - 1 June 1999


Since many of the comments are requests for interpretation or clarification once the working group consenses on how to handle the issue, the result should show up in errata, FAQ, techniques, or all of the above. Thus, as we are closing issues we need to be thinking about what needs to immediately change and what should change in the long run (i.e., version 1.1).

Al's suggested test: put favorite of the moment technique in working draft. errata should link to faq, or techniques. but should be a punch list of questions that have been asked. test of faq - is this a recurring question? in technique - do we need to make details clear. errata - does it mislead someone?

Resolved on: 10 June

Resolution: Agree with Al's proposal with following additions:

  1. Techniques document also needs to link to errata
  2. Errata needs to be more visible
  3. Techniques document needs to link to errata
  4. Anything that is in errata also ought to be in the Techniques document.

Maintenance of "until user agents" page

Issue raised by: Coordination Group - 1 June 1999


It seems that as we develop the Techniques document, we will uncover information for the "uua page." Therefore, it seems to be our responsibility to complete the next version. However, once stable, it will become the responsibility of a W3C staff person to maintain. Judy is checking to see what resources they can offer. We need a general discussion about what direction to take with the document and how to get there.


Discussion on 10 June and 12 August brought about action items to get the ball rolling within GL and then hand it off to either UA or some W3C/WAI staff person.

How do relative units affect images?

Issue raised by: David Clark - 20 April 1999


Is it appropriate to use proportional units for images sizes? Do we want to allow an exception here? Specifying width and height for images often decreases download time.

Resolved on:

23 Nov 1999


Add an entry in errata that modifies the note on checkpoint 3.4 and address in Techniques.

Label position (checkpoint 10.2)

Issue raised by: Charles/Len - 13 June 1999 (on GL/EO lists)


Checkpoint 10.2 wording works for some controls, but not all. Refer to examples that don't work from Chuck Letourneau.

Resolved on:

23 Nov 1999


Add an entry in errata that modifies the note on checkpoint 10.2 and address in Techniques.

Implications of spaces in links for I18N

Issue raised by: Rick Jeliffe - 19 May 1999


Checkpoint 10.5 might conflict with Chinese typographic conventions, since it demands the use of spaces and Chinese typography does not include spaces. Therefore, some alternative wording or suggestion ought to be made. Is underlining links against good i18n practise (for languages written without spacing), if the underlines for consecutive words meet with no or only-a-tiny gap? If so, what are possible non-intrusive solutions to this that would not upset people's pages? The approach I raised, as an example not a suggestion, is to put a serif (a butt-end) on the end of each underline (or only adjoining ones), to clearly indicate its range.

10.5 currently reads: Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3].


The "until user agents" clause is satisfied for a few browsers. We need to document which legacy browsers are broken. Refer to the test case.