Checklist: auditing and implementing website accessibility
For: Website owners
Updated: 2026-11
An accessible website comes about in seven steps: set scope and target standard, test automatically and manually, fix the reused components, check forms and interactive elements with keyboard and screen reader, clean up content and PDFs, publish an accessibility statement and introduce a review routine for new content.
This checklist is for those responsible for websites of authorities, associations and companies that want to reach WCAG 2.1 or 2.2 level AA, whether because of eCH-0059, the European Accessibility Act or their own standards.
It is structured so that the building blocks that affect many pages are fixed first. That saves most effort.
The checklist
- 01
Set scope and standard
Determine which pages, flows and documents are covered and which standard applies.
Done when: A short document names the target standard, such as WCAG 2.2 AA, and lists the page types and flows covered.
- 02
Test automatically
Test the main page types with an automated tool and group findings by component.
Done when: A findings list exists, grouped by component rather than by page.
- 03
Test manually
Run the main flows with keyboard only and with a screen reader, checking focus, order and announcements.
Done when: Every main flow can be completed with keyboard and screen reader, or the deviation is documented.
- 04
Fix components
Fix navigation, buttons, form fields, dialogs and colour system at the source.
Done when: The fixed components pass the re-test; contrast reaches the required values.
- 05
Check forms and error messages
Design labels, required fields, error and status messages so they are announced.
Done when: A deliberately wrongly completed form is reported back understandably by the screen reader.
- 06
Clean up content and PDFs
Revise text alternatives, link texts, heading structure and relevant PDFs.
Done when: Current pages have meaningful text alternatives and a logical heading structure; relevant PDFs are tagged.
- 07
Publish statement and introduce routine
Publish an accessibility statement with status, limitations and contact, and check new content before publication.
Done when: The statement is linked and a review routine is part of the editorial process.
Common mistakes
- —Relying on an overlay script instead of fixing the causes in the code.
- —Fixing page by page instead of repairing the components.
- —Testing only automatically and assuming the website is therefore accessible.
- —Forgetting PDFs, which often make up most of the content at authorities.
What this checklist does not cover
- —The checklist does not replace legal assessment of whether and to what extent an organisation is obliged to be accessible.
- —Full proof of conformity requires checking every success criterion; the checklist describes the approach, not each individual test.
- —Testing with people with disabilities yields insights no tool provides and is not covered here.
Parent service: Website Development
Matching offers
Accessible website
We audit existing websites against WCAG with automated and manual tests, fix the reused components, support content and PDFs and write the accessibility statement. New websites are built to WCAG 2.2 level AA from the start, compatible with eCH-0059 and the requirements of the European Accessibility Act.
Website relaunch with an SEO and GEO foundation
A relaunch that protects visibility instead of losing it: we capture every URL with impressions from Search Console, build the new website on Next.js with technical SEO, structured data and a GEO foundation, permanently redirect old URLs to the matching new pages, and check indexing and redirects after go-live.
FAQ
WCAG 2.1 or 2.2?
eCH-0059 requires WCAG 2.1 AA for the Confederation. New builds should aim for 2.2, which is backwards compatible.
Which screen reader is suitable for testing?
Common combinations are NVDA with Firefox or Chrome on Windows and VoiceOver with Safari on Apple devices.
How often should you test?
New content and features before publication, the whole website after major changes and periodically.
More checklists
Checklist: documenting technical and organisational measures (TOMs)
TOMs are documented credibly when they start from the actual estate: record systems and data, determine protection needs, record measures for access, authorisation, encryption, availability and logging per system, include processors, name owners and review effectiveness periodically.
Checklist: accepting software without nasty surprises
Software acceptance succeeds when acceptance criteria are fixed before testing: test cases derived from requirements, realistic test data, testing by future users, a clear classification of defects by severity, a signed protocol and an orderly handover to operations with documentation and access.
Checklist: ready to report a cyberattack within 24 hours
A company is ready to report when it has clarified its applicability under the ISA, regulated roles and 24/7 reachability, has a decision aid on the reporting duty, prepared the initial report, knows parallel reporting duties, obliged providers to cooperate and exercised the process.