Accessibility checklist #

This checklist is for the accessibility lead, site administrator and editorial lead of a public body. It separates what Exponential provides from what your organization must do. The status words come from Accessibility standards: WCAG 2.2 AA Partly complies for the admin4 and admin4l administration; EN 301 549 and Section 508 Unverified; public designs not audited; no VPAT.

Note This page describes features and common practice; it is not legal advice. Check the law that applies to your organization with your legal counsel. Official texts: WCAG 2.2, EN 301 549, Directive (EU) 2016/2102, Section 508.

Contents #

1. The administration
2. The public design
3. Content
4. Testing
5. Statement and feedback

The administration #

• To do: Staff who need it use the admin4 design, which is built and tested against WCAG 2.2 AA criteria (The admin4 design).
• To do: Staff know the Keyboard shortcuts and the light, dark and system modes.
• To do: You know the gaps: the classic administration, the online editor (TinyMCE) and some extensions are not covered by the same tests (Accessibility standards).
• To do: Interface language set per user where needed (UI switch settings).

The public design #

• To do: The design was built or reviewed for WCAG 2.2 AA; the project's public designs are not audited and are the site builder's responsibility.
• To do: Skip link, landmarks, one h1 per page, visible focus, lang on <html> (Accessibility for site builders).
• To do: Color contrast of text 4.5:1 and of controls 3:1; no information by color alone.
• To do: Layout reflows at 320 CSS pixels and at 200% zoom.
• To do: Forms have labels, error messages and instructions (Building a contact form).
• To do: Right-to-left languages set the direction (Right-to-left sites).
• To do: CAPTCHA, if any, has an accessible alternative (Spam protection for forms).

Content #

• To do: Editors are trained in accessible content (Editors 201, Module 8).
• To do: Every informative image has alternative text; nothing in the software forces editors to fill it (Accessibility standards).
• To do: Headings are in order; tables have header rows; link texts describe the target.
• To do: Documents (PDF, office files) are accessible or have an accessible alternative.
• To do: Videos have captions; audio has transcripts.
• To do: Plain language (Plain language checklist).

Testing #

• To do: Test with the keyboard alone and with a screen reader on key journeys (Testing accessibility).
• To do: Run an automated checker on the main templates; it finds only part of the problems.
• To do: Follow a method such as WCAG-EM for a formal evaluation.
• To do: Retest after design changes and after upgrades.
• To do: If an auditor's report is required, commission one for your site; the project publishes none.

Statement and feedback #

• To do: Accessibility statement published: conformance status, known problems, feedback contact, date (W3C guidance).
• To do: A feedback route that works without the inaccessible content (e-mail, phone).
• To do: Feedback is answered within your own deadline and fixes are tracked.
• To do: The statement is reviewed at least once a year (Annual review).

Related pages #

• Government checklists
• Accessibility standards
• The accessibility section of this government help (written by another author)
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.