Are you from the public sector?
Are you from the public sector?
Test the complete functionality of AccessGO risk-free for 7 days free of charge.
A structured WCAG checklist helps you implement digital accessibility systematically and traceably. It provides a clear overview of the most important requirements and facilitates practical application—regardless of whether you are following WCAG 2.0, WCAG 2.1, or already WCAG 2.2. Differences between versions are made transparent, allowing you to respond specifically to current standards.
This page provides practical tips, highlights typical challenges, and helps you use the WCAG checklist as an understandable guide in your projects. You receive a well-founded overview, without legal guarantees, but with concrete added value for the accessible design of your digital offerings.
The WCAG checklist is systematically structured and divided into several levels, each assigned to the guidelines of the Web Content Accessibility Guidelines (WCAG). It begins with the four fundamental principles: Perceivable, Operable, Understandable, and Robust. Under these principles, various guidelines are grouped, which in turn are described by concrete success criteria. Each success criterion can be specifically tested and forms the basis for individual test points in the checklist.
Depending on the version—WCAG 2.0, WCAG 2.1, or WCAG 2.2—the checklist structure differs in scope and requirements. The WCAG 2.1 checklist contains additional criteria that particularly address mobile and new forms of interaction. The WCAG 2.2 checklist expands this with further aspects, such as operability for users with cognitive disabilities. The checklist serves as a central tool in the overall accessibility process: it enables structured testing and systematic implementation of requirements, from planning to regular review of digital offerings.
| Structural Level | Description and Differences |
|---|---|
| Fundamental Principles | Perceivable, Operable, Understandable, Robust—identical in all WCAG versions |
| Guidelines | Subordinate requirements for each principle, similar in all versions but with expansions in 2.1 and 2.2 |
| Success Criteria | Concrete test points, supplemented in WCAG 2.1 and 2.2 with additional criteria (e.g., for mobile use and cognitive barriers) |
| Checklist Items | Practical implementation and assignment to success criteria, varying in scope depending on WCAG version |
The four fundamental principles of the WCAG checklist—Perceivable, Operable, Understandable, and Robust—form the foundation for every assessment of digital accessibility. They provide direction on how content and functions must be designed so that as many users as possible can access them regardless of their individual abilities. For checklist logic, this means that all test points are always assigned to one of these principles, creating clear guidance for practice.
Each principle can be illustrated through concrete application examples: Perceivable requires text alternatives for images, for instance, so that users with visual impairments can also access information. Operable demands that all functions of a website be usable via keyboard. Understandable is supported, for example, by a clear navigation structure, while Robust ensures that content is reliably interpreted by different assistive technologies. Unlike other standards such as EN 301 549 or ISO 9241, the WCAG checklist focuses directly on the user perspective and their concrete usage scenarios.
7 days unrestricted access. No payment details required.
The success criteria of the WCAG checklist are precisely formulated requirements that make it measurable whether digital content is designed accessibly. Each criterion is assigned to one of three conformance levels: A, AA, or AAA. These levels differ in their stringency and specify how comprehensively accessibility must be implemented. While Level A represents the most basic requirements, Level AA requires additional, more extensive criteria to be met. Level AAA finally encompasses the highest standards, which are rarely fully achieved in practice.
In assessment practice, the WCAG checklist is used to systematically test which success criteria are met. This is usually done through a combination of automated tests and manual reviews. Depending on the objective—such as legal requirements or internal quality standards—it is determined to which level the criteria must be met. The results are documented and serve as the basis for further optimization.
| Conformance Level | Example Success Criteria and Assessment |
|---|---|
| Level A | Basic requirements, e.g., alternative texts for images; minimum standard, usually mandatory |
| Level AA | Extended requirements, e.g., sufficient color contrast; often a legal requirement |
| Level AAA | Highest requirements, e.g., extended text alternatives; rarely fully required |
The WCAG checklist evolves with each new version, reflecting the current state of digital accessibility requirements. While WCAG 2.0 lays the foundation, WCAG 2.1 expands the checklist particularly with criteria for mobile use and users with cognitive disabilities. WCAG 2.2 introduces further success criteria that especially strengthen operability and accessibility for an even broader user group. For practical application, this means that existing checklists must be regularly updated to meet the new standards.
In practice, it is important to know the differences between versions in order to specifically implement the respectively required criteria. Newly added or adapted success criteria often concern areas such as touch operation, additional navigation aids, or simplification of interactions. The following table illustrates the most important differences and innovations in the checklists of WCAG versions.
| WCAG Version | Special Features and New Criteria in the Checklist |
|---|---|
| WCAG 2.0 | Basic structure with 61 success criteria; focus on desktop use and general accessibility |
| WCAG 2.1 | 17 new success criteria, e.g., for mobile operability, cognitive disabilities, and low vision |
| WCAG 2.2 | 9 additional new success criteria, e.g., for drag-and-drop, target size, and additional navigation aids |
Testing digital accessibility is carried out in a structured way based on the WCAG checklist and includes several consecutive steps. First, during preparation, the relevant page areas and use cases are defined and the WCAG criteria to be tested are determined. During execution, the individual checkpoints are worked through systematically, using both automated tools and manual testing methods. Follow-up includes documenting the results, assessing the barriers found, and deriving measures to remediate them.
Using testing tools can automatically capture many technical requirements, but it is not a substitute for manual review. Human assessment is essential, especially for content, design, or interactive elements. Combining tool-supported analysis with manual testing ensures comprehensive audit logic and increases the reliability of the results.
| Test step | Significance and typical methods |
|---|---|
| Preparation | Defining the audit scope, selecting WCAG criteria, planning the audit process |
| Execution | Systematic processing of the checklist, use of tools (e.g., screen readers, validators), manual tests |
| Follow-up | Documentation of results, assessment of barriers, derivation of improvement measures |
Schedule a free consultation and speak with one of our experts.
For practical implementation of the WCAG checklist, a step-by-step approach is recommended that can be seamlessly integrated into existing development and testing processes. At the outset, the checklist should be reviewed together as a team to clarify responsibilities and define the relevant checkpoints for the specific project. During development, the checklist can be used as an ongoing control instrument to address accessibility early on. In the testing phase, the implemented requirements are reviewed in a targeted manner, ideally using the four-eyes principle and involving different roles such as developers, designers, and quality assurance.
For efficient collaboration, it is advisable to integrate the WCAG checklist into digital project management tools and schedule regular coordination meetings. Typical practical examples include checking alternative text for images, ensuring keyboard operability of forms, or testing color contrast. Continuous documentation of results and open items makes follow-up easier and ensures transparency within the team.
The WCAG checklist plays a central role in the structured implementation of legal requirements for digital accessibility, such as those set out in the Accessibility Strengthening Act (BFSG) or the Barrier-Free Information Technology Ordinance (BITV 2.0). It serves as a practical tool to systematically capture the standards required by these regulations and to demonstrate compliance. Unlike other testing standards such as EN 301 549 or specific industry requirements, the WCAG checklist focuses on internationally recognized success criteria for web content.
As part of audits and internal reviews, the WCAG checklist enables traceable documentation of the measures carried out and the barriers identified. It helps demonstrate progress and identify optimization potential. However, no legal guarantees or liability commitments are provided; rather, the checklist should be understood as a tool for guidance and quality assurance.
When applying the WCAG checklist, typical challenges often arise in practice. A key misunderstanding is to view the checklist as a purely technical task and neglect content and design aspects. In addition, success criteria are sometimes interpreted too narrowly or too broadly, which leads to misinterpretations and makes implementation more difficult. Especially with complex web applications, certain checkpoints may be overlooked or assessed incorrectly.
The most common sources of error include relying uncritically on automated tests, failing to involve users with disabilities, and insufficient documentation of test results. To avoid these pitfalls, it is advisable to work through the checklist together as a team, incorporate different perspectives, and provide regular training on interpreting the criteria. Careful follow-up and continuous review help identify and resolve issues early.
7 days unrestricted access. No payment details required.
The WCAG checklist must be tailored to different areas of application to meet the respective technical and design requirements. For traditional websites, aspects such as text alternatives, navigation structures, and color contrast are the main focus. For web applications, interactivity, dynamic content, and the operability of complex components come to the fore. Mobile applications add further requirements, for example regarding touch operation, responsive design, and platform-specific navigation.
Depending on the industry, additional specifics may apply, for example in e-commerce (process guidance, form validation) or in the public sector (multilingualism, accessible documents). The following table shows the key differences and focus areas when applying the WCAG checklist for different platforms.
| Area of application | Focus areas and specifics of the WCAG checklist |
|---|---|
| Website | Text alternatives, clear navigation, color contrast, accessible forms |
| Web application | Interactive components, dynamic content, keyboard operability, focus management |
| Mobile application | Touch operation, target sizes, responsive design, platform-specific navigation |
| Industry-specific solutions | Process guidance, accessible documents, multilingualism, specific user groups |
A WCAG 2.1 checklist contains 17 additional success criteria compared to the WCAG 2.0 checklist. These new criteria particularly address mobile operability, users with cognitive disabilities, and people with visual impairments. For current projects, this means that testing methods should be adapted and additional tests—such as for touch operation or flexible layouts—should be planned to meet the expanded requirements.
The WCAG checklist provides a structured and practice-oriented foundation for systematically implementing digital accessibility. It covers the different requirements of WCAG versions and can be flexibly adapted to various platforms and project sizes. By integrating it into existing quality processes and combining automated and manual testing, it supports sustainable and traceable implementation of accessibility requirements.
For application in everyday project work, a step-by-step approach is recommended that involves all relevant team members and continuously integrates the checklist into development, testing, and documentation processes. This helps avoid typical sources of error and specifically address industry-specific considerations.
Check your homepage with the AccessGO quick check.
Identify risks and barriers according to WCAG standards.
Various tools are available for applying a WCAG checklist, including browser widgets (e.g., axe, WAVE), specialized testing software, and online validators. For larger projects, a combination of automated tools and manual tests is recommended, such as with screen readers or keyboard testing. Additionally, official resources and guidelines help correctly interpret the criteria and apply them within the team.
Various tools are available for applying a WCAG checklist, including browser widgets (e.g., axe, WAVE), specialized testing software, and online validators. For larger projects, a combination of automated tools and manual tests is recommended, such as with screen readers or keyboard testing. Additionally, official resources and guidelines help correctly interpret the criteria and apply them within the team.
A WCAG checklist should be used regularly during all project phases—ideally at the beginning, after significant development steps, and before launch. Continuous reviews are particularly important during ongoing maintenance or expansion of digital offerings. Testing intervals depend on the scope and dynamics of the project, but at least one review per release or after major changes is recommended.
An official WCAG 2.2 checklist in German is not yet centrally provided by W3C, but translations and practical compilations from specialist organizations do exist. For documentation purposes, traceable recording of tests is recommended. Audit-proof storage can be achieved through versioning and storage in the internal quality management system, ensuring all testing steps remain transparently traceable.
The WCAG checklist serves as the central foundation for structured documentation of accessibility measures. German-language translations and accompanying resources are available from trusted specialist organizations and official websites. For international projects, the English-language original should be used as a reference to avoid misunderstandings and ensure the current state of requirements.
