Accessibility Checklist for Business Software

Before running through a checklist, decide what "accessible" means for this specific piece of software: which screens and journeys are in scope, which disabilities and assistive technologies are being designed for (screen readers, keyboard-only use, low vision, motor impairment), and which standard the software is being measured against. Internationally, the current benchmark is WCAG (Web Content Accessibility Guidelines) 2.2, published as a formal W3C Recommendation on 5 October 2023 and updated in December 2024, with Level AA the target most businesses aim for as a reasonable, achievable bar (W3C, checked 8 September 2026).

In India, the Rights of Persons with Disabilities Act, 2016, which came into force in April 2017, places a legal obligation on establishments to make information and communication technology accessible, and government-facing platforms are additionally expected to follow the Guidelines for Indian Government Websites (GIGW), which specify WCAG 2.1 Level AA compliance (Department of Empowerment of Persons with Disabilities, Government of India, checked 8 September 2026). Private business software isn't bound by GIGW directly, but it's a useful reference point for what "accessible enough" looks like in an Indian context, and worth discussing with your own legal advisor if the software serves the public or a regulated sector.

A large share of accessibility problems in business software come down to whether the interface can be operated without a mouse at all. Every interactive element — buttons, links, form fields, menus — should be reachable and usable with the keyboard alone, in an order that follows the visual and logical layout of the screen, with a clearly visible focus indicator showing where keyboard attention currently is.

Labels matter just as much as structure: form fields need labels a screen reader can announce (not just placeholder text that disappears once typing starts), images that convey meaning need alternative text, and icon-only buttons need a text description even if it's visually hidden. A save icon with no accessible label is invisible to anyone using a screen reader, however obvious its meaning looks to a sighted user.

Imagine a hypothetical bakery running an online ordering site for corporate cake orders. A sighted customer clicks straight through the flavour, size and delivery-date fields; a customer using a screen reader, testing the same order, finds the size selector reads out only as "button, button, button" because the options were never given accessible names — a fix that takes minutes once found, but is invisible to anyone not testing with a screen reader in the first place.

Text needs sufficient contrast against its background to be readable by someone with low vision, and the interface should remain usable when a browser or device's zoom or text-size setting is increased — content shouldn't overlap, get cut off, or become unusable at larger sizes. On touch devices, interactive elements need to be large enough, and spaced enough apart, that someone with limited fine motor control can tap the right one reliably.

Error handling deserves particular attention: an error needs to be announced in a way assistive technology picks up, described in plain language rather than a vague code, and tied clearly to the specific field it relates to. A form that shows a red border with no accompanying text is a common failure — sighted users infer the meaning from colour alone, but that signal is lost entirely for anyone who can't see it.

Automated scanning tools are a fast, cheap first pass — they reliably catch missing labels, poor contrast ratios and some structural issues — but they only catch a portion of what makes software genuinely usable with assistive technology, generally estimated by accessibility practitioners at well under half of all issues, since most tools can't judge whether a screen reader's spoken-out-loud experience actually makes sense as a sequence.

Testing with an actual screen reader (or with someone experienced in using one), navigating a real task using only the keyboard, and checking behaviour with the operating system's built-in accessibility settings turned on, catches problems automated tools miss entirely — like a logical page structure that becomes a confusing jumble when read aloud in the wrong order.

Accessibility isn't a one-time fix, because every new screen or feature added after the review can reintroduce the same problems that were just resolved. Each finding from a review should be logged with a severity rating, a named owner, and a target date, the same way any other defect would be tracked, rather than living only in a report that gets filed away.

It's worth agreeing, as part of the same process, who checks new features for accessibility before they ship — whether that's a formal step in QA, a shared checklist designers and developers both use, or a periodic re-audit. Without an assigned owner, accessibility tends to regress quietly every time the software changes, even after a genuinely thorough initial fix.