The digital accessibility glossary, in plain English.

Whether NVDA, JAWS or VoiceOver can navigate your page: correct heading order, labelled form fields, alt text on meaningful images, and live regions that announce changes. This is the single most-tested category in axe-core-based scanning.

Every interactive element reachable and operable without a mouse, no keyboard traps, a logical tab order, visible focus indicators. WCAG 2.1.1 and 2.1.2, both automatable to a good degree.

Custom dropdowns, tabs, modals and comboboxes built with the correct ARIA roles, states and properties, so they read as the right control type to assistive tech instead of an unlabelled <div>.

Head pointers, sip-and-puff controllers and other adaptive hardware generally work through the same keyboard and pointer events a scanner already checks, but confirming the actual experience is a manual-audit task, not something a script can certify.

Single-switch scanning depends on predictable focus order and generously sized targets, both things our audits flag, but full switch-device testing needs the physical hardware and a specialist tester. We design for it; we don't lab-test it.

Voice Control and Dragon rely on visible, unique accessible names for every control (WCAG 2.5.3, Label in Name), which we do check. Testing actual voice-command sessions is a specialist QA discipline outside a standard audit.

Eye-tracking and gaze-control users benefit from the same large targets and stable layouts (WCAG 2.5.5, 2.5.4) as switch and voice users. We flag the underlying issues; we don't run dedicated eye-tracking test rigs.

Braille displays render whatever a screen reader exposes, so the fix is upstream: clean semantics and accurate accessible names. Once those pass, braille-display output is a manual spot-check, not a separate build.

Reflow at 400% zoom, non-colour ways to convey meaning, text that survives a custom stylesheet. Automated checks catch pieces of this; a real 400%-zoom walkthrough is a manual-audit line item.

4.5:1 for body text, 3:1 for large text and UI components (WCAG 1.4.3 / 1.4.11). This is one of the most reliably automatable checks in the entire standard, and one of the most common findings.

A visible outline on every focused element, never suppressed with outline:none and nothing to replace it. WCAG 2.4.7 and, at AA in 2.2, 2.4.11 Focus Not Obscured.

A "Skip to content" link as the first focusable element, so keyboard and screen reader users don't tab through the entire header on every single page.

Text set in relative units that actually resizes with the browser's zoom or font-size setting, up to 200%, without clipping or overlap (WCAG 1.4.4).

Print stylesheets and downloadable reports that hold up at large point sizes, most relevant for the PDF/Excel reports and documentation the EAA requires, checked as part of a manual audit.

Content structured so TTS tools read it in a sensible order: real headings, real lists, language attributes set correctly (including on any mixed-language phrases).

Pre-recorded video with meaningful visual information needs a narrated audio description track (WCAG 1.2.5). A scanner can detect a missing track; whether the narration is actually accurate needs a person to watch it.

Synchronized, accurate captions on video, and a player UI where the caption toggle itself is keyboard- and screen-reader-accessible. Caption presence is easy to check; caption accuracy is a manual review.

For prerecorded content where the EAA or your sector rules require it, a sign language interpretation track alongside captions, not a replacement for them. We check that it's present and that the player exposes it accessibly.

Predictable navigation, no unexpected context changes, clear error messages that say how to fix the problem, not just that something failed.

Reduced motion by default, no auto-playing carousels, consistent placement of navigation and help across pages, WCAG 2.2's Consistent Help criterion in practice.

Short sentences, one idea per paragraph, jargon defined on first use. Directly relevant to the EAA's plain-language requirements for accessibility statements and terms.

Respecting prefers-reduced-motion, no flashing content above the seizure threshold (WCAG 2.3.1), and animation that can be paused, stopped or hidden (2.2.2). All of it directly scannable.

An EAA compliance tool that runs a real audit engine against your live URL and cross-walks every finding to Directive (EU) 2019/882, no signup, results in your browser.

The harmonised European standard the EAA presumes conformance against. Clause 9 adopts WCAG 2.1 A/AA in full; we map every finding to its specific clause, not just a generic "fail".

A stakeholder-ready PDF plus a developer-ready Excel, frontend and backend fixes split out, so design and engineering aren't reading the same undifferentiated list.

The same open-source engine behind Chrome Lighthouse's accessibility panel, running entirely client-side. Same detection logic you'd get from deque's own tools, wrapped in EAA-specific reporting.

Documentation formatted the way an authority actually wants to see it during an enforcement review, findings, severity, and remediation status, not a raw console log.

Once a Formal Notice starts your 30–90 day cure period, you need evidence you actually fixed what was cited. Our Manual Expert Audit produces exactly that.

Payment flows, identity verification, and account dashboards, tested for the specific barriers that block a transaction outright, not just cosmetic contrast issues.

EAA Annex I names banking services explicitly. A compliance review covers the web app, the statements and disclosures, and how accessible authentication actually is (WCAG 2.2's Accessible Authentication).

Runs inside Figma, free on the Figma Community, so a11y checks happen at design time, before a single line of code gets written.

Flags failing text/background combinations directly on the frame, and suggests the nearest AA-passing colour instead of just failing silently.

The web app's Apply Fix & Copy Code button generates corrected markup for common findings, contrast, tap targets, missing labels, ready to paste into your codebase.

Audits markup right inside the editor, same engine and EAA/EN 301 549 mapping as the web app, so accessibility review happens in the same tool the code was written in.