Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

Accessibility statement publication

accessibility-statement-publicationDomain: accessibilityType: policy

Description

An accessibility statement is the public-facing document that records, in regulator-readable form, what the platform's current accessibility posture actually is. The document sits on the public website at a stable URL (the convention is /accessibility, footer-linked from every page), and it functions as both an operator commitment to users and the artifact a regulator reaches for first when an inquiry opens. The content set has converged across regimes onto roughly the same five elements: the conformance target standard (typically WCAG 2.1 or 2.2 at AA), the conformance status against that standard, the named limitations and the remediation timeline for each, the contact route for users who encounter a barrier, and the date of the most recent substantive review. The authoring layer that produces the document and the assessment layer that determines what it says are two different exercises and benefit from different actors. The assessment comes from an accessibility audit (a third-party VPAT-format review or an internal WCAG-conformance audit using axe DevTools, WAVE, or equivalent), and the audit output is what populates the named-limitations and conformance-status fields. The authoring is a writing task that translates the audit output into the public document; the trade-off is that audits produce findings in technical accessibility-criterion vocabulary, and the public statement has to render those into language a regulator and a user can both read. The third layer (the review-cadence governance) is the one operators most often under-invest in: a statement dated three years ago against a product that has shipped four major redesigns since does not survive a regulator inquiry, even if the current accessibility posture happens to be better than the older statement claims. Annual review is the de-facto floor; quarterly is the cadence most large operators have moved toward. The statutory anchors are the European Accessibility Act (Directive (EU) 2019/882) Article 13 for in-scope products and services, the EU Web Accessibility Directive (Directive (EU) 2016/2102) for public-sector bodies, US Section 508 (29 U.S.C. §794d) for federal contractors via the Section 508 Refresh, UK PSBAR (the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018) for UK public-sector entities, the ADA reading at 42 U.S.C. §§12101-12213 as interpreted by DOJ in its 2024 Title II web rule, the UK Equality Act 2010 c. 15, and the Ontario AODA. The pattern across all of these is that regulators have been more forgiving of partial-conformance statements with named gaps and dated remediation commitments than of full-conformance claims that turn out not to survive an actual audit; accuracy is structurally worth more here than aspiration.

Required by (3 regulations)

  • ADA

    42 U.S.C. §§12101–12213

  • EAA

    Article 13 — provision of information to consumers.

    Directive (EU) 2019/882

  • Equality Act

    Equality Act 2010, c. 15

Fulfilled by (1)

  • In-house build · low effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • accessibility-statement page
  • review-cadence notes

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn