WCAG 2 FAQ Notes

From Education & Outreach
This is an internal planning page.
Please see the published WCAG 2 FAQ.

Nav: EOWG wiki main page

Goals, etc.

  • clarify role of techniques, address misunderstandings
  • clarify issues with WCAG 2 ISO
  • focus on current issues, e.g., lower Is WCAG done and comparison to WCAG 1 sections

Note: consider along with update to WCAG Overview

WCAG 2 ISO draft

This is an internal planning page. Please see the published WCAG 2 FAQ. In the FAQ is information about ISO/IEC 40500 and WCAG 2.0.

{Q: [Tell me about] WCAG 2 ISO?}

WCAG 2.0 [is expected to be] approved as an ISO standard: ISO/IEC @@DIS 40500 Information technology -- W3C Web Content Accessibility Guidelines (WCAG) 2.0.

ISO 40500 is exactly the same as Web Content Accessibility Guidelines (WCAG) 2.0 from the W3C Web Accessibility Initiative (WAI), which is available online at http://www.w3.org/TR/WCAG/

For an overview of WCAG and links to supporting resources that provide practical advice for meeting WCAG 2.0, see the WCAG Overview.

{Adoption of} WCAG 2.0 as an ISO standard benefits countries and organizations that are more easily able to {adopt} ISO standards. Countries that previously adapted WCAG 2.0 may now be able to adopt WCAG 2.0 as is through the ISO document.

WCAG 2.0 is available in multiple languages from WCAG 2.0 Translations.

If you want more information on W3C and the ISO process, see W3C PAS FAQ.

Techniques

latest proposal and drafts: WCAG Techniques Communications

Comments since 16 May

Overall

  • Comments {name, date}
  • [closed] need to differentiate W3C document techniques vs. some other person/groups set of technique {Andrew, 17 May}
  • [closed] main section title: "Understanding Techniques for WCAG Success Criteria". perhaps would be better as: "Understanding Techniques for WCAG 2.0" to make clear the focus is on the W3C document ... depends if we want to leave "Success Criteria" in there to reinforce that the SC are the basis for conformance... {Shawn}

Understanding WCAG 2.0

  • Comments {name, date}
  • [EOWG discuss] Suggestions for improving the wording of the Failures section?
  • [EOWG discuss] The Other Techniques section currently says: "In addition to the techniques in W3C's Techniques for WCAG 2.0 document, there are other ways to meet WCAG success criteria. Web content does not have to use W3C's published techniques." The last bit is trying to address both developers and evaluators. It's a more succinct way of saying to authors that your web content doesn't have to follow W3C's techniques, AND saying to evaluators that when you're checking web content, it's OK if it doesn't use W3C's techniques. Would it help to say:
    "Web content does not have to follow W3C's published techniques." or
    "Web content does not have to implement W3C's published techniques."?
    or can we keep the simpler word "use"?
    or is there another simple way to say it? {Shawn}
  • [closed] Tests: suggest strengthening the requirement for 'accessibility support' {Andrew, 17 May}
  • [closed] Suggest changing "The WCAG Techniques are not intended to be required. The only thing that should be required is meeting the WCAG 2.0 success criteria" to "The W3C did not intend WCAG Techniques to be required. The only requirement is meeting the WCAG 2.0 success criteria" to be more definitive. {Andrew, 17 May}
  • [closed] STs: Suggest changing "For most success criteria, there are sufficient techniques — if you follow the sufficient techniques, you meet the success criteria." to "For most success criteria, there are sufficient techniques — one way to meet the success criteria is to follow the sufficient techniques." to downplay the hint that the way to meet the SC is to follow the techniques {Andrew, 17 May}
  • [closed] STs: Suggest changing " numbered list where each list item provides the technique or combination of techniques" to " numbered list where each list item provides a technique or combination of techniques" {Andrew, 17 May}
  • [closed - I think good to leave 'sufficient' in there] ATs: suggest changing "they are not sufficient to meet the full requirements of the success criteria" to "they do not meet the full requirements of the success criteria" to 'tersify' {Andrew, 17 May}
  • [closed] ATs: suggest changing the leading sentence, at the moment it sounds as though all ATS have each of the problems in the list, (problem word seems to be "including". Would "Advisory techniques can enhance accessibility, yet are not designated as sufficient due to one or more of the following issues:" make the list appear less scary? {Bim, 17 May}
  • [closed] Failure: can we say 'If a failure is observed, than the page definitely fails that corresponding SC' ? {Andrew, 19 May}
  • [closed] Failures: Might there also be other ways to FAIL other than those WCAG working group has documented? Should we say so? {Andrew, 22 May}
    Yes, there are other ways to fail. However, I'm not sure it's worth mentioning. There are import reasons to clarify there can be other "sufficient techniques". I haven't heard of anyone thinking that the failures were a comprehensive list... Possibly worth a brief mention, but I think not worth a lot of text. I tried a simply change from: "Failures are common mistakes to avoid." to -> "Failures are some common mistakes to avoid." {Shawn, 23 May}
  • [closed] General & tech-specific: We are new referring to all techniques as 'best practice' - this seems different what is said under STs and ATs {Andrew, 19 May}
  • [closed. yeah. there may not be another way for a specific sc, but we know that there are other ways for some SC, and this is a point they want to get across.] Other Techniques: We say "there are other ways to meet WCAG success criteria" - are we sure? Should we instead say "there may be other ways to meet WCAG success criteria"? {Andrew, 19 May}

Techniques for WCAG 2.0

  • Comments {name, date}
  • [closed. we don't talk about any of that in this section, instead we point to the full explanation in the other section.] Consider adding at the end of para that starts "Techniques are informative ..." something to make it clear here in the Techniques doc that "There may be other techniques not documented here that will satisfy a particular SC" {Andrew, 19 May}

WCAG 2.0 FAQ

  • Comments {name, date}
  • [closed] Q2: maybe change from "The WCAG Techniques are not intended to be required" to "The WCAG Techniques are not intended to be required - other techniques may also satisfy any particular SC" It is in the bullets, but might be worth getting into the first senstence too :) {Andrew, 19 May}
  • [closed - why add the extra wording?] Q2: suggestion for the "Limiting authors ..." para - "Limiting authors to the published Techniques for WCAG 2.0 would prevent them from using other techniques that could be better in certain circumstances. It would prevent authors from using new techniques and technologies until they were assessed and published by the WCAG Working Group; this can take many months."

Each Technique - add section at the end

  • comments {name, date}
  • [closed] suggest "Alternative techniques may be applicable in some situations." instead of "Other techniques may be used." {Andrew, 17 May}

Understanding - for each technique listing

  • Comments {name, date}

Key Points

  • Comments {name, date}




below is background and previous ideas

Previous Info

Issue: Some people wrongly think that:

  • the techniques are the basis for meeting WCAG, instead of the SC
  • you must use the sufficient techniques
  • sufficient techniques should be required
  • you can only use the WCAG sufficient techniques and not other ways to meet the SC
  • if you fail a test in a technique, you fail WCAG 2

Current coverage of Techniques:

Recent EOWG discussions of the issues and solutions:

Proposal for addressing the issues

  1. Full coverage - Clearly and thoroughly cover issues with edits listed below to:
         Sufficient and Advisory Techniques section of Understanding WCAG 2.0
    Rationale: The Techniques document is not intended to be read, nor usually is read, as a whole document; whereas, the Understanding document is intended to be read more thoroughly.
  2. Key points - Develop a short, succinct few paragraphs (draft below) with a pointer to the Understanding for details, and put the same text in:
  3. Each technique - In each technique, include a short statement that it's not required, with pointer to more details.
    Rationale: Lots of people (most?) read the QuickRef/How to Meet and individual techniques, and never read the Techniques intro, nor the Understanding pages.
  4. policy page? - Consider pros & cons of having a separate page to point policy makers to. (If so, re-use the key points language, and keep it as short and focused as possible.)

Draft Content

Understanding WCAG 2.0 document

Move most of the Introduction to Techniques for WCAG 2.0 to the Understanding document and edit it significantly:

  • Reorganize it under more subheadings, such as:
    • Informative Techniques for WCAG Success Criteria -
      SC are broad and stable, techniques provide specific guidance and are updated regularly;
      techniques informative, not required, SC only for conformance;
      • General and Technology-specific Techniques - including the second paragraph
      • Other Techniques - OK to use others, other method for ensuring they meet SC
      • Submitting Techniques - the current 4th paragraph
    • Sufficient Techniques - about numbered lists, AND, etc.
    • Advisory Techniques
    • Failures
    • Techniques Tests - edited version of what's there now that's not already covered elsewhere. more clear. failing a technique test doesn't mean failing WCAG.
    • Notes
      • Code Samples - info from Note 1 and the first paragraph under "Application of Techniques"
      • Alterantive mechanisms to access content - middle paragraph under "Application of Techniques"
      • "Must" wording - last paragraph under "Application of Techniques"(also RFC 2119 needs link to reference)
    • Using the Techniques (repeat new section from Techniques doc.)
  • Edit to more active voice so it's easier to understand.
  • Right now there is a lot of information that applies to all techniques but is said only for sufficient techniques. Edit this.
  • A concrete example of a new technique would be useful, e.g., related to a new technology
  • Note: "If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the Success Criteria would be needed." can be turning people off - On the one hand we are saying that this is just one way but on the other hand we add a burden of proof that may seem onerous.

Techniques for WCAG 2.0 document

Move most of the Introduction to Techniques for WCAG 2.0 content to the Understanding doc. Rationale: The Techniques document is not intended to be read, nor usually is read, as a whole document; whereas, the Understanding document is intended to be read more thoroughly.

Put in the Techniques document:

  • The key points text (above)
  • Using the Techniques - not intended to be read top to bottom, instead, access from QuickRef/How to Meet or Understanding...
  • Read the Understanding Doc to learn more.

Key Points

[DRAFT]

WCAG 2.0 guidelines and success criteria are designed to be broadly applicable across technologies and time. Guidance on meeting the WCAG success criteria is provided in techniques. Techniques are informative, that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard — not the techniques.

The Techniques for WCAG 2.0 document provides guidance for developers, including code examples, resources, and tests. For most success criteria, there are sufficient techniques — if you follow the sufficient techniques, you meet the success criteria. There are advisory techniques that you are encouraged to consider. There are also common failures that show you what to avoid.

While many developers find the WCAG Techniques useful, there are also other ways to meet WCAG success criteria. You do not have to use these sufficient techniques. You can develop different techniques. (We encourage you to share new techniques via the Techniques for WCAG 2.0 submission form.) Web content could even fail a particular technique test, yet still meet WCAG in a different way. Also, content that uses some of the WCAG Techniques does not necessarily meet all WCAG success criteria.

Note that the WCAG Techniques are not intended to be required. The only thing that should be required is meeting the success criteria.

To learn more about techniques, please see the Informative Techniques for WCAG Success Criteria section of Understanding WCAG 2.0.

Ideas for Key Points

(These have not been reviewed by EOWG.)

"[for fun]The WCAG 2.0 Techniques are brilliant. And those who read and use them on a regular basis are invariably not only wise and intelligent, but also devastatingly attractive.[end fun]

There are two formal kinds of technique: 'sufficient' and 'advisory'. The most important are the 'sufficient' techniques. Follow them and you can be confident that you will meet the WCAG success criteria. But you are free to come up with sufficient techniques of your own, as long as you are confident that they will also meet the success criteria. New web technologies may require new techniques, and the published techniques are not intended to be exhaustive or exclusive. Talented developers are continually coming up with new techniques even for established technologies; these are added to the techniques documents on an occasional basis.

The difference between a 'success criterion' and a 'sufficient technique' is important, in that success criteria are designed to be required [begin delete]by regulation (or law)[end delete]; sufficient techniques emphatically are not.

The second type of technique is 'advisory'. 'Advisory' techniques are just that - things that take you above and beyond the basic requirements, that you should always consider implementing, but are neither required nor sufficient to meet the basic criteria. They may be experimental.

In addition to the techniques, there are also a number of associated 'failures' - if you fail any of these, you know you have failed to meet the success criteria (but just because you haven't, doesn't mean you've passed...).

The techniques are *not* meant to be read at one sitting. They are meant to be read one at a time, when implementing a particular WCAG2.0 success criterion. We recommend developers start off from the quick reference 'How To Meet' document (http://www.w3.org/WAI/WCAG20/quickref/); those managing development projects or QA testing from http://www.w3.org/TR/UNDERSTANDING-WCAG20/; drafters of legislation or other regulation should start by ringing [begin delete]Shawn[end delete].

Of course, if you do come up with a new technique, share it! [begin delete]Send it in to Shawn at the W3C...[end delete] via the Techniques for WCAG 2.0 submission form

Good luck out there." {Liam}

Possible Policy Makers page

Updated Use of WCAG 2.0 Techniques and Failures from WCAG WG.

Ideas for policy page

(These have not been reviewed by EOWG.)

"Appropriate Use of Techniques for Writing Policy:

This document clarifies the use of Techniques as they are used in the writing and implementation of policy. Successful implementations of WCAG 2.0 support the WCAG 2.0 Success Criteria. The only true measure conformance is whether the success criteria that appear in the WCAG 2.0 Guidelines are satisfied.

The techniques that appear in that appear in the WCAG Techniques Document are vetted methods successfully implement content that conforms to WCAG 2.0. They are not the only way to satisfy the WCAG 2.0 success creiteria, but they are known to work every time.

The fact that WCAG Techniques are not the only way to meet the Success Criteria, makes them a poor choice as a basis for writing policy. All policy should b written to the Success Criteria, and Techniques should only be used as exemplars of exellent ways to satisfy the criteria."

{Wayne}




Big picture for later

[dboudreau - 20130419] We need to come up with some sort of a filter document that presents the general essence of what every success criteria covers or means to cover. So for instance, SC 1.3.1 could have a bullet list of reminders along the lines of semantics, structure, headings, explicit association in forms and data tables, etc. It wouldn't need to point directly to techniques (we have the understanding link that does that), but rather to a short overview of the things one need to keep in mind when trying to conform to a specific success criterion.

Liam: N.b. The trouble with 1.3.1 techniques: SC 1.3.1 is a special case - a bit of a grab-bag of page components, with techniques applicable if given elements exist (form elements, list elements, headings, tabular data etc). Could come up with a special 'am I finished yet?' para for just those techniques (Or even a nice page-checker that looks for particular components and references the appropriate techniques).

archived notes:

Key Points 18 April 2013 Draft

WCAG 2.0 guidelines and success criteria are designed to be broadly applicable across technologies and time. Guidance on meeting the WCAG success criteria is provided in techniques. Techniques are informative, that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard — not the techniques.

The Techniques for WCAG 2.0 document provides specific guidance for developers, including code examples, resources, and tests. For most success criteria, there are sufficient techniques — if you follow the sufficient techniques, you meet the success criteria. There are advisory techniques that you are encouraged to consider. There are also common failures that show you what to avoid.

While many developers find the WCAG Techniques useful, there may be other ways to meet WCAG success criteria. Websites do not have to use the sufficient techniques to meet WCAG. Web content can use other ways to meet the WCAG success criteria. Web content could even fail a particular technique test, yet still meet WCAG a different way. Also, content that uses some of the WCAG Techniques does not necessarily meet all WCAG success criteria.

Note that the WCAG Techniques are not intended to be required. The only thing that should be required is meeting the success criteria.

To learn more about techniques, please see the Sufficient and Advisory Techniques section of Techniques for WCAG 2.0.

FAQ

Do I have to follow the Techniques to meet WCAG?

No. The Techniques document provides guidance that is "informative". The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard — not the techniques.

You do not have to use the sufficient techniques to meet WCAG. Web content can use other ways to meet the WCAG success criteria. Web content could even fail a particular technique test, yet still meet WCAG a different way. Also, content that uses some of the published techniques does not necessarily meet all WCAG success criteria.

The Techniques are not intended to be required. The only thing that is intended to be required is meeting the success criteria.

To learn more about the techniques, please see:

  • About the Techniques section of How to Meet WCAG 2.0: A customizable quick reference... [@@ is there a reason to point to the QuickRef? or do we only need to point to the Techniques?]
  • Sufficient and Advisory Techniques section of Techniques for WCAG 2.0.
  • [@@ do we only need to point to the Techniques? or is there a reason to also point to Understanding?]

QuickRef Draft:

About the Techniques

[@@ just started this, and will have other edits...]

All of the techniques are informative — you do not have to follow the techniques. The basis for determining conformance to WCAG 2.0 is the success criteria, not the techniques.

You do not have to use the sufficient techniques to meet WCAG. Web content can use other ways to meet the WCAG success criteria. Web content could even fail a particular technique test, yet still meet WCAG a different way. Also, content that uses some of the published techniques does not necessarily meet all WCAG success criteria.

The Techniques are not intended to be required. The only thing that is intended to be required is meeting the success criteria.

Anyone can submit new techniques at any time. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the success criteria would be needed.

In addition to the 'sufficient techniques', there are also advisory techniques that go beyond WCAG 2.0's requirements. Authors are encouraged to apply all techniques that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.

See also Sufficient and Advisory Techniques. [@@suggest replacing with latest version link, not dated URI]

Questions: Do you think the right explanation is in those places? Does it need to be explained better? Or, are people just not finding it there?

Clarifying misunderstandings: Maybe we should refine a good explanation and then put it in the FAQ or elsewhere, and then do a promotional campaign just around that one issue - explaining the techniques... or while we're at it, see if there are other WCAG misunderstandings we want to clear up, too... (I'm imagining a short video explaining it, too - but that's wishlist.)

Some wording we drafted then deleted elsewhere: WCAG Techniques give specific guidance for developers on how to develop accessible web content. The techniques are "informative", that is, you do not have to use them. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard, not the techniques. To learn more about techniques, see About the Techniques.




This is an internal planning page.
Please see the published WCAG 2 FAQ.