English for Accessibility Engineers: WCAG, ARIA, and a11y Vocabulary
Learn essential accessibility vocabulary — WCAG levels, POUR principles, ARIA roles and states, focus management, screen readers, colour contrast, and a11y audit language.
Accessibility is no longer optional. Legal requirements, inclusive design principles, and growing awareness mean that every engineering team needs at least one person who speaks the language of a11y fluently. This guide covers the vocabulary you will use in accessibility audits, code reviews, and team discussions — from WCAG levels to ARIA attributes to screen reader testing.
Accessibility vs Usability
Accessibility (a11y)
Accessibility (often abbreviated a11y — the “11” represents the eleven letters between “a” and “y”) is the practise of making digital products usable by people with disabilities. This includes visual, auditory, motor, and cognitive impairments.
“The component passes usability testing, but it fails accessibility — a screen reader user can’t navigate the custom dropdown at all.”
The abbreviation a11y is used in writing and code, but say “accessibility” in conversation.
Usability vs Accessibility
Usability is about making something easy for the average user. Accessibility is about making it work for users with disabilities. A product can be highly usable for sighted users but completely inaccessible to a blind user.
“The drag-and-drop file upload is great UX, but it’s not accessible — keyboard-only users and screen reader users need an alternative input method.”
WCAG and Compliance Levels
WCAG (Web Content Accessibility Guidelines)
WCAG is the international standard for web accessibility, published by the W3C. The current version is WCAG 2.2. It defines success criteria organised into three levels.
WCAG Levels: A, AA, AAA
- Level A — the minimum. Failing these criteria makes content inaccessible to some users.
- Level AA — the target for most organisations. Required by UK law (Equality Act) and many international regulations. Covers colour contrast, text resize, keyboard navigation, and more.
- Level AAA — the highest level. Not required for entire sites — some criteria are impossible to satisfy for all content types.
“Our target is WCAG 2.2 AA — that’s what the public sector accessibility regulations require. AAA is aspirational for critical flows.”
POUR Principles
WCAG is organised around four core principles, summarised as POUR:
Perceivable
Content and UI components must be perceivable — available to at least one of a user’s senses. This means providing text alternatives for images, captions for video, and not relying on colour alone to convey information.
“The error state uses red colour only — that’s not perceivable for colour-blind users. Add an icon or text label.”
Operable
All functionality must be operable using a keyboard alone, and users must have enough time to complete tasks.
“The modal closes after 30 seconds — that’s not operable for users who need more time to read. Add a way to extend the session.”
Understandable
Content and UI must be understandable — text must be readable, behaviour must be predictable, and forms must help users avoid and correct errors.
“The error message just says ‘Invalid input’ — that’s not understandable. Tell the user exactly what format is expected.”
Robust
Content must be robust enough to work with current and future assistive technologies. This means writing valid HTML and using semantic elements and ARIA correctly.
ARIA
ARIA (Accessible Rich Internet Applications)
ARIA is a set of HTML attributes that communicate the role, state, and properties of UI elements to assistive technologies when native HTML semantics are insufficient.
“We built a custom combobox in JavaScript — it has no native HTML equivalent, so we need ARIA attributes to make it understandable to screen readers.”
The first rule of ARIA: don’t use ARIA if a native HTML element already does the job.
ARIA Roles
An ARIA role tells assistive technologies what type of element this is. Example: role="dialog", role="alert", role="tablist".
“The modal div needs
role='dialog'andaria-modal='true'so the screen reader announces it as a dialog when it opens.”
ARIA Properties
ARIA properties describe characteristics of an element that do not change often. Examples: aria-label (provides an accessible name), aria-describedby (links to a description), aria-required.
“Add
aria-label='Close modal'to the X button — otherwise the screen reader just says ‘button’ with no context.”
ARIA States
ARIA states describe dynamic conditions that change based on user interaction. Examples: aria-expanded, aria-checked, aria-disabled, aria-selected.
“When the accordion panel opens, toggle
aria-expandedfromfalsetotrue— the screen reader will announce ‘expanded’ to the user.”
Accessible Name
The accessible name is the text that assistive technology announces for an element. It comes from: visible text, aria-label, aria-labelledby, or the alt attribute for images.
“That icon button has no accessible name — there’s no visible text, no
aria-label, and notitle. The screen reader says nothing useful.”
Focus Management
Focus Management
Focus management means programmatically controlling which element has keyboard focus, especially when content changes dynamically — opening a modal, loading new content, or showing an error.
“When the modal opens, move focus to the first interactive element inside it. When it closes, return focus to the button that opened it.”
Keyboard Navigation
Keyboard navigation means all interactive elements can be reached and activated using the keyboard alone — typically using Tab, Shift+Tab, Enter, Space, and arrow keys.
“I can Tab to the menu button, but I can’t open the dropdown with Enter or Space — that’s a keyboard navigation failure.”
Skip Link
A skip link is a visually hidden link at the top of the page that keyboard users can activate to jump past repetitive navigation and go directly to the main content.
“Add a skip link — keyboard users shouldn’t have to Tab through 40 navigation items on every page load.”
Focus Trap
A focus trap keeps keyboard focus inside a specific container — most commonly a modal dialog — so users cannot accidentally Tab into content behind it.
“The modal needs a focus trap. Right now you can Tab out of it into the page behind it — that breaks the expected behaviour for keyboard and screen reader users.”
Screen Reader Testing
Screen Reader Compatibility
The main screen readers are NVDA (Windows, free), JAWS (Windows, commercial), and VoiceOver (macOS/iOS, built-in). Testing across multiple readers is important because they interpret ARIA differently.
“It works in VoiceOver, but JAWS reads the form labels out of order. Always test with at least two screen readers.”
Live Region
An ARIA live region (aria-live) is an area of the page that updates dynamically. The screen reader announces updates automatically without the user navigating to them.
“The toast notification is visually visible but never announced to screen reader users. Wrap it in an
aria-live='polite'region.”
Colour and Visual Accessibility
Colour Contrast Ratio
The colour contrast ratio measures the luminance difference between text and its background. WCAG AA requires 4.5:1 for normal text and 3:1 for large text.
“The grey placeholder text is 2.8:1 against the white background — it fails WCAG AA. Darken it to at least 4.5:1.”
Semantic HTML
Semantic HTML
Semantic HTML means using elements that carry meaning — <nav>, <main>, <button>, <label>, <h1>–<h6> — rather than <div> and <span> for everything. Semantic elements give assistive technologies the information they need for free.
“Replace
<div class='button'>with an actual<button>element — you get keyboard focus, Enter/Space activation, and the correct ARIA role without writing a single extra line of code.”
Common Accessibility Phrases
| Phrase | Meaning |
|---|---|
| ”It fails 1.4.3” | It does not meet WCAG 2.x success criterion 1.4.3 (colour contrast) |
| “This is keyboard inaccessible” | Users cannot reach or activate this without a mouse |
| ”The accessible name is missing” | The screen reader has nothing useful to announce |
| ”We need to audit this component” | Review it against WCAG criteria and screen reader behaviour |
| ”That’s redundant ARIA” | You’re re-declaring what a native HTML element already says |
| ”Focus doesn’t return” | After closing a modal, keyboard focus goes to the wrong place |
| ”Mark it as decorative” | alt="" on images that add no information |