4 min read
Accessible enterprise web applications: what WCAG 2.2 AA asks of engineers
Automated tooling finds roughly a third of WCAG issues. The rest are structural: custom controls without keyboard support, focus that vanishes after an interaction, errors announced only visually, and content that reflows into unusability at 400% zoom. These are engineering decisions, and they are cheapest to get right at build time.
- Accessibility
- Frontend
- Delivery
Written by the Codentures engineering team.
Accessibility work usually arrives as a remediation project after a procurement questionnaire or a complaint. By then the cost is high, because the failures are rarely in the styling layer where they would be cheap. They are in the component architecture, and fixing them means rebuilding controls that already work for most users.
The pattern is consistent enough to be worth naming: the accessibility failures that matter in enterprise applications are engineering decisions made months earlier, by engineers who were not thinking about accessibility because nobody had asked them to.
What automated testing will and will not find
Automated tools, such as axe and its equivalents, are genuinely useful and belong in CI. They will find missing alternative text, contrast failures, form controls without programmatic labels, invalid ARIA and duplicate landmark roles. That is a real portion of the problem, and catching it automatically is free after the first day of setup.
They will not find that your custom dropdown cannot be operated with a keyboard, that focus is lost when a dialog closes, that an error message is visually adjacent to a field but not programmatically associated with it, or that a form can only be completed by someone who can perceive colour. Those require a person and a keyboard, and they are the ones that actually prevent people from completing tasks.
Where the expensive failures originate
Custom controls rebuilt from divs
A native select, button or checkbox arrives with keyboard behaviour, focus management, state announcement and platform conventions already correct. A div with a click handler arrives with none of it, and reproducing all of it is more work than most teams estimate. The rule that saves the most remediation cost is simply: use the native element unless there is a requirement it genuinely cannot meet, and treat 'the designer wanted a different arrow' as not being such a requirement.
Focus that goes nowhere
Focus management is invisible to sighted mouse users and definitive for everyone else. When a dialog opens, focus moves into it; when it closes, focus returns to the control that opened it. When content is added asynchronously, focus stays where the user put it. When a route changes in a single-page application, something has to move focus and announce the new context, because the browser no longer does it for you. Each of these is a few lines, and each is missing from most enterprise applications.
Errors that are only visible
A form error rendered in red text below the input is invisible to a screen reader user until they navigate to it, and invisible to anyone who does not perceive the colour difference. The fix is unglamorous: associate the message with the input via aria-describedby, mark the field aria-invalid, and put the error text in the message rather than relying on the colour to carry the meaning. If a summary of errors is rendered, move focus to it.
Layouts that break under zoom
WCAG 2.2 requires content to reflow to a 320 CSS pixel width without two-dimensional scrolling, which is equivalent to 400% zoom on a standard desktop viewport. Enterprise applications built around wide fixed tables and multi-column dashboards routinely fail this, and it is expensive to fix afterwards because the layout assumptions run through the whole component tree. Building mobile-first is not a mobile decision; it is the cheapest route to passing reflow.
Motion, and the preference nobody tests
Animation that improves hierarchy for most users can cause genuine physical discomfort for people with vestibular disorders. The operating system already exposes the preference; respecting it takes a media query and, in a JavaScript animation library, a hook. What matters is what you replace the animation with: not a jump that loses the user's place, but an immediate or simply-faded final state. Test it by turning the preference on in your own operating system and using the application, which almost nobody does.
What this looks like as an engineering practice
- Semantic HTML as the default and ARIA as the exception. The first rule of ARIA is not to use it when a native element will do.
- Automated accessibility assertions in CI, so regressions fail a build rather than a procurement review.
- A keyboard-only pass on every significant interface change: tab through it, operate everything, and confirm focus is always visible and never trapped.
- One meaningful h1 per page and a heading structure that reads as an outline, because that is how screen reader users navigate a page.
- Contrast checked at design time against the actual token values rather than assumed from a palette that looked fine.
- Touch targets sized at 44 by 44 CSS pixels or larger, which also measurably reduces mis-taps for everyone.
None of this is expensive when it is the default. All of it is expensive as a retrofit. That asymmetry is the entire argument for treating accessibility as an architectural concern rather than a testing phase.
We build to WCAG 2.2 Level AA and test both automatically and by keyboard. We do not certify conformance, and no responsible engineer claims a site is fully conformant without testing it.