Accessibility Checklist for Business Software

Before working through a checklist, decide which screens and journeys are in scope, which assistive technologies you are designing for, and which standard the software will be measured against. Start with screen readers, keyboard-only use, low vision and motor impairment, then add any group your customers or staff include, for example older users or one-handed phone use.

Level AA is the usual target. WCAG 2.2 became a formal W3C Recommendation on 5 October 2023 and was updated in December 2024 (W3C, checked 8 September 2026). Record the chosen level.

Disability rules reach digital services in many countries, so ask a legal adviser to confirm the obligations, especially when the software serves the public or a regulated sector.

Start with the keyboard. Every button, link, form field and menu should be reachable and usable with the keyboard alone, in an order that follows the visual and logical layout of the screen. A clearly visible focus outline must show where keyboard attention currently sits, because a user who cannot see the focus cannot tell what pressing Enter will do.

Labels matter as much as structure. Form fields need labels a screen reader can announce, not placeholder text that vanishes once typing starts, and images that carry meaning need alternative text. Icon-only buttons need a hidden text description. A save icon with no accessible name is invisible to a screen-reader user, even though its meaning looks obvious to everyone else.

Consider a hypothetical bakery taking online orders for corporate cakes, where a sighted customer clicks straight through the flavour, size and delivery-date fields in seconds. A screen-reader customer hears the size selector announced only as “button, button, button” because nobody gave the options accessible names in the markup. The fix takes minutes once found. Only a screen-reader test reveals it.

Check text contrast first. Text needs enough contrast against its background for someone with low vision to read it, and the layout must survive larger text without overlap. Test at higher zoom too. On touch devices, buttons need enough size and spacing for someone with limited fine motor control to tap the right one reliably.

Error handling deserves particular attention. An error must be announced in a way assistive technology picks up, described in plain language rather than a vague code, and tied to the specific field it concerns. Red borders alone fail. Sighted users infer the meaning from colour alone, but the signal is lost for anyone who cannot see that colour, including users with colour blindness.

Automated scanners are a cheap first pass. They reliably catch missing labels, poor contrast ratios and some structural issues, but they catch only part of what makes software usable with assistive technology. No scanner can judge whether the spoken sequence of a screen reader makes sense to a person trying to finish a task.

Some checks need a person. Test with a screen reader, work through a real task using only the keyboard, and switch on the operating system’s built-in accessibility settings. These steps catch what scanners miss. A logically structured page can become a confusing jumble when read aloud in the wrong order, and only a listening human notices.

Accessibility is not a one-time fix. Every new screen added after the review can reintroduce the problems you just resolved, so log each finding with a severity, the person responsible and a target date. Track it like any other defect.

Decide who checks new features. That could be a formal QA step, a shared checklist that designers and developers both use, or a periodic re-audit scheduled each quarter. Without an assigned owner, accessibility tends to regress quietly every time a release changes the software, even after a thorough and well-funded first fix.