Free Accessibility Statement Generator
Generate a WCAG 2.2-compliant accessibility statement for your website. Covers ADA compliance, the EU Web Accessibility Directive, and UK PSBAR requirements.
Why Your Website Needs an Accessibility Statement
Accessibility law is no longer a niche concern. It's one of the fastest-growing areas of web compliance litigation globally.
ADA Title III website lawsuits hit a record 4,605 cases in 2023, up from just 2,352 in 2018: nearly doubling in five years. These cases are filed against businesses of every size, in nearly every industry. Retail, hospitality, healthcare, financial services, and SaaS companies have all faced claims that their websites are inaccessible to users with disabilities. Plaintiffs' law firms have industrialized the process: they use automated scanning tools to identify non-compliant sites at scale, then file in bulk. An accessibility statement (and genuine efforts toward WCAG compliance) is your first line of defense.
In the European Union, the Web Accessibility Directive (Directive 2016/2102/EU) requires all public sector bodies (and large private organizations in many member states) to publish a formal accessibility statement. The statement must follow a specific structure, declare conformance status against WCAG standards, describe known limitations, provide contact information for users who encounter barriers, and explain the enforcement procedure available if the organization fails to respond. The European Commission has a model accessibility statement that member state regulators use as a compliance benchmark.
In March 2024, the US Department of Justice issued its long-awaited final rule under ADA Title II, formally requiring state and local government websites to conform to WCAG 2.1 Level AA. This makes WCAG compliance a codified federal legal requirement for government entities, and signals that Title III rules for private businesses are likely to follow. Courts are already citing WCAG 2.1 as the benchmark for what "accessible" means under Title III. Publishing a WCAG-referencing accessibility statement is now considered essential risk management for any US-facing website.
WCAG 2.2 became the official W3C recommendation in October 2023, superseding WCAG 2.1 as the current standard. WCAG 2.2 adds nine new success criteria, with particular focus on mobile usability and cognitive accessibility: addressing needs that were underserved in earlier versions. It also removes criterion 4.1.1 (Parsing), which had become largely obsolete with modern browser behavior. Organizations whose accessibility statements still reference only WCAG 2.1 should consider updating; while 2.1 remains legally valid in most jurisdictions, 2.2 is what auditors, plaintiffs' experts, and regulators increasingly cite.
In the United Kingdom, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (PSBAR 2018) require all public sector websites to meet WCAG 2.1 AA and publish an accessibility statement. The Government Digital Service (GDS) actively monitors compliance and can take enforcement action against non-compliant bodies. While PSBAR applies specifically to public sector bodies, the broader accessibility obligation (and the litigation risk from disabled users) extends to private sector organizations as well. Canada's Accessible Canada Act and Australia's Disability Discrimination Act create parallel obligations in those jurisdictions. Global best practice is converging on the same answer: publish an honest accessibility statement, acknowledge what you have and haven't achieved, and provide a route for users to flag problems.
Who Needs One
Any public sector body in the EU or UK, any US business serving the public, any organization subject to ADA, PSBAR, or the EU Web Accessibility Directive, which in practice means most websites.
Without One
ADA Title III lawsuits, EU regulatory enforcement, UK GDS monitoring, reputational damage, and a signal to plaintiffs that accessibility has not been taken seriously by your organization.
With a Good One
Demonstrated good faith, a clear contact route for users with accessibility needs, documented compliance status, and a starting point for continuous improvement toward full WCAG conformance.
What Your Accessibility Statement Must Include
A complete breakdown of every section the generator produces for you.
Conformance Status
A clear declaration of whether the site is fully conformant, partially conformant, or not conformant with WCAG at Level A, AA, or AAA. Honesty here matters: overstating compliance creates legal exposure.
WCAG Version Referenced
Specifies which version of WCAG, 2.1 or 2.2: the conformance claim is made against. WCAG 2.2 is the current W3C standard as of October 2023 and is increasingly the expected reference.
Known Limitations
A documented list of specific content or features that do not fully meet the standard, including the reason (third-party content, legacy code being updated, etc.) and the workarounds available to users.
Technical Specifications
The technologies the accessibility depends on: HTML, CSS, WAI-ARIA, JavaScript. Also lists the browsers and assistive technologies the site has been tested with for compatibility.
How to Report Accessibility Issues
A clear mechanism for users to flag barriers they encounter. This is required by both the EU Directive and PSBAR, and is best practice under ADA. Response timeframes should be specified.
Contact Information
The designated accessibility contact (email address, phone number, or online form) where users can reach someone who is actually responsible for accessibility issues and can respond meaningfully.
Enforcement Procedure (EU/UK)
For EU and UK organizations, a description of the enforcement body that users can contact if they receive an unsatisfactory response: typically the national accessibility enforcement authority.
Last Review Date
The date the statement was last reviewed and updated. Required by the EU Web Accessibility Directive. Demonstrates active maintenance and good faith. Annual reviews are best practice.
Alternative Contact Methods
If the primary contact method is itself inaccessible to some users, alternative routes should be provided. This might include a phone number, postal address, or relay service information for users who cannot use email.
Frequently Asked Questions
Everything you need to know about Accessibility Statements
Further Reading
Go deeper on this topic with our guide.
FreeTOS vs Paid Accessibility Tools
Some accessibility platforms charge significant monthly fees. Here's how FreeTOS compares for accessibility statement generation.
| Feature | FreeTOS | Termly | AudioEye |
|---|---|---|---|
| Price | $19 a month | $12/mo+ | $49/mo+ |
| Free Accessibility Statement | Yes | No | No |
| Includes Consent Banner | No (statement only) | Yes | Yes |
| WCAG 2.2 Coverage | Yes | Yes | Yes |
FreeTOS generates the accessibility statement document. For automated site scanning, ongoing monitoring, and overlay widgets, paid tools like AudioEye may be appropriate. For the statement document itself, FreeTOS provides everything you need.
How to Add Your Accessibility Statement to Your Website
Where to publish your accessibility statement and how to make it findable by users and regulators.
WordPress
- Generate your accessibility statement on FreeTOS
- Create a new WordPress page titled "Accessibility Statement"
- Paste the HTML in the Custom HTML block or HTML editor mode
- Set the URL slug to /accessibility-statement
- Publish and add a link to your footer menu
- Consider also linking from your site's main navigation or help page
- Review and update annually or after major site changes
Shopify
- In Shopify Admin, go to Online Store, then Pages
- Create a new page titled "Accessibility Statement"
- Switch to the HTML editor and paste the generated content
- Set a clean handle: accessibility-statement
- Add the page to your footer navigation links
- Verify the link is visible from every page of your store
- Update the statement whenever you add major new features or third-party apps
Any HTML Site
- Download the accessibility statement HTML from FreeTOS
- Save as accessibility-statement.html and upload to your server
- Add a footer link on every page pointing to /accessibility-statement
- Ensure the page itself is accessible: proper heading structure, sufficient contrast, keyboard navigable
- Consider adding a skip-to-content link on all pages while you're at it
- Test with a screen reader (NVDA, VoiceOver, or JAWS) to verify the statement is readable