5.3 Accessibility¶

Overview and motivation¶

Accessibility (often shortened to "a11y") is the practice of building software that people with disabilities can perceive, understand, navigate, and use. That includes people who are blind or have low vision, who are deaf or hard of hearing, who have motor impairments, who have cognitive or learning differences, and who face temporary or situational limits such as a broken arm, bright sunlight, or a noisy room. Roughly one in five people has a disability, and everyone benefits from accessible design at some point. This is not a niche accommodation. It is a baseline of quality.

For large teams, accessibility has to be built into the system, not left to individual good intentions. When many teams ship into one product, a single inaccessible component (an unlabeled form field, a color-only status indicator, a keyboard trap in a modal) can lock disabled users out of an entire journey. Building accessibility into shared components, design tokens, testing pipelines, and definitions of done is the only way to make it reliable at scale. Retrofitting it after the fact is expensive and error-prone. Designing it in is cheap and durable.

For government, accessibility is a legal requirement and a civic obligation, not a nice-to-have. Public services must serve every member of the public, and disabled citizens often have no alternative provider: if the government website is inaccessible, they cannot get their benefit, license, or vote another way. Laws and standards around the world make accessibility mandatory for public bodies, and increasingly for the private sector too. This chapter treats accessibility as three things at once: a legal duty, an ethical duty, and simply good design.

See also: chapter 5.2 (UI design and design systems), chapter 5.6 (frontend engineering), and chapter 5.1 (UX foundations).

Key principles¶

• Accessibility is a baseline quality attribute, like security and performance, not an optional feature.
• The POUR principles: interfaces must be Perceivable, Operable, Understandable, and Robust.
• Semantic HTML first; use ARIA only to fill genuine gaps, never as a substitute for native elements.
• Everything usable with a mouse must be usable with a keyboard alone.
• Do not convey information by color, shape, or position alone.
• Automated tools catch only a fraction of issues; manual and assistive-technology testing are essential.
• Accessible design is better design for everyone (the "curb-cut effect," where features built for disabled people benefit all users).
• Design and test with disabled people, not just for them.

Recommendations¶

Design and build to WCAG, targeting the current standard¶

The Web Content Accessibility Guidelines (WCAG) are the international reference. WCAG 2.1 and 2.2 are organized under the four POUR principles, with testable success criteria at conformance levels A, AA, and AAA. Target Level AA as your baseline; it is what most laws reference. WCAG 2.2 adds criteria for focus visibility, target size, and reducing cognitive load. WCAG 3.0 is an emerging successor, structured differently and still in development. Keep an eye on it, but build to 2.2 AA today. Treat the guidelines as a floor, not a ceiling: passing every criterion does not guarantee a genuinely usable experience.

Use semantic HTML and correct ARIA¶

Native HTML elements (buttons, links, form controls, headings, lists, landmarks) come with built-in accessibility semantics, keyboard behavior, and assistive-technology support. Use them first. Reach for ARIA (Accessible Rich Internet Applications) roles, states, and properties only to describe custom widgets that HTML cannot express, and follow the ARIA Authoring Practices. The first rule of ARIA is simple: don't use ARIA if a native element will do. Incorrect ARIA is worse than none: it actively misleads screen readers. Give the page a logical heading structure, meaningful labels, alternative text for images, captions and transcripts for media, and a programmatic link between each label and its control.

Guarantee keyboard and assistive-technology operability¶

Every interactive element must be reachable and operable with the keyboard alone, in a logical order, with a clearly visible focus indicator. Avoid keyboard traps. Manage focus deliberately when content changes: move focus to a dialog when it opens, return it when the dialog closes, and announce dynamic updates through live regions. Test with real assistive technologies, including screen readers on desktop and mobile, screen magnification, voice control, and switch access. And respect user preferences such as reduced motion and increased contrast.

Test with automated tools, manual review, and real users¶

Automated accessibility scanners are valuable, and they should run in the pipeline on every change. But studies consistently show they catch only a minority of real issues, roughly a third. The rest need human judgment: keyboard walkthroughs, screen-reader testing, contrast checks, and asking whether the content is actually understandable. Most important of all, include people with disabilities in usability testing. Build accessibility acceptance criteria into the definition of done, so issues get caught per story rather than in a pre-launch audit.

Make accessibility organizational, not heroic¶

Bake accessibility into the design system so components ship accessible by default. Offer training so designers, engineers, content authors, and product managers each know what they are responsible for. Establish an accessibility standard, an owner or center of excellence, and a remediation process. Publish an accessibility statement and give users a way to report barriers. And procure accessibly: require vendors and third-party components to conform, and to provide evidence (such as an accessibility conformance report).

Trade-offs: pros and cons¶

The central trade-off is upfront discipline versus deferred cost. Accessibility built in is inexpensive and improves quality for everyone; accessibility retrofitted under legal pressure is expensive, incomplete, and stressful. In the long run there is no real trade-off against "speed": inaccessible software simply does not work for a fifth of your users. That is a defect, not a saving.

Examples¶

Startup. A three-person startup building a hiring tool added an accessibility scanner to their build and a quick keyboard walkthrough to their pull-request checklist from the very first sprint, reasoning it was cheaper to stay accessible than to fix it later. When a mid-size customer's procurement team asked for an accessibility conformance report during a sales cycle, the startup already used semantic HTML, labeled every field, and had visible focus everywhere, so they answered in days instead of scrambling. That readiness won a deal that a competitor lost on the same requirement.

Enterprise. A large retailer faced a class-action lawsuit because blind customers could not complete checkout with a screen reader. Beyond the settlement and legal fees, the company had to remediate under a court-supervised timeline. Afterward it rebuilt accessibility into its design system and CI pipeline, added screen-reader testing to the definition of done, and trained its teams. The rebuilt, accessible checkout also improved conversion and reduced support contacts for everyone: the fixes that helped screen-reader users (clear labels, error messages, logical order) helped all users.

Government. A public benefits agency was legally required to meet WCAG 2.1 AA for its online application. Early testing with blind and low-vision users, keyboard-only users, and users with cognitive disabilities revealed that a color-only "required field" indicator, an inaccessible date picker, and unannounced validation errors were blocking people from finishing. Fixing these, through semantic markup, visible focus, live-region error announcements, and plain-language help, let disabled citizens apply on their own for the first time. That reduced reliance on in-person help and lowered cost to serve, while meeting the legal mandate.

Business case: motivations, ROI, and TCO¶

The business case rests on market reach, legal risk, cost to serve, and quality. Disabled people and their families control significant spending power; excluding them forfeits it. Accessible services reduce the need for expensive assisted channels (phone and in-person help), which is a direct operational saving, especially for government. And because accessibility improvements (clear labels, keyboard support, readable content, robust markup) help everyone, they typically raise overall completion and satisfaction.

On TCO, the adoption cost is training, tooling, and building accessibility into components and pipelines, all modest when you do it from the start. The cost of not adopting is severe and comes from several directions: legal liability (lawsuits, settlements, court-ordered remediation, regulatory penalties), the far higher expense of retrofitting under deadline pressure, reputational damage, and the ongoing cost of serving excluded users through more expensive channels. Retrofitting typically costs several times what designing-in would have.

To make the case to leadership, lead with the legal obligation where it applies (it is non-negotiable for government and increasingly for the private sector). Then quantify the addressable population you are excluding, the assisted-channel cost of that exclusion, and the "curb-cut" gains for all users. Position accessibility as risk management plus quality, not charity.

Anti-patterns and pitfalls¶

• Accessibility as a pre-launch checkbox: an audit at the end instead of continuous practice, guaranteeing expensive last-minute rework.
• "Div soup": non-semantic markup with click handlers on generic elements, invisible to assistive technology.
• ARIA misuse: bolting ARIA onto broken markup, which misleads screen readers more than plain markup would.
• Color-only information: status shown by color alone, invisible to color-blind users.
• Invisible focus: removing focus outlines for aesthetics, stranding keyboard users.
• Keyboard traps: modals and widgets that trap or lose focus.
• Automated-scan complacency: passing a scanner and assuming the product is accessible.
• Accessibility overlays: third-party "one-line fix" widgets that do not deliver real conformance and can worsen the experience.
• Excluding disabled users from research: designing for an imagined disabled user instead of testing with real ones.

Maturity model¶

Level 1: Initial. No accessibility practice. Issues discovered only when a user complains or a lawsuit arrives. Markup is non-semantic and untested.

Level 2: Repeatable. Awareness exists; some automated scanning and a pre-launch audit. Accessibility is a late-stage checklist, frequently deprioritized under schedule pressure.

Level 3: Defined. WCAG 2.2 AA is the standard. Accessibility is built into the design system, tested automatically and manually, and part of the definition of done. Teams are trained; an owner and remediation process exist.

Level 4: Optimizing. Accessibility is continuous and measured. Disabled people are involved in research and testing. Accessibility is embedded in procurement, design tokens, and CI. The organization tracks conformance over time and treats regressions as build failures, and it influences vendors and partners.

Ideas for discussion¶

• How do you keep accessibility from being deprioritized when deadlines tighten?
• What is the right mix of automated, manual, and user testing for your risk profile?
• How should accessibility conformance be written into vendor contracts and procurement?
• How do you handle the gap between WCAG conformance and genuine usability for disabled people?
• How should teams prepare for WCAG 3.0 while building to 2.2 today?
• How do you fairly and respectfully recruit and compensate disabled participants for research?

Key takeaways¶

• Accessibility is a baseline quality attribute and, for government, a legal requirement.
• Design to WCAG 2.2 AA as a floor; use the POUR principles as a mental model.
• Semantic HTML first; ARIA only to fill real gaps, done correctly.
• Automated tools catch about a third of issues; manual and assistive-technology testing are essential.
• Test with disabled people, not just for them.
• Building accessibility in is cheap and durable; retrofitting is expensive and fragile.
• Accessible design is better design for everyone: the curb-cut effect is real.

References and further reading¶

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2 and supporting Understanding/Techniques documents
• W3C, WAI-ARIA Authoring Practices Guide
• W3C Web Accessibility Initiative (WAI), introductory and tutorial materials
• Laura Kalbag, Accessibility for Everyone
• Sarah Horton and Whitney Quesenbery, A Web for Everyone
• Regine Gilbert, Inclusive Design for a Digital World
• U.S. Section 508 standards and Section508.gov guidance
• European standard EN 301 549 and the European Accessibility Act
• Government accessibility guidance (e.g., UK GDS accessibility manual)
• WebAIM, research and articles including the annual accessibility analyses