WCAG 2 Overview
Introduction
Web Content Accessibility Guidelines (WCAG) 2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.
The WCAG documents explain how to make web content more accessible to people with disabilities. Web “content” generally refers to the information in a web page or web application, including:
- natural information such as text, images, and sounds
- code or markup that defines structure, presentation, etc.
Who WCAG is for
WCAG is for those who want a technical standard. It is not an introduction to accessibility. For links to introductory material, see “Where should I start?” in the FAQ.
WCAG is primarily intended for:
- Web content developers (page authors, site designers, etc.)
- Web authoring tool developers
- Web accessibility evaluation tool developers
- Others who want or need a standard for web accessibility, including for mobile accessibility
To meet the needs of others — including policy makers, managers, and researchers — there are many different WAI Resources.
What is in WCAG 2
The WCAG 2.2 has 13 guidelines. The guidelines are organized under 4 principles: perceivable, operable, understandable, and robust.
For each guideline, there are testable success criteria. The success criteria are at three levels: A, AA, and AAA.
The success criteria are what determine “conformance” to WCAG. That is, in order to meet WCAG, the content needs to meet the success criteria. Details are in the Conformance section of WCAG.
For a short summary of the WCAG 2 guidelines, see WCAG 2 at a Glance.
Supporting material and supplemental guidance
The following resources help you understand and implement WCAG, and improve accessibility beyond WCAG:
- Quick Reference / How to Meet WCAG 2 / Checklist
- Understanding WCAG 2
- Techniques for WCAG 2
- Test Rules for WCAG 2
- Supplemental Guidance
Please read about these WCAG 2 resources from WCAG 2 Documents.
WCAG 2.0, 2.1, 2.2
The Web Content Accessibility Guidelines (WCAG) standards are referenceable when they are published as a ‘W3C Recommendation’ web standard.
- WCAG 2.0 was published on 11 December 2008.
- WCAG 2.1 was published on 5 June 2018, and updates were published on 21 September 2023, 12 December 2024, and 6 May 2025.
- WCAG 2.2 was published on 5 October 2023, and an update was published on 12 December 2024.
For information on the updates, see the WCAG 2 FAQ.
WCAG 2.0, 2.1, and 2.2 are designed to be “backwards compatible”, which means content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0. If you want to meet all the versions, you can use the WCAG 2.2 resources and you don’t need to bother looking at earlier versions.
All the success criteria from 2.0 are included in 2.1, and all from 2.1 are in 2.2 (except 4.1.1, explained in the next paragraph).
- WCAG 2.0 has 12 guidelines.
- WCAG 2.1 adds 1 guideline and 17 success criteria. They are introduced in What’s New in WCAG 2.1.
- WCAG 2.2 adds 9 success criteria. They are introduced in What’s New in WCAG 2.2.
A few things have changed, and we intend the updates in the related documents to support backwards compatibility in practice. The main change is that in WCAG 2.2, one success criteria (4.1.1 Parsing) is obsolete. Notes added to WCAG 2.1 and WCAG 2.0 errata address this, as explained in WCAG 2 FAQ, 4.1.1 Parsing. WCAG 2.2 also includes Notes about different languages; more information is in WCAG 2 FAQ, internationalization.
WCAG 2.0, WCAG 2.1, and WCAG 2.2 are all existing standards. WCAG 2.2 does not deprecate or supersede WCAG 2.1, and WCAG 2.1 does not deprecate or supersede WCAG 2.0. W3C encourages you to use the latest version of WCAG.
Translations
Authorized Translations and unofficial translations of WCAG 2 are listed in WCAG 2 Translations.
ISO/IEC 40500, EAA, EN 301 549
WCAG 2.2 is an approved International Organization for Standardization (ISO) standard: ISO/IEC 40500:2025, and is available free from ISO. ISO/IEC 40500:2025 is exactly the same as the October 2023 version of WCAG 2.2. We expect the December 2024 version of WCAG 2.2 to be available as ISO/IEC 40500:2026 by late 2026.
In addressing the European Accessibility Act (EAA), most organizations use WCAG and the European Standard EN 301 549: Accessibility requirements for ICT products and services. EN 301 549 currently uses WCAG 2.1. We expect the next version of EN 301 549 to use the latest version of WCAG 2.2.
To find how laws around the world use WCAG, see Web Accessibility Laws & Policies.
W3C encourages you to use the latest version of WCAG. Content that meets WCAG 2.2 also meets WCAG 2.1 and WCAG 2.0.
Who develops WCAG
The WCAG technical documents are developed by the Accessibility Guidelines Working Group (AG WG) (formerly the Web Content Accessibility Guidelines Working Group), which is part of the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI).
WAI updates Techniques for WCAG 2 and Understanding WCAG 2 periodically. We welcome comments and submission of new techniques.
Opportunities for contributing to WCAG and other WAI work are introduced in Participating in WAI.
More about WCAG
WCAG is part of a series of accessibility guidelines, including the Authoring Tool Accessibility Guidelines (ATAG) and the User Agent Accessibility Guidelines (UAAG). Essential Components of Web Accessibility explains the relationship between the different guidelines.
Frequently asked questions (FAQ)
See the WCAG 2 FAQ for more information on:
- WCAG 2 coverage of mobile accessibility
- Applying WCAG 2 to documents and software
- and more…
JSON machine-readable files
The WCAG JSON (JavaScript Object Notation) files include the principles, guidelines, success criteria, and glossary terms from WCAG and the supporting Techniques. For more information, see JSON Serialization of WCAG 2 – GitHub .
WCAG 3
=
What it’s like working with WCAG in practice
WCAG gives you the rules of the road, but the real work happens in interpretation and implementation.
Common experiences teams run into
Success criteria look simple until you test them manually. For example, WCAG 2.1’s focus visibility requirement seems straightforward, but designers often want custom focus styles that don’t meet contrast thresholds.
Developers often assume ARIA fixes everything. Experience teaches you that ARIA is powerful but fragile. Native HTML almost always behaves better with assistive tech.
Automation catches only a fraction of issues. Tools like axe or WAVE are great, but they miss things like logical reading order, confusing link text, or poor keyboard traps.
Design debt is the biggest accessibility debt. Fixing color contrast or heading structure late in the process is always more expensive than designing accessibly from the start.
What WCAG teaches you over time
Accessibility is about predictability, not cleverness.
Consistency beats novelty.
Semantics matter more than visuals.
Keyboard testing is the fastest way to find serious issues.
What it’s like working with Section 508
Section 508 adds a layer of compliance, especially when working with U.S. federal agencies or vendors selling to them.
Typical real‑world experiences
Documentation becomes as important as the fixes. Agencies expect VPATs (Voluntary Product Accessibility Templates) that map your product to WCAG 2.0 AA criteria.
Trusted Tester methodology is strict. It’s more prescriptive than WCAG alone. You follow a defined testing process, not just interpret guidelines.
508 compliance requires repeatability. You need consistent testing procedures, not ad‑hoc audits.
Procurement teams ask tough questions. They want evidence, not promises—screenshots, test results, remediation plans.
What Section 508 teaches you
Accessibility is not optional when selling to government.
Compliance is a process, not a one‑time audit.
Teams must align: design, dev, QA, content, and legal.
Lessons learned from combining WCAG + Section 508
WCAG is the “what,” 508 is the “must.” WCAG defines the standards; 508 enforces them in federal contexts.
Meeting WCAG 2.1 AA puts you ahead of 508. Since 508 aligns with WCAG 2.0 AA, aiming higher reduces future rework.
Manual testing is the real differentiator. Screen reader testing reveals issues no automated tool can detect.
Accessibility maturity grows in stages. Teams move from reactive fixes → proactive design → integrated accessibility culture.
==========
Here is it Accessibility Tool is keros and Accchecker .https://docs.microsoft.com/
1. Selectable controls named and in proper tab order (more details later).
2. Access keys (e.g., pressing Alt plus some underlined letter clicks the button).
3. Aka "keyboard shortcuts" or "hotkeys" but we're not supposed to call them that anymore.
4. High contrast themes
Control Panel\Appearance and Personalization\
5. High DPI modes up to a custom text size of 200%
Control Panel\Appearance and Personalization\Display
Common Web Accessibility Bugs
6. Cannot set accessibility properties in html
Previous common bugs not obvious during CR.
Inferred by other means by browser.
7. Specify sizes in percentage
Test with zoom
8. Alternate text for images
Screen readers require context per control.
Not necessary if merely decorative
Accessibility Overview
Accessibility ensures that digital content can be used by everyone, including people with diverse abilities and disabilities. The core question is: Can all users—including those with disabilities—access and interact with our website effectively?
People may experience a wide range of disabilities, including:
1. Vision Disabilities
Blindness
Low vision
Color blindness (red, blue, green, or total color blindness)
How to Test
Screen Readers (Blindness):
Use JAWS or Windows Narrator to verify that all content is read correctly and in logical order.
Narrator in Windows 8 and later provides improved speed and feature support.
Low Vision:
Increase font size and ensure content remains readable and usable.
Test “Change only text size” settings to confirm UI elements scale properly.
Use Magnifier to enlarge portions of the screen and verify layout integrity.
Color Blindness:
Ensure no information is conveyed by color alone.
Verify that “greyed out” or disabled states are still distinguishable without relying solely on color.
2. Hearing Disabilities
Deafness
Hard of hearing
How to Test
Confirm availability of audio alternatives, such as captions or transcripts.
Validate that features like SSPR loudspeaker and CAPTCHA alternatives are accessible.
3. Temporary Disabilities
Broken bones
Short-term recovery
Limited mobility
How to Test
Ensure keyboard-only navigation is fully supported.
Ensure mouse-only navigation is fully supported.
Validate compatibility with speech recognition tools.
Speech Recognition Example: Windows Speech Recognition allows users to control the PC with voice commands, dictate text, and navigate applications.
4. Cognitive Disabilities
Learning disabilities
Difficulty focusing
Memory challenges
How to Test
Ensure clear, descriptive labels for all UI elements.
Validate that instructions are simple and consistent.
Test High Contrast Mode, which increases text and image distinction for easier recognition.
Accessibility Tools & References
Microsoft Accessibility Guidance
https://www.microsoft.com/enable/guides/vision.aspx
Keros Accessibility Testing
https://keros.cloudapp.net/
Example scan report: https://keros.cloudapp.net/Report/ScanPassResult/66df9d27-2877-45b5-9fb5-171aea6473d8#null
What to Test
Automated & Manual Testing
Execute all TP engine test cases using Keros and JAWS.
Validate keyboard accessibility.
Validate high contrast mode compatibility.
Pages to Test
IDP selection page
Signup attributes page
ESTS page
USS page
MFA page
Password reset pages
Profile edit policy pages
SSPR
Page UI customization
Detailed Testing Areas
Vision
JAWS screen reader
Narrator
Font size adjustments
Magnifier
High contrast mode
Hearing
Audio-to-text alternatives
Captioning support
Temporary Mobility
Keyboard-only navigation
Mouse-only navigation
Speech recognition support
Cognitive
Clear labels
Consistent UI patterns
UI Testing
Keros automated accessibility scans
==============
Localization/Globalization
Under-Localization:
The HSBS team will run manual tests on pseudo loc builds to look for strings that are not exposed for localization. Any string that’s not exposed for localization will be in English on the pseudo builds. The following strings must be localized:
· Strings exposed to the user.
· Tool tips.
· File version information – File description, copyrights, company name etc.
· URL – Links to online contents.
· Accelerator keys.
· Display file name.
· Service name and description in services.msc
· Firewall name and description.
· Event log entries.
Over-Localization:
Non-localizable strings should not be exposed for localization. Over localization typically results in functional bugs.
The following is the list of strings that should not be localized:
· Registry Key name and path
· Physical file name and folder name.
· Forwarded URLs.
· File extensions.
· Product names.
· Font names and sizes.
· Html and Xml tags.
Loc specific testing on loc builds will be primarily done by the windows Intl test team but as feature area owners we should test the functionality is not dependent on any particular locale being present. The following are some areas that need to be considered by each feature team when creating loc test cases:
1. User Locale Awareness:
· Date and Time
Area | Title |
Calendar System
| Check with non-Gregorian Calendars. Some of them are Japanese Emperor Era, Taiwan calendar, Korean Tangun Era calendar. |
Date Formatting | Change date format in regional settings. Check with both Long date and short date formats. Long Date English (United States): Tuesday, August 7, 2007 Short Date English (United States): 08/07/2007 |
Time Formatting | Use a 12-hour or 24-hour clock. Use a character other than “:” to separate hours/minutes/seconds. This can be set in the Advanced options for the regionals ettings. Verify the date/time displayed in the console matches the user settings. |
2. Keyboards and Input Methods
Area | Title |
IME/Keyboard layout | Verify IME (Input Method Editor) support is present for EA languages. The default keyboard layout should match the language. |
International text | Enter international text into all available input fields. Cut/copy/paste international text. Apply different types of fonts to international text.
|
3. Encoding and Unicode:
Area | Title |
Encoding and Unicode | Verify the localized UI showed correctly on different system locale. Verify the text displayed correctly with multilingual characters. Make sure that text conversions between encodings that use different numbers of bytes per character do not cause buffer overflows, memory leaks, or text truncations |
4. Sorting:
Area | Title |
Sort | Check the correct sort result depends on user locale. Compare the sort order of a collection before and after changing the user locale. |
5. Turkish Specific
==========
