Accessibility in applications, not just websites
Why the same accessibility standard applies to the software your staff and customers log into, and where applications fail most.
The short answer
Accessibility is discussed as a website topic, and the applications people log into, internal tools, customer portals, dashboards, booking systems, are left out. The standard does not leave them out. The same requirements apply: keyboard operability, screen reader support, contrast, labelled forms, announced errors and changes, no information conveyed by colour alone. Applications fail in specific places, mostly in custom controls built for the mouse and retrofitted for nothing else. A component library built to the standard makes every screen accessible by default and is far cheaper than fixing screens one at a time. And accessible applications are faster for everyone, because what keyboard users and screen reader users need is what power users want.
Where applications fail
| Failure | What it looks like | Fix |
|---|---|---|
| Custom controls not operable by keyboard | A dropdown, date picker or toggle that only works with a mouse | Native elements where possible; otherwise full keyboard handling and roles in the component |
| Focus lost or trapped | A modal opens and focus stays behind it, or closes and focus vanishes | Move focus in, trap while open, return on close, in the modal component |
| Data tables without structure | Rows of divs that look like a table | Real tables with headers, captions and sortable columns announced |
| Live updates not announced | Status changes, new rows, errors appear silently | Live regions for changes that matter; announced errors on forms |
| Colour as the only signal | Red for error, green for success, nothing else | Icons, text and colour together |
| Unlabelled icon buttons | A row of icons with no names | Accessible names on every control |
| Keyboard traps and no shortcuts | Tab through forty cells to reach a button | Logical order, skip links, shortcuts for frequent actions |
| Timeouts and motion | Sessions that expire mid-task; animations that cannot be paused | Warnings and extensions; reduced-motion respect |
Building it in
- Start from a component library built to the standard: every button, input, select, table, modal, tab and menu keyboard operable, labelled and tested with a screen reader before any screen uses it.
- Design states, not just screens: loading, empty, error, success, each announced.
- Automate the checks in the pipeline on every change: contrast, labels, roles, focus order.
- Test with the keyboard only as part of every review, and with a screen reader for every new component.
- Add shortcuts for the actions people do all day.
- Audit once properly, then keep it with the pipeline and the component library.
Why it is faster for everyone
Keyboard operability means an operator processing a hundred records a day never reaches for the mouse. Logical focus order means the next field is always where the cursor lands. Clear labels and visible state mean less guessing. Shortcuts mean frequent actions take a keystroke. These are the properties experienced users demand of tools they live in, and they are exactly what the standard requires. An accessible application is a well-designed one measured against a checklist.
What this means for you
Hold your applications to the same standard as your website: keyboard operable, screen reader usable, high contrast, labelled, announced, colour never alone. Build accessibility into the component library so every screen inherits it, automate the checks, and test with the keyboard on every review. It serves staff and customers who need it, meets obligations that increasingly cover applications, and makes the software faster for the people who use it all day.
Frequently asked questions
Does accessibility law apply to internal software?
Employers have obligations towards staff with disabilities, public bodies have explicit requirements, and increasingly regulations cover digital services broadly. Beyond the law, internal tools are used all day by people whose ability to work depends on them. Build to the standard regardless of which rule applies; the specific obligations for your sector are a question for an advisor, and the engineering answer is the same.
Where do applications fail most?
In the custom controls: dropdowns, date pickers, drag and drop, rich tables and modals built for the mouse. Each needs keyboard operation, focus management and announcements to work for everyone, and each is usually missing them. A component library that gets these right once, used everywhere, is the difference between an accessible application and an audit with two hundred findings.
Do accessible applications look worse or work slower?
No. Keyboard shortcuts, logical focus order, clear labels and visible state are what experienced users of any application want. Accessibility done well is indistinguishable from good interface design, and power users are often its most vocal beneficiaries.
Sources
- W3C: How to Meet WCAG (Quick Reference) (accessed 2026-09-12)