Software Accessibility Checklist (WCAG 2.2)

What is a software accessibility checklist?

A software accessibility checklist is a list of concrete yes-or-no checks a team runs on a website or app to find barriers for people with disabilities. Good checklists are built on WCAG success criteria, grouped by what a user needs (perceivable, operable, understandable, robust), and run during design, development and release. A checklist finds common problems early. It does not prove conformance by itself.

What to check

• Keyboard. Can every control be reached and used with the keyboard alone, in a logical navigation order, without getting trapped?
• Visible focus. Is the focused element clearly visible (WCAG 2.4.7, Level AA)?
• Text alternatives. Do meaningful images have a description and decorative ones none? See accessible images.
• Contrast. Does text meet 4.5:1, or 3:1 for large text (at least 18 point or 14 point bold; WCAG 1.4.3, Level AA)? See accessible color palettes.
• Target size. Are pointer targets at least 24 by 24 CSS pixels, or spaced so they pass the exceptions (WCAG 2.5.8, new in 2.2, Level AA)?
• Forms. Does each field have a label, and are errors described in text and announced to assistive technology?
• Structure and names. Are headings, landmarks and control names meaningful, and is ARIA used only where native HTML cannot do the job?
• Media. Do video and audio have captions or transcripts? See accessible media types.
• Layout and zoom. Does the interface still work when resized or on a small screen? See accessible layout.

How to use it

• Pick the standard and level first, usually WCAG 2.2 AA.
• Review designs against it before build, and run it per feature in code review.
• Run automated scans for the code-detectable items, then check the rest by hand with a screen reader and keyboard. See manual tests and automated testing.
• Log each failure with the page, criterion and fix, then retest.

Example items

A concrete checklist item reads like a test: "On the checkout page, press Tab from the top. Every field and button receives a visible focus ring in the order it appears on screen, and Enter submits the form." Pass or fail, with the page named.

Common mistakes

• Treating a ticked checklist or a clean Lighthouse run as proof of WCAG conformance. Automated tools check only part of it.
• Running it once before launch instead of per release.
• Skipping assistive technology such as screen readers and switch devices.
• Adding ARIA to fix what proper HTML would solve.

Where LoadFocus fits

LoadFocus does not run a full accessibility audit or issue conformance reports. Page speed monitoring runs scheduled Lighthouse audits that include an Accessibility score, which can flag regressions on the code-detectable items between manual reviews. For the wider picture, see performance testing and accessibility.

FAQ

Is a checklist enough to claim WCAG conformance?

No. A checklist finds common problems, but conformance is judged per success criterion across a representative sample, and part of that needs manual evaluation. A checklist is a good working tool, not a certificate.

Which WCAG level should the checklist target?

Level AA of WCAG 2.2 is the usual target. Check whether your buyer, law or contract names a specific standard or version.

What are the quickest wins on a software accessibility checklist?

Full keyboard use with a visible focus, labels on every form field, alt text on meaningful images and enough text contrast fix a large share of common failures.

Can I automate the whole checklist?

No. Scanners such as Lighthouse and axe catch code-detectable issues, but items like logical tab order, sensible alt text and screen reader behaviour need a person.