Accessibility Statement Editor for Evidence-Based Declarations

An accessibility statement template provides a structured place to explain what part of a website has been assessed, which accessibility standard was considered, what barriers remain, and how people can request help. Enter the site owner, assessed website, supported conformance status, assessment method, date, known limitations, improvement plans, and a genuine contact address. The editor produces an editable Markdown statement and a JSON record from those facts. It does not scan the website or certify compliance. Claims such as “fully conformant” must come from an appropriate assessment carried out by the site owner or qualified reviewer, not from completing a text-generation form.

Accessibility Statement Template At a Glance

What a Meaningful Accessibility Statement Should Tell People

A public statement should make it clear who is responsible for a website, what was evaluated, when that evaluation happened, and what people should do if they encounter a barrier. Those facts are more valuable than broad claims that the organization cares about inclusion. Some legal regimes specify particular statement elements, review intervals, and complaint or enforcement procedures, but requirements differ by jurisdiction and type of organization. The editor deliberately avoids asserting that a generic draft satisfies every law. It encourages a specific, evidence-supported declaration that can be reviewed by the organization's accessibility, legal, and support teams before publication.

Identifying the Website and the Scope of the Review

A company may operate many websites, embedded tools, third-party booking interfaces, and mobile applications. One accessibility assessment may cover only a defined subset of those properties. Enter the actual URL of the website concerned, then clarify in the assessment method which templates, user journeys, or components were tested. A broad statement about an entire organization is misleading when only the homepage was reviewed. Think about login, checkout, search, forms, document downloads, and connected services. If a critical third-party widget was not in scope, say so in the final reviewed text. Honest scoping helps users understand what evidence underpins each claim.

Choosing a Conformance Status Carefully

The editor offers fully conformant, partially conformant, and not conformant as selectable declarations. These are statements supplied by the editor's user, not the outcome of a testing engine. Choose the category only after reviewing evidence against the claimed standard and the evaluated pages. A site with unresolved barriers should not be described as fully conformant merely because most elements pass automated scans. Likewise, a partially conformant declaration should explain relevant limitations instead of sounding like an unexplained negative label. If no suitable assessment has been completed, do not publish an unverified conformance claim. Complete the review first and use an accurate description of what is currently known.

Naming Standards Without Overpromising

Web Content Accessibility Guidelines, often called WCAG, provide testable success criteria covering perceivable, operable, understandable, and robust content. Different contracts and laws may reference different versions and conformance levels. Enter the standard actually used in the assessment, rather than selecting the newest acronym simply because it looks authoritative. A review of WCAG 2.2 AA does not automatically establish legal compliance or mean that every assistive technology combination works perfectly. The editor treats standards as user-provided descriptions and does not audit individual success criteria. For a particular interface, an accessible palette builder can support color selection, but successful color checks alone cannot establish overall conformance.

Describing the Assessment Method

The method section is where the statement becomes meaningful. Explain whether reviewers used manual keyboard testing, screen readers, browser accessibility inspectors, automated checks, user testing, or a structured audit. Include the key workflows and platforms when they materially affect the result. Automated tools can catch certain markup and contrast issues, but they cannot judge every interaction, reading order, label purpose, cognitive demand, or task completion outcome. A vague assertion that “the website was tested” leaves people unable to judge the strength of the conclusion. The editor requires an assessment-method entry so the declaration is tied to a real process rather than an unsupported badge.

Recording Known Barriers With Useful Detail

People visiting an accessibility statement often want to know whether a particular feature will work for them today. Instead of saying that some areas may be inaccessible, identify the affected function and describe the obstacle in plain language. For example, a keyboard user may be unable to reach a date picker, or a document download may contain headings that are not exposed semantically. Explain workarounds if they genuinely exist, but do not present a difficult alternative as equivalent access without considering the user's needs. The form requires limitations when the selected status is not fully conformant; the editor cannot verify that every barrier has been identified, so maintain a separate defect register.

Improvement Plans and Realistic Commitments

An improvement section can identify what is being repaired, who is responsible, and whether a credible target date has been agreed. Avoid promising precise completion dates unless the organization has approved them. Accessibility remediation often crosses design systems, third-party dependencies, content publishing workflows, and procurement, so some fixes take longer than a small CSS adjustment. Users benefit from knowing what is being actively addressed, but an outdated promise can make a statement less trustworthy. If no timetable is available, describe the next review step rather than inventing milestones. The draft contains neutral language that can be replaced with verified commitments before publication.

Making Feedback and Alternative Access Practical

A statement should provide a real way to request help when the site is not usable. Enter an email address monitored by the responsible team and explain what information a visitor can provide, such as the affected page and desired response format. Depending on legal requirements and organizational policy, you may also need a telephone number, physical address, formal complaint route, response timeframe, or enforcement details. This editor does not send mail or confirm the contact inbox exists. Test the route yourself and make sure people can use it without being forced through the same inaccessible process they are reporting.

Avoiding Generic Legal or Accessibility Claims

Statements sometimes become boilerplate that says every user is welcome without addressing practical barriers. Such language may sound positive yet tell a visitor very little about whether they can complete an important task. A more helpful statement explains the assessment boundary, standard, actual findings, and feedback mechanism. Do not paste certification logos or claim compliance merely because a testing plugin displayed a favorable score. The editor's disclaimer is deliberate: generating polished prose does not establish that an audit occurred or that legal duties have been met. The owner must decide what can responsibly be said and have the declaration reviewed where necessary.

Example: Updating a Partially Conformant Website

Imagine a municipal information site that has completed manual tests of its main navigation and forms, but a number of downloadable PDFs remain inaccessible. A defensible statement might identify the tested web pages, the standard used, the audit date, and the specific PDF barriers. It could describe an available alternative format request process, provided staff actually respond to those requests. The improvement section could explain that replacement documents are being prepared, without promising an unsupported deadline. The partially conformant label becomes informative because readers can identify which services may be affected. The editor can format this information, but it cannot determine whether the municipal service is legally compliant.

Maintaining Accuracy After Website Changes

A statement is a snapshot of knowledge at a particular date. New components, campaign landing pages, plugins, design changes, and translated content can introduce issues after a review. Establish a process for checking the statement when the website changes materially and for recording newly discovered accessibility barriers. The assessment date should be updated only when a new assessment actually occurs; changing a date field without new testing can misrepresent the evidence. Maintain a list of outstanding issues and refer back to the reported user impact when prioritizing repairs. Accurate maintenance matters more than publishing a polished declaration once and forgetting it.

Reviewing the Markdown and JSON Exports

The Markdown output is intended for editing in a content management system or document editor, while JSON retains a structured version of the entries for internal review. Neither export publishes the statement, scans the website, sends email, or verifies that your contact address accepts messages. Review the generated copy for jurisdiction-specific requirements, correct scope, accessible terminology, and accidental omissions. Remove unsupported assertions and protect sensitive data if internal testing notes are incorporated into a public disclosure. The final statement should remain readable without requiring visitors to decode audit jargon, and it should be consistent with the accessibility experience people actually encounter.

Accessible Publication of the Statement Itself

Even an accurate accessibility statement can be hard to use if the page containing it is inaccessible. Publish it as properly structured text with meaningful headings, accessible links, adequate contrast, usable keyboard navigation, and a contact mechanism that does not depend on inaccessible widgets. Keep the page findable through ordinary site navigation without burying it in a complex footer. If you offer the statement in a downloadable format as well, ensure the web version remains available to people who cannot use that file type. A document about accessibility should demonstrate the same care for basic interaction and comprehension as the rest of the website.

Frequently Asked Questions About Accessibility Statements