Accessibility Vocabulary for Developers: WCAG, ARIA, and Inclusive Design Terms Explained

Accessibility is no longer an optional concern for software teams. Whether you are working on a government portal, a SaaS product, or an internal tool, you will encounter accessibility requirements — and you will need to talk about them precisely. The problem is that the vocabulary is dense: WCAG, ARIA, conformance levels, focus traps, screen readers. For developers working in English as a second language, this domain carries both technical and linguistic complexity. This guide unpacks both.

The POUR Principles

Every accessibility requirement in the Web Content Accessibility Guidelines (WCAG) traces back to four core principles, known collectively as POUR: Perceivable, Operable, Understandable, and Robust.

Perceivable means that information and interface components must be presentable to users in ways they can perceive. In practice: if a user cannot see an image, there must be a text alternative. If a user cannot hear audio, captions must be available.

Operable means that the interface must be navigable and usable without relying on a specific input method. Keyboard-only navigation must work. There must be no time limits that cannot be adjusted. Nothing should flash more than three times per second.

Understandable means that both the content and the operation of the interface must be comprehensible. Label your form fields. Write clear error messages. Do not change context unexpectedly.

Robust means that content must be interpreted reliably by a wide range of user agents, including current and future assistive technologies. In practice: write valid HTML, use semantic elements correctly, and do not rely on browser quirks.

How do these appear in real code review conversations?

“This fails Perceivable — the image has no alt attribute.” “The keyboard trap on this modal breaks Operable. You can tab in but you cannot tab out.” “The error message just says ‘Invalid input’ — that’s a problem for Understandable.”

Knowing which principle a bug violates helps you frame the severity and the required fix more precisely.

WCAG Conformance Levels

WCAG organises its success criteria into three conformance levels: A, AA, and AAA.

Level A represents the minimum. These are the success criteria without which a page is essentially unusable for some users. Failure at Level A is a hard barrier: the content cannot be accessed at all.

Level AA is the standard target for most commercial products and is legally required in many jurisdictions — including the EU under EN 301 549, and the United States under Section 508. When a contract or brief refers to “WCAG 2.1 compliance”, it almost always means AA conformance.

Level AAA is aspirational. Some AAA criteria are impractical to meet for all content — they are typically targeted in specific contexts, such as applications for users with cognitive disabilities.

In professional writing and pull request comments, you will reference specific success criteria (SC):

“SC 1.4.3 Contrast (Minimum) requires a 4.5:1 ratio for body text at AA. Our primary text on this background is 3.2:1.” “This component fails SC 2.1.1 — all functionality must be operable via keyboard.”

The format SC [number] [Name] is the standard reference pattern. Learn to use it.

ARIA Roles and Attributes

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that modify the way assistive technologies interpret the DOM. It exists to fill gaps where native HTML semantics are insufficient — particularly for custom interactive components.

Key attribute distinctions:

aria-label provides a direct string label for an element. Use it when there is no visible label text.
aria-labelledby points to another element by ID whose text content serves as the label. Preferred over aria-label when visible text already exists.
aria-describedby provides a longer description, supplementing the label. Common on form inputs with hint text.
aria-live tells screen readers to announce dynamic content changes. aria-live="polite" waits until the user is idle; aria-live="assertive" interrupts immediately.
aria-expanded communicates the open/closed state of a collapsible component.
aria-hidden="true" removes an element from the accessibility tree entirely — useful for decorative icons.

How to discuss these in PR comments:

“Add aria-expanded={isOpen} to this button so screen readers announce the state change when the dropdown opens.” “Use aria-live="polite" for this status message — it’s non-critical, so we don’t want to interrupt the user.” “This icon is decorative — add aria-hidden="true" so it’s not announced unnecessarily.”

The golden rule of ARIA: no ARIA is better than bad ARIA. A misapplied role or attribute actively misleads assistive technology. If a native HTML element can do the job, use it.

Focus Management Vocabulary

Keyboard navigation depends entirely on correct focus management — controlling which element receives keyboard focus and when.

Key terms:

Focus ring: the visible outline that indicates which element currently has keyboard focus. Removing it without providing an alternative is a WCAG failure.
Focus trap: a pattern that keeps focus within a specific container — necessary in modal dialogs, but a bug if it appears unintentionally and prevents the user from leaving.
Skip link: a visually hidden (but keyboard-accessible) link at the top of the page that jumps directly to the main content, bypassing navigation.
Focus order: the sequence in which elements receive focus on Tab keypress. Should match the visual reading order.

Phrases for describing focus issues:

“The tab order doesn’t match the visual order here — it jumps from the header to the footer, skipping the main content.” “After this modal closes, focus should return to the trigger element that opened it. Right now it drops to the top of the document.” “We need a skip link here — sighted keyboard users have to tab through the entire navigation on every page.”

Accessibility Audit Language

An accessibility audit is a structured evaluation of a product against WCAG success criteria. Audits combine automated testing — tools run programmatically to catch a defined subset of issues — and manual testing, which requires human judgment and assistive technology.

Automated testing tools commonly referenced:

axe (browser extension and CI integration): fast, low false-positive rate
Lighthouse (built into Chrome DevTools): generates a scored accessibility report
WAVE (browser extension): visual annotation of issues on the live page

Automated tools can detect approximately 30–40% of WCAG issues. The rest require manual review.

Screen readers you will reference:

NVDA (NonVisual Desktop Access) — Windows, free
VoiceOver — macOS and iOS, built-in
TalkBack — Android, built-in
JAWS — Windows, enterprise-grade

Writing accessibility bug reports in the standard format:

“This fails WCAG 2.1 SC 1.4.1 Use of Color — colour is the only distinguishing factor between the active and inactive states. Add an icon or underline.” “Medium severity: the form field for email address has no associated <label>. Screen reader users will not know what to enter.” “Automated (axe) + manual (NVDA + Chrome): the modal does not trap focus. Tab key exits the modal and navigates behind it.”

A well-written accessibility bug report names the WCAG SC, describes the failure in plain language, states the severity, and notes which method detected it.

Practice Accessibility Vocabulary

Reinforce these terms with hands-on exercises:

Understanding the vocabulary is the first step. Being able to explain a WCAG violation clearly in a code review, a bug report, or a client meeting is a professional skill that sets strong engineers apart.