Define document-specific scope
Most accessibility statements are written for websites and web applications. They describe WCAG conformance levels, list known issues, and provide a feedback mechanism. This is necessary but incomplete for organizations that publish documents. If your organization distributes PDFs, Word files, presentations, or HTML documents through any channel, your accessibility statement must address document-specific workflows.
Begin by inventorying every document publication channel: website download pages, email attachments, learning management systems, intranet portals, public records databases, and third-party distribution platforms. Each channel has different accessibility characteristics and different user expectations. A statement that says "our website meets WCAG 2.2 AA" does not cover the PDF linked from that website if the PDF is inaccessible.
For each channel, describe what document formats are published, what accessibility standards those formats conform to, and what process ensures ongoing conformance. Be specific. "We strive to make our documents accessible" is not a statement. "All public-facing PDF documents published after January 2026 are converted to tagged PDF/UA-1 format and validated against WCAG 2.2 AA success criteria before publication" is a statement.
Include explicit scope boundaries. If certain document types are not yet covered by your accessibility process (legacy archives, third-party submitted content, user-generated materials), acknowledge these gaps and describe your remediation timeline. Honest scope boundaries build credibility. Vague universal claims invite legal challenge.
Make accurate conformance claims
WCAG conformance claims have specific technical requirements defined in the WCAG 2.2 specification. A valid conformance claim must identify the conformance level (A, AA, or AAA), the specific WCAG version, the scope of content covered, and any relied-upon technologies. Many accessibility statements make claims that do not meet these requirements, which creates both legal and credibility risk.
For document workflows, conformance claims should distinguish between the accessibility of the document content and the accessibility of the platform through which documents are accessed. A perfectly tagged PDF served through an inaccessible download portal fails the user even though the document itself is conformant. Address both layers in your statement.
Avoid claiming conformance for content you do not control. If your platform hosts user-uploaded documents, state that platform accessibility is maintained at WCAG 2.2 AA while user-submitted document accessibility is the responsibility of the uploading party. Provide tools and guidance to help users create accessible uploads, but do not extend your conformance claim to content you have not validated.
Update conformance claims when your process, tooling, or scope changes. A conformance claim made in 2024 that has not been reviewed since is stale evidence. Pair your accessibility statement with a "last reviewed" date and a review schedule commitment.
Publish support and escalation paths
An accessibility statement without a support mechanism is incomplete. Users who encounter barriers need a clear path to request assistance, report problems, and receive timely resolution. The support path you publish becomes a contractual commitment that your organization must honor.
Define three elements in your support path: how to report an issue (email, web form, phone), what information to include (document name, URL, description of barrier, assistive technology used), and what response timeline to expect (acknowledgment within one business day, resolution or workaround within five business days for severity-1 issues).
Provide an alternate format request mechanism. Users should be able to request an accessible version of any published document. Define supported alternate formats (HTML, tagged PDF, large print, plain text), expected fulfillment timelines, and any limitations. Under ADA Title II, public entities must provide equally effective communication, which may require alternate formats for document content.
Publish an escalation path for unresolved issues. If initial support does not resolve the barrier, users should know how to escalate to a supervisor, accessibility coordinator, or ADA compliance officer. An escalation path demonstrates organizational commitment and provides a safety valve for the support team when issues exceed their authority or expertise.
Track all support interactions and resolution outcomes. This data serves dual purposes: it identifies document accessibility gaps that need systemic fixes, and it provides evidence of good-faith effort during compliance reviews or complaint investigations.
Address alternate format commitments
Alternate format requests are a core component of document accessibility obligations, particularly for public entities. Your accessibility statement should describe which alternate formats you support, how users request them, and what turnaround time they can expect. Vague commitments like "we will work with you to provide accessible alternatives" create unpredictable obligations and frustrate users.
Common alternate formats include HTML (most universally accessible), tagged PDF (widely supported but viewer-dependent), large print, plain text, and audio description for visual content. Not every organization needs to support every format. Define your supported formats based on your audience needs and operational capacity, and be transparent about formats you do not support.
Set realistic fulfillment timelines for alternate format requests. Simple text-to-HTML conversions might take one to two business days. Complex documents with tables, figures, and interactive elements might take five to ten business days. Publishing these timelines sets user expectations and gives your team clear performance targets.
For documents that cannot be provided in an alternate format (proprietary interactive tools, signed legal documents with format-specific requirements), describe the limitation and provide the closest available alternative. Complete transparency about limitations builds more trust than unrealistic promises.
Maintain and update the statement regularly
An accessibility statement is a living document that must evolve with your organization. Schedule quarterly reviews to verify that stated processes, contact information, supported formats, and conformance claims still match operational reality. When your workflow changes, the statement should change at the same time.
Assign statement maintenance to a specific role, not a committee. A named owner is responsible for triggering quarterly reviews, incorporating process changes, and verifying that stated commitments are being met. Without named ownership, accessibility statements age silently until an audit or complaint reveals the gap.
Version your accessibility statement and maintain a changelog. Users and auditors should be able to see when the statement was last updated and what changed. This demonstrates active maintenance rather than one-time compliance theater.
Test your support and escalation paths regularly. Submit test requests through your published channels to verify that response timelines are met, that the right people receive escalations, and that resolution workflows function as described. A support path that exists on paper but fails in practice creates liability rather than reducing it.
Frequently asked questions
Can we reuse a generic website accessibility statement for documents?
Only as a starting point. Document workflows require additional details about supported formats, alternate format request handling, document-specific conformance claims, and per-channel publication coverage that generic website statements do not address. Start with your website statement and extend it with document-specific sections.
Should alternate formats be mentioned directly in the statement?
Yes. Specify which alternate formats you support, how users request them, and what response timeline to expect. Vague language like "reasonable accommodations will be provided" does not meet user expectations or demonstrate compliance readiness. Be specific about what you offer and what your limitations are.
Is an accessibility statement legally required?
Requirements vary by jurisdiction and sector. The European Accessibility Act and EN 301 549 require accessibility statements for public sector bodies in the EU. In the US, Section 508 requires federal agencies to publish accessibility information. Even where not legally required, an accessibility statement demonstrates good faith and provides operational structure for handling accessibility issues.
How detailed should conformance claims be?
Detailed enough to be verifiable. State the specific WCAG version and conformance level, the scope of content covered, any relied-upon technologies, and any known limitations. A claim of "WCAG 2.2 AA for all documents published after January 2026 through our public website" is verifiable. A claim of "we follow accessibility best practices" is not.
What happens when we discover a conformance gap after publishing the statement?
Update the statement to acknowledge the known limitation, describe your remediation plan and timeline, and ensure your support path can handle requests related to the gap. Honest disclosure of known issues with active remediation plans demonstrates better compliance posture than an outdated statement that claims conformance you cannot deliver.
Sources and references
Need help applying this to your workflow?
Start a conversion request or contact our team for an implementation plan mapped to your document profile.