Web Accessibility (a11y)

Design and development practice ensuring digital products are usable by people with visual, motor, hearing, and cognitive disabilities.

"Making the form accessible meant adding labels to every input, announcing errors to screen readers, and ensuring the entire flow was keyboard-navigable."

Web Content Accessibility Guidelines; the international standard published by the W3C. Versions 2.1 and 2.2 define criteria at levels A, AA, and AAA.

"Our product targets WCAG 2.1 AA compliance — it is the level required by UK and EU accessibility regulations for public-sector and commercial services."

The four WCAG top-level principles: Perceivable, Operable, Understandable, and Robust. Every guideline maps to one principle.

"We evaluate every new feature against POUR: can users perceive it, operate it, understand it, and will it work with current and future assistive technologies?"

HTML attribute that defines the semantic purpose of an element to assistive technology: role="button", role="dialog", role="alert".

"Adding role="dialog" to the modal and role="button" to the custom div element made the experience identical for screen reader users to native elements."

Attribute describing a characteristic of an ARIA element: aria-label provides a text label, aria-describedby links to a description, aria-required marks required fields.

"aria-label="Close dialog" on the × button gives screen reader users a meaningful description instead of hearing just "button"."

Attribute reflecting the current dynamic condition of an interactive element: aria-expanded, aria-checked, aria-disabled, aria-selected.

"The accordion toggle sets aria-expanded="true" when open and aria-expanded="false" when closed — screen readers announce the state change on activation."

Using HTML elements for their intended meaning: <button> for actions, <nav> for navigation, <main> for primary content; often eliminates the need for ARIA.

"Replacing <div onclick> with a real <button> gave us keyboard focus, Enter/Space activation, and screen reader announcement for free."

Programmatically controlling which element has keyboard focus, especially when opening modals, rendering dynamic content, or navigating single-page applications.

"When the dialog opens we move focus to the first interactive element inside it; when it closes we return focus to the button that triggered it."

Ensuring all functionality is accessible without a mouse: focusable elements, logical tab order, and keyboard-operable controls.

"Our audit found the custom date picker was mouse-only — we added keyboard navigation so users can navigate months with arrow keys and select with Enter."

Assistive technology that reads page content, structure, and interactive element states aloud; major products are NVDA, JAWS (Windows), and VoiceOver (macOS/iOS).

"We test with both VoiceOver on macOS and NVDA on Windows — they interpret ARIA differently and both have significant user bases."

The ratio of relative luminance between foreground text and its background. WCAG 2.1 AA requires 4.5:1 for normal text and 3:1 for large text.

"Our light grey placeholder text on a white background had a contrast ratio of 2.1:1 — far below the 4.5:1 AA requirement — so we darkened it."

The text label announced by screen readers for an interactive element; computed from aria-label, aria-labelledby, the element's content, or the alt attribute.

"The icon button had no accessible name — screen readers announced just "button". Adding aria-label="Submit form" gave it a meaningful name."

Visually hidden anchor link at the top of a page that lets keyboard users jump directly to the main content, bypassing repeated navigation.

"The skip link is the first focusable element on every page — keyboard users press Tab once then Enter to jump past the nav and reach the main content."

Element with aria-live that causes screen readers to automatically announce dynamic content updates without requiring the user to move focus there.

"The form validation summary uses aria-live="assertive" so screen readers immediately announce error messages when they appear after submission."

Open-source accessibility testing engine by Deque; available as a browser extension, Playwright/Cypress plugin, and CI tool. Detects WCAG violations automatically.

"Integrating axe-core into our Playwright test suite catches 57% of WCAG issues automatically on every pull request — before human review even begins."