Glossaire de l'accessibilité

The text that assistive technologies use to identify a UI component. Computed by the accessible name and description computation algorithm, which draws on aria-labelledby, aria-label, the element's content, or a native HTML label.

A document, usually built on the VPAT template, that formally declares how a product meets accessibility standards. Commonly requested in enterprise and government procurement.

Americans with Disabilities Act (1990). Title III prohibits discrimination by places of public accommodation, which many courts have applied to websites and apps (federal courts are split on sites with no physical location). 3,117 federal ADA website lawsuits were filed in 2025, up 27% on 2024 (Seyfarth Shaw).

Advanced Perceptual Contrast Algorithm. A perceptual model for colour contrast based on spatial frequency and visual acuity. Explored for WCAG 3.0 but removed from the working draft in July 2023. WCAG 2.x contrast (4.5:1 for normal text) remains the legal requirement.

Accessible Rich Internet Applications (WAI-ARIA). A W3C specification that defines roles, states, and properties added as HTML attributes to communicate semantics to assistive technologies when native HTML is insufficient. The first rule of ARIA: use native HTML elements instead wherever possible.

An element with aria-live='polite' or 'assertive' that announces dynamic content changes to screen readers without requiring the user to move focus. Used for status messages, notifications, and error announcements. WCAG 4.1.3 (Level AA, new in 2.1) requires status messages to be programmatically determinable, which in practice usually means a live region.

A WAI-ARIA attribute that defines the purpose of an element, e.g. role='button', role='dialog', role='navigation'. Roles override the implicit semantics of the host element and tell screen readers how to interact with it.

Assistive Technology. Hardware or software that helps people with disabilities interact with digital content. Screen readers, braille displays, switch controls, eye-tracking devices, voice recognition, and alternative keyboards all qualify.

Accessibility for Ontarians with Disabilities Act (2005). Canadian provincial law requiring public-sector and large-private-sector organisations to meet WCAG 2.0 AA by 2021. Many organisations aim higher, at WCAG 2.1 or 2.2 AA, which include everything in 2.0 AA.

Open-source automated accessibility rules engine by Deque Systems. Used in Chrome DevTools' Lighthouse and many CI pipelines. Deque reports that, in its own study, axe-core found about 57% of accessibility issues automatically.

The alt attribute on an <img> element. Provides a text alternative for non-text content per WCAG 1.1.1 (Level A). Decorative images should use alt='' (empty); informative images need a concise description; complex images (charts, diagrams) may require a long description.

A hardware device with a row of refreshable braille cells that translate on-screen text to tactile braille in real time. Typically used alongside a screen reader by deafblind users.

A foundational accessibility distinction. Buttons (<button>) trigger actions (submit, open dialog, toggle). Links (<a href>) navigate to a new destination. Using the wrong element mismatches keyboard behaviour and screen reader announcements: links are activated with Enter, buttons with both Enter and Space.

Completely Automated Public Turing test to tell Computers and Humans Apart. Visual CAPTCHAs are a significant accessibility barrier. WCAG 1.1.1 requires a CAPTCHA to describe its purpose in text and to offer a version in another sense, such as audio. WCAG 3.3.8 (new in 2.2, Level AA) adds that a login step must not depend on a cognitive function test, such as retyping distorted characters, unless an alternative or a mechanism to help is provided; object-recognition CAPTCHAs are an exception at Level AA.

Cognitive and Learning Disabilities Accessibility Task Force (W3C). Produces supplemental guidance, including 'Making Content Usable for People with Cognitive and Learning Disabilities', which defines 8 design objectives. Its work is informing the WCAG 3.0 drafts.

Design practices that support users with cognitive and learning disabilities including ADHD, dyslexia, autism spectrum conditions, aphasia, TBI, and aging-related decline. Encompasses clear language, predictable navigation, error prevention, reduced distractions, and consistent UI patterns.

The measured difference in luminance between foreground and background colours. WCAG 1.4.3 (Level AA) requires a minimum 4.5:1 ratio for normal text and 3:1 for large text. WCAG 1.4.11 requires 3:1 for non-text UI components and graphical objects.

WCAG organises success criteria into three levels: A (minimum), AA (the usual legal requirement), AAA (enhanced). Full AA conformance means meeting all Level A and AA criteria. Most laws reference WCAG 2.x Level AA.

A number from 1:1 (no contrast) to 21:1 (black on white) expressing the luminance difference between two colours. Calculated per the WCAG relative luminance formula. A ratio of at least 4.5:1 is required for normal text under WCAG 1.4.3 AA.

21st Century Communications and Video Accessibility Act (2010). US law requiring advanced communications services (email, SMS, VoIP, browsers) and video programming to be accessible to people with disabilities.

Disability Discrimination Act. Refers to laws in several countries: the UK DDA (1995, superseded by the Equality Act 2010) and the Australian DDA (1992), which requires websites not to unjustifiably discriminate against users with disabilities.

An image that is purely decorative and adds no information. Should have alt='' (empty alt attribute) so screen readers skip it. Using a non-empty alt for decorative images adds noise to the screen reader experience.

European Accessibility Act (EU Directive 2019/882). Has applied since June 28, 2025, across all EU member states. Covers listed products and services, such as e-commerce, consumer banking, e-books, passenger transport and electronic communications, including the websites and mobile apps used to provide them. The Act sets functional requirements; EN 301 549 is the European standard used to meet them, and its clause 9 corresponds to WCAG 2.1 AA.

Harmonised European standard for ICT accessibility. Chapter 9 maps directly to WCAG 2.1 AA for web content; Chapters 10 and 11 extend requirements to documents and software. Harmonised under the EU Web Accessibility Directive, used for the EAA and widely used in EU public procurement.

Technology that lets users control a computer with their gaze. Users with severe motor impairments, such as ALS or spinal cord injuries, may rely on eye tracking as their primary input. Designers must ensure interactive elements are large enough and adequately spaced (see WCAG 2.5.8 Target Size).

The visible outline shown on the currently focused interactive element. WCAG 2.4.7 (AA) requires keyboard focus to be visible. WCAG 2.4.11 (AA, new in 2.2) requires the focus indicator to not be entirely hidden. WCAG 2.4.13 (AAA, new in 2.2) defines minimum area and contrast requirements.

The practice of programmatically moving keyboard focus to the appropriate element after a user interaction, for example moving focus into a newly opened modal dialog, or back to the trigger element after it closes. Poor focus management leaves keyboard and screen reader users lost on the page.

A pattern that constrains keyboard focus within a component (typically a modal dialog) so users cannot Tab out of it while it is open. Required for accessible dialogs per the ARIA Authoring Practices Guide (APG). Implemented with JavaScript that intercepts Tab and Shift+Tab keydown events.

A design strategy where a feature works fully for capable browsers or AT configurations and falls back to a simpler but still usable experience for less capable environments. The opposite of progressive enhancement, which builds upward from a baseline.

The correct nested structure of heading elements (h1 to h6) on a page. Screen reader users navigate by headings: H in NVDA and JAWS, the rotor in VoiceOver. WCAG 1.3.1 (Level A) requires information conveyed by heading structure to be programmatically determinable.

A design methodology (popularised by Microsoft's Inclusive Design toolkit) that recognises exclusion as a mismatch between a person's needs and what is designed. Focuses on solving for one, extending to many: design for disability often benefits everyone (curb cuts, captions, voice control).

Job Access With Speech. The most widely used commercial screen reader for Windows, developed by Freedom Scientific. Widely used in enterprise and government settings, where JAWS with Chrome or Edge is a common test setup for accessibility QA.

The ability to operate all interactive elements (links, buttons, forms, dialogs, custom widgets) using only a keyboard. Required by WCAG 2.1.1 (Level A). Keyboard-only users include people with motor disabilities, power users, switch device users, and braille display users.

HTML5 sectioning elements (<main>, <nav>, <header>, <footer>, <aside>, <section>, <article>) and their ARIA role equivalents that divide a page into named regions. Screen reader users jump between landmarks to navigate quickly. A best practice at all WCAG levels.

Open-source automated auditing tool built into Chrome DevTools and CI pipelines. The accessibility audit runs axe-core checks and scores 0 to 100. A Lighthouse score of 100 does not mean full WCAG conformance: automated tools find only part of the issues a manual audit finds.

Relative luminance is a W3C-defined measure of a colour's perceived brightness, normalised 0 (black) to 1 (white). Calculated from linear-light RGB values using coefficients reflecting human visual sensitivity (0.2126 R, 0.7152 G, 0.0722 B). The basis for WCAG contrast ratio calculations.

An overlay component that interrupts the user's workflow and requires interaction before they can return to the main content. Accessible modals require: focus trap, aria-modal='true', a visible close mechanism, role='dialog', an accessible name via aria-labelledby, and focus return to the trigger on close.

NonVisual Desktop Access. Free, open-source screen reader for Windows by NV Access. Alongside JAWS, one of the two most widely used screen readers in WebAIM's screen reader user surveys. NVDA with Chrome is a common combination for web accessibility testing.

The second WCAG principle (O in POUR). All interface components and navigation must be operable. Covers keyboard accessibility, timing, seizure safety, navigation, and input modalities. Contains 5 guidelines and 34 success criteria in WCAG 2.2.

Open-source automated accessibility testing CLI and Node.js library. Uses axe-core and HTML_CodeSniffer as test runners. Popular for CI/CD pipeline integration: it can be configured as a pre-commit hook or CI step to block merges on accessibility failures.

The first WCAG principle (P in POUR). Information and UI components must be presentable in ways users can perceive, covering text alternatives, time-based media, adaptability, and distinguishability. Contains 4 guidelines and 29 success criteria in WCAG 2.2.

Writing that the reader can understand the first time they read it. Core techniques: short sentences (15 to 20 words), active voice, common vocabulary, clear headings. Supports WCAG 3.1.5 (Reading Level, AAA) and is central to W3C COGA guidance. A Flesch-Kincaid grade of 8 or below is a common target.

The four principles of WCAG 2.x: Perceivable, Operable, Understandable, Robust. Every WCAG success criterion falls under one of these principles. A page must satisfy all four principles to conform to WCAG.

A strategy that builds from a solid, accessible HTML baseline (content and core functionality work without CSS or JS) and layers on enhancements for capable environments. Tends to produce more accessible results than graceful degradation.

How easily a reader can understand written text. Measured by formulas such as Flesch-Kincaid Grade Level, Flesch Reading Ease, and Gunning Fog Index. Cognitive accessibility guidelines recommend targeting a Flesch-Kincaid grade of 6 to 9 for general audiences.

WCAG 3.3.7 (Level A, new in 2.2). Requires that users are not asked to re-enter information already provided in the same process unless re-entry is essential or required for security. Reduces cognitive load in multi-step forms.

The fourth WCAG principle (R in POUR). Content must be robust enough to be reliably interpreted by a wide variety of current and future user agents, including assistive technologies. In WCAG 2.2 it contains two success criteria: Name, Role, Value (4.1.2) and Status Messages (4.1.3).

Software that reads on-screen content aloud and via braille display for users who are blind or have low vision. Major screen readers: JAWS and NVDA (Windows), VoiceOver (Apple), TalkBack (Android), Orca (Linux). Screen readers depend on semantic HTML and correct ARIA to communicate content.

Section 508 of the US Rehabilitation Act. Requires US federal agencies to make the ICT they develop, buy, maintain or use accessible, which is why vendors selling to agencies are asked for conformance reports. The Revised Section 508 Standards (compliance from January 2018) adopted WCAG 2.0 AA for web content. Recipients of federal funding are covered by Section 504 instead.

The meaning conveyed by HTML elements beyond their visual appearance. A <nav> means navigation; a <button> means interactive trigger; a <h2> means a second-level heading. Correct semantics are the foundation of accessibility: they allow AT to convey structure and purpose without vision.

A visually hidden link that becomes visible on focus, allowing keyboard and screen reader users to jump past repeated navigation directly to main content. WCAG 2.4.1 Bypass Blocks (Level A) is typically satisfied by a skip link. Usually implemented as the first element in <body>.

A message that conveys success, error, warning, or progress, typically shown dynamically without receiving focus. WCAG 4.1.3 (Level AA, new in 2.1) requires status messages to be programmatically determinable via role or property so AT can announce them.

A testable, pass/fail statement in WCAG. Each SC belongs to a guideline, a principle, and a conformance level (A, AA, or AAA). WCAG 2.2 contains 86 success criteria across 13 guidelines and 4 principles (61 from WCAG 2.0, plus 17 added in 2.1 and 9 added in 2.2, minus 4.1.1 Parsing which 2.2 removed as obsolete). Nine new SCs were added in WCAG 2.2.

A method of controlling a device using one or more physical switches. Used by people with severe motor disabilities. Switch access relies on scanning (elements are highlighted in sequence) and requires all interactive elements to be reachable via keyboard navigation.

The sequence in which keyboard focus moves through interactive elements when the user presses Tab. Should follow the logical reading order of the page. WCAG 1.3.2 Meaningful Sequence (Level A) and WCAG 2.4.3 Focus Order (Level A) require a logical order that preserves meaning.

Google's built-in screen reader for Android. The primary AT for Android users who are blind or have low vision. TalkBack + Chrome is the standard combination for Android accessibility testing. Android uses AccessibilityNodeInfo to communicate with TalkBack.

The minimum area of a pointer or touch target. WCAG 2.5.5 (Level AAA) requires 44×44 CSS pixels. WCAG 2.5.8 Target Size (Minimum) (Level AA, new in 2.2) requires 24×24 CSS pixels unless the target has adequate spacing. Matters most for people with motor disabilities and for touch users.

The third WCAG principle (U in POUR). Content and UI must be understandable, covering readable text, predictable behaviour, and input assistance. Contains 3 guidelines and 21 success criteria in WCAG 2.2.

The design of products and environments usable by all people, to the greatest extent possible, without adaptation or specialised design. The term was coined by architect Ron Mace. Differs from inclusive design in starting from the broadest baseline rather than designing from a specific excluded group outward.

Apple's built-in screen reader on macOS, iOS, and iPadOS. Dominant screen reader for Mac and iPhone users. VoiceOver + Safari is the most common combination for Apple platform accessibility testing. Activated on Mac with Command+F5; on iOS with triple-click of the side/home button.

Voluntary Product Accessibility Template. A standardised document structure (maintained by ITI) for reporting a product's conformance with accessibility standards. VPAT 2.5 supports Section 508, WCAG 2.x, and EN 301 549. Completed VPATs are published as Accessibility Conformance Reports (ACRs).

Web Accessibility Initiative. The W3C programme responsible for developing accessibility guidelines and standards including WCAG, ARIA, ATAG (Authoring Tool Accessibility Guidelines), and UAAG (User Agent Accessibility Guidelines).

Web Content Accessibility Guidelines. The international standard for web accessibility produced by the W3C. WCAG 2.2 (September 2023) is the current version with 86 success criteria. WCAG 2.1 AA is the legal minimum in the EU (EAA/EN 301 549), and WCAG 2.0 AA in the US (Section 508). DOJ rule mandates WCAG 2.1 AA for US state/local government.

The current (September 2023) version of WCAG. Added 9 new success criteria: 2.4.11 Focus Not Obscured, 2.4.12 Focus Not Obscured Enhanced, 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size Minimum, 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication Minimum, 3.3.9 Accessible Authentication Enhanced. Also removed SC 4.1.1 Parsing.

The W3C working draft for the next generation of accessibility guidelines. As of the September 2026 working draft it is incomplete and not yet a standard, and W3C expects it to take a few more years. To conform, content must meet all core requirements, which are tagged by their impact on people, and results are reported in six tiers. Its scope covers web content, apps, tools, publishing and emerging technologies. WCAG 2.x remains the legal standard for the foreseeable future.

World Wide Web Consortium. The international standards body that develops Web standards including WCAG, HTML, CSS, ARIA, and SVG. The WAI is a programme within W3C specifically focused on accessibility.