Accessibility and UX: How A11y improves the user experience for everyone

Accessibility improves the UX not only for people with disabilities. Visible focus states help everyone who switches between mouse and keyboard. Meaningful link texts help everyone who skims pages. Generous touch targets help people with limited motor skills as well as anyone ordering with one hand on a jerky platform. Fast performance helps assistive software as well as older hardware and poor mobile communications. This added value for the majority is the reason why accessible engineering pays off economically and not just ethically.

The Web Content Accessibility Guidelines of the W3C are based on four principles: Perceivable, Usable, Understandable, Robust (WCAG 2.2, W3C). In UX language this sounds like a usability requirement, in engineering language it sounds like clean code. Both are the same thing.

Perceptible requires that no information is conveyed exclusively via a single sensory channel: Image information needs alternative texts, audio and video content needs transcripts or subtitles, color cues need additional textual markings. Operable requires every function to be accessible via keyboard, voice or switch. Understandable requires predictable behavior and clearly formulated error messages via aria-live regions. Robust addresses clean technical coding so that assistive technologies can interpret reliably.

If you conduct design reviews according to these four principles, you can build UX standards and accessibility requirements in one step. The separation between “UX bug” and “A11y bug” disappears almost completely in practice.

• Semantic HTML before ARIA. Native HTML elements automatically include focusability, keyboard behavior and screen reader support. A button element is not a div element with a click handler. The first rule of WAI-ARIA is: No ARIA is better than bad ARIA.
• Use ARIA patterns correctly. Where native elements are not sufficient, such as for tabs, combo boxes or tree views, the ARIA Authoring Practices help as a reference implementation (WAI-ARIA Authoring Practices). They specify the tested interaction of roles, states, properties and keyboard behavior for complex widgets.
• Focus management in single page applications. In SPAs, the browser does not automatically take care of the focus. Route changes without shifting the focus are a common occurrence in many React, Angular and Vue applications. Correct implementation means: After a route change, the focus moves programmatically to the h1 element or the main element, and the route change is announced via aria-live.
• Form states for screen readers. Validation errors that only flash red are invisible to screen readers. The combination of visible text, programmatically linked label, aria-invalid and an aria-live region is correct. The abandonment rate in forms decreases measurably, not only for people with disabilities.
• Movement as a choice, not as a default. Excessive animations and parallax effects can cause discomfort for people with vestibular disorders. The media query prefers-reduced-motion: reduce is a standard browser function. A design system that does not respect it fails WCAG 2.3.3 and an elementary UX expectation.
• Language and lang attribute. Screen readers select pronunciation and voice based on the lang attribute. An incorrectly set language attribute leads to machine-distorted reading. Internationalized applications should also mark inline language changes via lang at element level.
• Performance as an accessibility factor. A fast site is an accessible site. Older devices, assistive software in the background and slow networks are the reality for many user groups. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are therefore also A11y levers, not just performance issues.

Most WCAG violations are not isolated cases, but structural defects in reused components. The current WebAIM Million Report 2025 clearly shows this: 94.8 percent of the one million most-visited home pages worldwide have at least one automatically recognizable WCAG violation, an average of 51 errors per page (WebAIM Million Report 2025). If you build buttons, inputs, dropdowns, modals and datatables cleanly once, you multiply accessibility across the entire product.
An accessible component library guarantees keyboard operability by default, visible focus states, programmatically correct labels and descriptions, ARIA roles and states according to APG, contrast-safe tokens, focus trap in dialogs, live region patterns for asynchronous status changes. Such libraries can be built in-house or based on tried and tested headless patterns such as React Aria, Radix UI or Adobe Spectrum. The decisive factor is not the choice of library, but the consistency with which the components are set as binding for the product.

Without automated testing, regression errors creep in that are not noticed in any release audit. Three building blocks have proven their worth. Firstly, embedded checks with the open source engine axe-core from Deque in unit and integration tests; violations break the build. Secondly, Lighthouse or Pa11y in the pipeline with configured minimum scores on the most important page types. Third, visual regression tests with focus-state snapshots to detect suppressed focus styles before production.
Automated tests capture part of the WCAG requirements, especially structural code issues. Content-related issues such as the quality of an alternative text or the meaningfulness of a tab order remain the task of manual tests. Both together are the standard of modern engineering teams.

Custom components without keyboard behavior, often built as a showcase of modern framework features, are a classic. Aggressive lazy loading strategies can make screen reader use more difficult if content is only reloaded when it is visible. JavaScript magic to “improve” native browser features often produces the most findings in audits. Rule of thumb: If a native solution exists, it is usually the more accessible one.

At BAYOOTEC, we have been developing digital products for SMEs, international corporations and public authorities for over 20 years, often in regulated industries such as medical technology, energy or financial services. In this environment, accessibility is not an optional feature, but part of the same quality logic as security, data protection and maintainability. In the engineering strand, this means that accessibility is part of the Definition of Done, component libraries are set up with accessibility-tested patterns, automated A11y checks run in the CI/CD pipeline alongside linting and tests. Where relevant to the project, our colleagues from our sister company UID supplement the UX strategy and user research side.

Good UX is the result of the interplay between concept, content, design and engineering. However, the question of whether accessibility becomes a tangible feature of a product or a late correction task is decided in the code: In the markup, in the components, in the routing, in the performance, in the pipeline. What a user actually experiences in everyday life is determined at every point in this chain. Those who anchor A11y in the engineering standard build products for a wide variety of uses, not just for the “average” use case.