WCAG 2 FAQ
- Is WCAG 2.0 stable?
- What about WCAG 2.1?
- Does WCAG address mobile accessibility?
- Where should I start?
- What are the different WCAG 2.0 documents?
- Do content authors (developers, designers, etc.) have to follow W3C's techniques to meet WCAG?
- What would be the negative consequences of allowing only W3C's published techniques to be used for conformance to WCAG 2.0?
- Is ISO/IEC 40500 the same as WCAG 2.0?
- Is WCAG 2.0 available in other languages?
- How is WCAG 2.0 different from WCAG 1.0?
- Where can I find answers to more of my questions?
Yes. WCAG 2.0 was published as a final W3C Recommendation Web Standard on 11 December 2008. WCAG 2.0 itself is a stable, referenceable standard that will not change.
What about WCAG 2.1?
WCAG 2.1 is currently in development and is scheduled to be published as a standard in 2018. The primary focus for WCAG 2.1 is accessibility requirements for people with low vision and cognitive and learning disabilities, and mobile accessibility.
WCAG 2.1 is designed to be "backwards compatible" so websites that conform to WCAG 2.1 will also conform to WCAG 2.0 — which means that a website that meets WCAG 2.1 will meet the requirements of policies that reference WCAG 2.0.
Important notes about WCAG 2.1 Working Draft success criteria and planned refinements:
- The draft currently includes some success criteria that the Working Group has accepted, and many success criteria that are proposals that the group has not yet accepted. We are refining those proposals, and other proposals that are not yet included in the draft.
- The draft currently includes the WCAG 2.0 success criteria unchanged, even if they are redundant with proposed new success criteria. In later drafts, we might modify some WCAG 2.0 success criteria to reduce duplication and increase clarity. We would like input on the approach — whether to leave the 2.0 success criteria as is, or modify them.
Please review and comment. Updated WCAG 2.1 Working Drafts will be announced periodically to get feedback on accepted and proposed success criteria. We encourage you to submit comments early, to help us complete WCAG 2.1 as soon as possible. (We expect to finalize WCAG 2.1 wording in 2017, and late comments are unlikely to be addressed in this version due to the tight timeline.)
- February 2017 Working Draft announcement e-mail with a few more details than above.
- February 2017 blog post with background, goals, and process.
- March 2017 presentation material: WCAG 2.1—A New Version of Accessibility Guidelines.
After WCAG 2.1
Yes. See the Mobile Accessibility page.
If you want a really short introduction to 3 web accessibility issues (alternative text for images, keyboard input, and transcripts), see What: Examples of Web Accessibility.
To learn about web accessibility principles and guidelines, see Accessibility Principles.
To learn about WCAG 2.0 specifically, start with the WCAG Overview. It provides an important foundation for understanding the different WCAG 2.0 documents, and points to several resources for using WCAG 2.0.
How to Meet WCAG 2.0: A customizable quick reference is the primary resource for developers using WCAG 2.0.
To learn how the different WCAG 2.0 technical documents are related and linked, see The WCAG 2.0 Documents.
Here's a little more perspective on the different technical documents. When web content and web software developers were using WCAG 1.0, they had many questions on how to implement it, how to evaluate for it, and the reasons behind its requirements. WAI wanted to provide this information with WCAG 2.0, and since those details don't fit well in a technical standard, they are in the supporting documents.
Thus with WCAG 2.0, there are extensive supporting materials, which are advisory documents. The WCAG 2.0 guidelines document itself is the only document that is a web standard, and it is fairly short.
No, you do not have to use the techniques in W3C's Techniques for WCAG 2.0 document.
The 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.
While many authors find W3C-documented techniques useful, there may be other ways to meet WCAG success criteria. You can use other techniques. Web content could even fail a particular technique test, yet still meet WCAG in a different way. Also, content that uses some of the Techniques does not necessarily meet all WCAG success criteria.
For important additional information, see the Understanding Techniques for WCAG Success Criteria section of Understanding WCAG 2.0.
What would be the negative consequences of allowing only W3C's published techniques to be used for conformance to WCAG 2.0?
Background: Some organizations have considered requiring all web content to use W3C's published techniques.
W3C recommends that the only thing that is required is meeting the WCAG 2.0 success criteria. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard — not the techniques. W3C's Techniques for WCAG 2.0 document is informative (that is, not required, non-normative).
W3C cautions against requiring web content to use only W3C's published sufficient techniques and not allowing other techniques for several reasons, including:
- It would prevent the use of new technologies (for example, HTML5 and WAI-ARIA) while the technologies and relevant sufficient techniques are being developed, which is usually more than a year.
It often takes several years for technologies to be developed and finalized. Once a technology is stable, it usually takes several months for the WCAG Working Group to develop techniques, test them with user agents and assistive technologies, make them available for public review, revise them as needed, and formally publish them.
- W3C's Techniques for WCAG 2.0 is not comprehensive and may not cover newer technologies and situations. There may be techniques that are sufficient to meet a given success criteria, but that are not yet included in W3C's published document.
- W3C's published sufficient techniques may not always be the best techniques in a specific circumstance.
- It is not always possible to use the W3C's published sufficient techniques — for example, because of the way the content is designed — and there are other ways to meet the success criteria.
- It would prevent the use of new techniques and best practices until W3C published them.
Therefore, W3C's published techniques should not be required as the only way to meet WCAG 2.0 success criteria unless the limitations and consequences above are understood and acceptable.
For additional information, see: Understanding Techniques for WCAG Success Criteria section of Understanding WCAG 2.0
Yes. WCAG 2.0 is approved as an ISO standard: ISO/IEC 40500:2012. ISO/IEC 40500 is exactly the same as the original Web Content Accessibility Guidelines (WCAG) 2.0 from the W3C Web Accessibility Initiative (WAI).
For supporting resources that provide practical advice for meeting ISO/IEC 40500 (which is WCAG 2.0), see the WCAG Overview.
Benefits of WCAG as ISO
Approval of WCAG 2.0 as an ISO standard benefits countries and organizations that can more easily adopt ISO standards. Countries that previously adapted WCAG 2.0 may now be able to adopt WCAG 2.0 as is by referencing ISO/IEC 40500.
W3C has offered our WCAG 2.0 Authorized Translations to be used for the ISO/IEC translations. We will update this page when more information about translations is available.
Yes. Authorized Translations and unofficial translations of the technical documents WCAG 2.0, Techniques for WCAG 2.0, and Understanding WCAG 2.0 are listed in WCAG 2.0 Translations.
Unofficial translations of other WAI documents are listed at Translations of W3C Documents - WAI documents - listed by languages and Translations of W3C Documents - WAI documents - listed by document.
For more information on how you can contribute to WAI translations, see Translating WAI Documents.
WCAG 2.0 is designed to apply to a broad range of web technologies.
Techniques for WCAG 2.0 has techniques for several different web technologies. Note that publication of techniques for a specific technology does not imply that the technology can be used in all cases to create accessible content that meets WCAG 2.0. Developers need to be aware of the limitations of specific technologies and ensure that they create content in a way that is accessible to all their potential users.
WAI is also developing guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
Generally, WCAG 2.0 applies broadly to more advanced technologies; is easier to use and understand; and is more precisely testable with automated testing and human evaluation. The fundamental issues of web accessibility are the same, though there are some differences in the approach and requirements between WCAG 1.0 and WCAG 2.0.
Web Content Accessibility Guidelines 1.0 was published in May 1999. WCAG 2.0 was published on 11 December 2008. W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0.
Most websites that conform to WCAG 1.0 should not require significant changes in order to conform to WCAG 2.0, and some will not need any changes at all. For those familiar with WCAG 1.0, it will take a little time to learn the new approach of how the WCAG 2.0 documents provide guidance. To help you move to WCAG 2.0, WAI developed:
- How WCAG 2.0 Differs from WCAG 1.0
- Comparison of WCAG 1.0 Checkpoints to WCAG 2.0
- How to Update Your Web Site from WCAG 1.0 to WCAG 2.0
WAI hosts an Interest Group (WAI IG) mailing list where the community discusses web accessibility issues. WAI IG provides ideas from different perspectives. If you have a question that might be relevant to the WAI IG list, you can:
- Search the WAI IG list archives to see if your question has already been addressed sufficiently.
- Join the self-subscription list and post an appropriate question. Please read the Using the WAI IG mailing list and Participation sections of the WAI IG page.
WAI staff are actively developing guidelines, technical reports, and supporting material, and generally are not available to answer individual questions. However, you can send questions to firstname.lastname@example.org and we will integrate answers into this page and other documents as we are able.