Website · THE NO-PANIC PLAN
Create and maintain an evidence-based accessibility statement
An accessibility statement helps visitors understand what you evaluated, what barriers remain, and how to get help. It is not an accessibility audit, certification, or proof of WCAG conformance. This workflow follows W3C guidance to define scope, evaluate a representative sample with human judgment, report verified findings in plain language, and maintain a findable statement. Local rules may require specific content; check applicable requirements with the responsible authority.
MISSION Create a plain-language website accessibility statement grounded in a documented, appropriately scoped evaluation; disclose known barriers, tested scope and contact routes, then keep it current.
Draft an evidence-based accessibility statementTHE REAL-WORLD BIT
What happens outside this browser tab?
Define the website scope and exact standard/level to evaluate; map important templates and complete journeys and select a documented sample; combine suitable automated checks with manual and assistive-technology testing; draft a plain-language statement from verified results; then independently review its claims, publish it where visitors can find it, and assign ongoing maintenance.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Set the statement's scope and the standard you will actually test
Name the website or service, its public URL, owner, intended users, and the outcome this work should produce: a useful, honest statement about accessibility. Decide which product areas are in scope (for example, public pages, account journeys, mobile layouts, documents, and embedded services), the languages covered, and the evaluation date. If you plan a WCAG claim, select the exact WCAG version and level before testing; WCAG-EM asks evaluators to define scope and target level up front. Check which laws or procurement requirements apply in the relevant jurisdiction with qualified counsel or the responsible authority. Do not copy a standard or legal claim from another organization. Keep a short scope note so later readers can tell what was included and what was not. (Sources 2, 3, 5)
- 02
Map key journeys and choose a representative sample
Inventory the site's page templates, languages, interactive components, and complete user journeys. Include high-impact and unusual paths such as search, sign-in, checkout or application forms, validation errors, support, and third-party embeds where they are part of the user experience. If you cannot inspect every page, document how you selected a representative sample and include pages with distinct layouts or functionality; a random handful of landing pages is not a defensible substitute. Record the browser, operating system, viewport, assistive technologies, and versions used for evaluation. Include any limitations in the sample or test environment. WCAG-EM 2 provides a structured method for defining scope, exploring the product, and selecting a sample; seek an experienced evaluator for formal conformance work. (Sources 2, 3)
- 03
Evaluate the sample with automated checks and human testing
Run suitable automated checks to find likely code and markup issues, then manually test the same sample and complete journeys. Check keyboard-only operation, visible focus, logical focus order, headings and landmarks, form labels and error recovery, text resize and zoom, contrast, meaningful alternative text, captions or transcripts, and understandable names and instructions. Use screen readers or other assistive technologies where available and relevant; record the actual combinations tested. For each finding save the page or component, steps to reproduce, user impact, evidence, severity, owner, and status (including not tested or inconclusive). Automated tools can miss barriers and can report false positives, so do not turn a scan result into a pass or conformance claim. Retest fixes and preserve the date and scope of the result. (Sources 2, 3, 4, 5)
- 04
Write a plain-language statement from verified findings
Use Accessibility Statement Generator (Nirmion tool 34666) to draft the statement from the evidence you just assembled; the generator does not scan or certify the site. State the product and scope, the accessibility standard and level actually evaluated (if any), evaluation date and method, tested browsers or assistive technologies, accessibility measures, and known barriers in terms visitors can understand. For every known limitation, explain which content or task is affected, what a user may experience, any available accessible alternative or workaround, and how to report the issue. Avoid vague promises such as "fully accessible," unsupported claims of WCAG compliance, and legal conclusions. Provide a working, accessible feedback channel and realistic response expectations. Keep sensitive test data out of the statement. (Sources 1, 2, 4, 5)
- 05
Review, publish where people can find it, and keep it current
Use Accessibility Statement Review (Nirmion tool 30048) to check completeness, clarity, assumptions, and follow-up prompts; it reviews statement text and does not validate site conformance. Have the accessibility owner confirm every factual claim against the evaluation record, test the contact route, and ask a person with relevant accessibility expertise to review any conformance statement. Publish the statement in a predictable location such as the footer and help area, and ensure its link and page are themselves usable. Assign an owner and review date; update it after substantial releases, resolved or newly found barriers, changes to tested environments, or contact-channel changes. Track incoming reports through to a response and retest remediation. Keep the report and statement date aligned, and label untested areas honestly. Check additional local requirements where applicable; W3C guidance does not decide your jurisdiction-specific legal obligations. (Sources 1, 2, 3)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-09