Select journeys
Include entry, navigation, form, confirmation and error state. Check a page on mobile and at high zoom.
GUIDE / PROTOCOL
Audit accessibility across a web journey
Accessibility is assessed across a whole task: find, understand, act and recover from an error.
Direct answer
How do you run a useful accessibility audit?
Select representative journeys and critical states. Combine code inspection, keyboard navigation and assistive technology checks. Connect each defect to a blocked task, a WCAG requirement, evidence and a retest.
01 / Review method
Review method
Use the keyboard
Check focus order and visibility, every control, menus, dialogs and exit from components. Identify keyboard traps.
Check meaning and output
Review headings, accessible names, labels, image alternatives, structure, contrast and error announcements with a screen reader.
Prioritize and replay
Rank failures by task and severity, fix shared components, then replay the journey and pages using them.
IN PRACTICE
Check a journey, not just a screenshot
A readable screen can still block an action. Test a complete goal: find the right section, use the control, understand the result and go back. Record the first obstacle and its practical effect.
Which check comes first?
Choose the situation you observed. Each path gives a first check, useful evidence and the limit of that check.
The task works with a mouse but not a keyboard
- First check
- Repeat a task using Tab, Shift+Tab, Enter and the component’s expected keys. Track focus: where does it enter, which control receives it and can you leave a menu or dialog?
- Evidence to retain
- Step, key, focused control, open or closed state and the exact point where the task blocks or becomes unclear.
- Limit to remember
- Logical focus order does not certify overall accessibility. Also examine control names, announced states and content reading.
A form rejects input without explaining why
- First check
- Trigger one field error and review its label, expected format and associated message. Check that it can be corrected without losing other useful values.
- Evidence to retain
- Field, non-sensitive test value, message, error-to-field association, focus behaviour and result after correction.
- Limit to remember
- A visible message may not be associated with its field or announced at the right time. Also test submission, confirmation and unavailability.
Text overflows or becomes hard to read
- First check
- Narrow the window, enlarge text and repeat the task. Identify the component forcing the whole page to scroll horizontally; distinguish it from a table needing two-dimensional layout.
- Evidence to retain
- Viewport width, zoom level, language, component, hidden text and genuine need for two-direction scrolling.
- Limit to remember
- One mobile screenshot does not cover every zoom, language and state. A table exception does not justify whole-page overflow.
Further reading
| Situation | Avoid | Useful correction |
|---|---|---|
| Navigation | Testing only with a mouse. | Traverse by keyboard and retain visible focus. |
| Form | Relying on temporary text inside a field. | Keep a visible label and connect the error to its field. |
| Dynamic result | Changing a number without context. | Provide the result, unit and what changed. |
Locate
Does the heading describe the right task?
Act
Is the control accessible and understandable?
Understand
Are the result and next action explicit?
Final check
Repeat the journey with Tab, Shift+Tab and Enter, then at 200% zoom. While scrolling, check that the fixed header does not completely hide the focused control. Open and close the menu using the keyboard, trigger a form error and check that you can correct it. Record the page, action and obstacle observed; these targeted checks are not WCAG certification.
Documentary references
Consulted on .
Reading workshop
Test the complete modal dialog cycle
Fictional case DEMO-A23 observes opening, disabled state, background and closure of a review dialog.
Fictional data and records for learning: none of these results comes from a live service query.
Confirm a choice after reading
The dialog contains a title, a “reading complete” checkbox, an initially disabled Confirm button and Cancel. Its trigger remains present after closure.
Open by keyboard
- Scenario observation
- Focus reaches the title to read
- What it establishes
- The task starts inside the dialog, not behind it.
- Next action
- Check the announced name and instruction reading.
Navigate initial state
- Scenario observation
- Tab reaches checkbox then Cancel; Confirm disabled
- What it establishes
- The unavailable action must not execute.
- Next action
- Check the box by keyboard, verify Confirm activation and repeat navigation.
Try the background
- Scenario observation
- Page behind remains visible but inactive
- What it establishes
- Background receives neither action nor focus while modal.
- Next action
- Test Tab/Shift+Tab and a target behind; dimming alone is insufficient.
Close without confirming
- Scenario observation
- Escape closes; focus returns to trigger
- What it establishes
- The person can resume the original task.
- Next action
- Also repeat Cancel and reopening.
Try the focus cycle in a modal dialog
Opening puts focus on the heading. Tab then reaches the checkbox; Confirm stays disabled until it is checked. The background command must remain inactive while the dialog is open. Escape or Cancel returns to Open.
The interactive demonstration is unavailable in this configuration; the worked case remains readable.
Demonstration ready: no data is sent.
This example uses a native modal dialog. It illustrates a task and does not test your own site’s accessibility. The checkbox is neither authorization nor a server-side safeguard.
Can aria-modal alone establish acceptance?
Open each proposition to compare its diagnosis. More checks may still be needed.
Yes, it supplies all behaviour.
No: actions and focus cycle need checking.
Yes, if the background is dark.
No: appearance does not establish background inactivity.
No; check the cycle with the box checked and unchecked.
Appropriate. Retain defects and conditions; one successful component does not certify the website.
Keyboard task record
Case: DEMO-A23 Opening: focus on dialog title Initial state: unchecked; Confirm disabled Navigation: checkbox then Cancel; internal return After checking: Confirm available Background: no action or focus escape expected Escape: close and return to trigger
Retain keys, control states, announced name and focus before/after closure. Repeat with assistive technologies actually within scope.
Documentation of the rules, separate from fictional examples
02 / Evidence to keep
Evidence to keep
Scenario and environment
URL, device, browser, assistive technology, zoom and attempted action.
Reproduction
Exact steps, screenshot or DOM extract, observed and expected outcomes.
Requirement and impact
Relevant WCAG criterion, affected people or tasks, and reasoned severity.
Retest
Fix, version, date and results with keyboard and screen reader.
Compare other situations and exercises
PRACTICAL CHECK
Before reaching a conclusion
A frequent misreading and the check that helps avoid it.
Premature conclusion
A high automated score does not guarantee a usable journey; comprehension, focus and error-announcement barriers require human review.
Decisive check
Complete key tasks with a keyboard and assistive technology, record the blocking step and tie each fix to a verifiable criterion.
AFTER THE REVIEW
Decide from the evidence
The menu is visible but unavailable by keyboard
Hold journey approval, fix the shared component, then test opening, navigation and closing wherever it is used.
Automated checks pass but instructions remain unclear
Keep the tool result, record the failed task and rewrite instructions before testing with relevant access modes.
Decision and review trail
Decision and review trail
What the check must help decide and what to retain so the choice can be reviewed.
Sufficient evidence
Use the keyboard for essential tasks, errors and dynamic states; record URL, element, assistive technology and expected result. An automated score is insufficient.
Next decision
Rank journey blockers first. Fix the shared component, then retest the full task and affected mobile and language variants.
Detailed inspection cases
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
A visually readable table loses its headers
What to inspect
Check cell-to-header associations, linear reading and keyboard navigation. A correct visual presentation does not establish that each value remains understandable through another reading mode.
Decision and action
Correct structure and labels, then repeat a specific lookup task. Distinguish an automated analyser’s result from the journey actually completed.
Record to retain
Keep the tested table, affected cells, reading mode and sequence used to retrieve a value.
Focus disappears beneath a fixed banner
What to inspect
Follow links, open and close menus and change viewport size. Observe where focus lands, whether its target remains visible and whether closing returns control to the trigger.
Decision and action
Adjust positioning, scrolling or focus restoration. Repeat the entire journey, including after a form error, rather than checking only the first tab stop.
Record to retain
Record viewport size, keys used, component and focus positions before and after correction.
Focus is lost after interaction
What to inspect
Use filters, menus and forms by keyboard and inspect focus after state changes.
Decision and action
Keep the next task step reachable and its result understandable.
Record to retain
Keyboard sequence, state, focus position and correction.
Review before deciding
These questions complement the method. They help establish what is actually supported while retaining qualifications in the record.
Keyboard task
Can the task be completed by keyboard without a trap, with visible focus and no control obscured by a fixed region? Retain the tested path and browser.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The button receives keyboard focus but remains entirely hidden behind the fixed header.
- Declared state
- Observed discrepancy
- Decision and next check
- Fix positioning or scrolling and repeat the full keyboard path. DOM focus alone is insufficient.
Understandable errors
Do fields have explicit names and do errors explain recovery? Complement automated checks with zoom and screen-reader testing on the selected journeys.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- An invalid field turns red; its message neither names the field nor explains the correction.
- Declared state
- Observed discrepancy
- Decision and next check
- Add a textual error linked to the field and test recovery with keyboard and screen reader.
Reading with zoom
Do labels, tables and actions remain usable with zoom? Examine header-to-cell relationships, not just the absence of overflow.
Documentation consulted : W3C · WCAG 2.2 ·
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- In the zoomed test table, each value remains associated with row and column headers; its region is keyboard operable.
- Declared state
- Verified within this scope
- Decision and next check
- Retain browser, zoom and tested table. This success does not assess other tables or the whole site.
TOOLS / REGISTERS
Information to record
Reproduce the task with a keyboard and assistive technology. Record the exact element, relevant criterion and obstacle; an automated tool alone cannot establish conformance.
- Access date and time zone
- Exact URL
- Task / journey step
- Device / browser
- Acceptance criterion
- Observed result
- Decision / next action
- Review owner
- Next review
03 / FAQ
Frequently asked questions
Is an automated tool enough?
No. It finds some code errors but cannot always judge logical order, comprehension or task completion.
What comes first?
Shared components and essential journeys such as navigation, search, request, payment or contact.
Must every language be tested?
Test key screens: declared language, labels, errors and reading order can differ.
When can an issue close?
When the original scenario succeeds with relevant access modes and the fix does not break other states.
Can an automatic error-free interface remain blocked?
and yes. Automatic checks detect certain defects, but the execution of interactions remains necessary to observe the obstacles to navigation, understanding or validation.
04 / Official references
Official references
Describe a context
Turn a need into a defined assignment
A few interventions relevant to this topic. Each amount covers the stated reference scope; the quote confirms priorities and overlapping tasks.
Accessibility review
Keyboard, forms, contrast and readability; correction plan.
Templates : 3 · 6 h
From 480 € excl. VAT / 576 € incl. VAT
Preparation and delivery checks
- What to prepare
- Representative pages and components, user tasks and agreed assessment reference.
- Suggested process
- Define tasks, observe barriers and repeat the same checks after changes.
- Delivery to agree
- Reproducible findings, reviewed criteria and diagnostic limits; no implied certification.
- Review for this service
- Repeat agreed keyboard checks and document examined elements, criteria and limits.
- Scope boundaries
- A page or task sample does not establish results for every website use case.
Indicative working scope, to confirm in the quotation.
Mobile & responsive fixes
Overflow, components and touch interactions.
Templates : 3 · 4 h
From 320 € excl. VAT / 384 € incl. VAT
Preparation and delivery checks
- What to prepare
- Affected components, target widths, long text and languages in use.
- Suggested process
- Define tasks, observe barriers and repeat the same checks after changes.
- Delivery to agree
- Layout, zoom and interaction fixes across agreed dimensions.
- Review for this service
- Check agreed widths, long text and absence of overflow on scoped pages.
- Scope boundaries
- A page or task sample does not establish results for every website use case.
Indicative working scope, to confirm in the quotation.
CTA & form conversion
Value proposition, labels, errors and confirmation.
Journeys : 1 · 4 h
From 320 € excl. VAT / 384 € incl. VAT
Preparation and delivery checks
- What to prepare
- Intended action, current fields, frequent errors and enquiry qualification rule.
- Suggested process
- Define tasks, observe barriers and repeat the same checks after changes.
- Delivery to agree
- Revised labels, error messages and confirmation, with a checking journey.
- Review for this service
- Test a valid enquiry and an error, then check displayed instructions and confirmation.
- Scope boundaries
- A page or task sample does not establish results for every website use case.
Indicative working scope, to confirm in the quotation.
Prepare and review a service
Use these notes to scope the request and review delivery. The quotation defines the agreed work, volumes and schedule.
SXO, UX, accessibility & performance
Reduce barriers in a useful journey, especially on mobile and with a keyboard.
- What to prepare
- Supply priority journeys, target devices and errors actually encountered.
- Suggested process
- Define tasks, observe barriers and repeat the same checks after changes.
- Delivery to agree
- Agree a record of barriers, their context and corrections actually checked.
- Scope boundaries
- A page or task sample does not establish results for every website use case.
Acceptance check to prepare
Include errors, confirmations, open menus and fixed banners in keyboard testing. Record obscured focus and justify individual target-size exceptions; measuring an icon alone is insufficient.
See scope and pricingDOCUMENTED REFERENCE
WCAG 2.2: distinguish target size, focus and conformance level
State the WCAG version and intended level before assessing a journey. The numbers 24 and 44 refer to CSS pixels, not physical screen pixels. These checks alone do not establish overall conformance.
| Reference | Value or form | What it identifies |
|---|---|---|
| 2.5.8 | AA · 24 × 24 CSS px | AA minimum target size, with exceptions for spacing, an equivalent control, inline targets, unmodified user-agent controls and essential presentation. |
| 2.5.5 | AAA · 44 × 44 CSS px | Enhanced AAA target-size criterion with its own exceptions. Do not describe 44 × 44 as a universal AA requirement. |
| 2.4.11 | AA | A keyboard-focused component must not be entirely hidden by author-created content such as a fixed banner. |
| 2.4.12 | AAA | The enhanced criterion requires no part of the focused component to be hidden by author-created content. |
| 2.5.7 | AA | Dragging functions also need a single-pointer method without dragging, except essential cases or unmodified native controls. |
| 3.3.7 | A | Within the same process, previously supplied information must be reusable or selectable, except when security, invalid information or necessity justifies an exception. |
Implication for the record
Measure the interactive area, not just the icon drawing. Record exceptions individually and test open states, errors and confirmations with a keyboard. Automated checks cannot assess every focus obstruction or complete process.
Primary documentation
- W3C · WCAG 2.2 Recommendation, 12 December 2024
- W3C WAI · Target Size (Minimum)
- W3C WAI · Focus Not Obscured (Minimum)
Documentation consulted on .
DOCUMENTED REFERENCE
Form field: separate label, help, constraint and error
For a postal code, 00123 can be a string to preserve rather than a quantity to add. Control choice follows the intended meaning. This table gives separate checks for a form review; no single attribute proves that an application is valid or that the whole journey conforms.
| Reference | Value or form | What it identifies |
|---|---|---|
| label[for] / id | association | Associate the visible label with the control: for must target its id, unique in the document. name names submitted data; it does not create that association. |
| placeholder / aria-describedby | instructions | A placeholder disappears when a value is entered. Keep necessary instructions in persistent text; aria-describedby can link that text to the control. |
| type / inputmode | semantics / keyboard | inputmode suggests an input mode without enforcing syntax by itself. type=number suits a numeric quantity, not every identifier made of digits. |
| pattern | whole value | On an appropriate text field, pattern constrains the whole value. An empty optional field does not become required just because it has a pattern. |
| required / aria-required | constraint / state | required demands a value on applicable controls. aria-required announces a state; alone it does not create native submission blocking. |
| aria-invalid / error text | state / explanation | After detecting a problem, aria-invalid can expose the state. Add text identifying the field and explaining the problem: a red border alone is insufficient. |
| WCAG 3.3.1 / 3.3.3 | identification / suggestion | A correction suggestion differs from error identification. Provide it when known and when it would not compromise security or the purpose of the content. |
| client / server | two checks | Browser validation assists input but can be bypassed. The server must validate data and enforce its own business rules. |
Implication for the record
The postal code 00123 is an example string, not a verified address. Do not apply one national format to every country. Automated attribute checks need keyboard and assistive-technology testing, including failure and recovery states.
Primary documentation
- W3C WAI · Labelling controls
- W3C WAI · User notifications
- WHATWG · input types and attributes
- WHATWG · inputmode
- WHATWG · Client-side validation security
- W3C · WCAG 3.3.3
Documentation consulted on .
DOCUMENTED REFERENCE
Text contrast: compare the ratio before rounding
Different colours can still be difficult to distinguish. WCAG 2.2 compares their relative luminances after linearising the sRGB components. This tool calculates that ratio for two opaque colours; it does not sample pixels from a photograph.
| Reference | Value or form | What it identifies |
|---|---|---|
| ratio | (Lmax + 0.05) / (Lmin + 0.05) | The lighter luminance is the numerator. Swapping text and background therefore leaves the ratio unchanged. |
| WCAG 1.4.3 · AA | 4.5:1 | The AA threshold for ordinary text is 4.5:1 where criterion 1.4.3 applies. |
| WCAG 1.4.3 · AA · large | 3:1 | The AA threshold for large text is 3:1. The definition includes 18 point text, or 14 point bold, with qualifications concerning fonts. |
| WCAG 1.4.6 · AAA | 7:1 / 4.5:1 | Enhanced criterion 1.4.6 sets 7:1 for ordinary text and 4.5:1 for large text within its scope. |
| 4.499:1 | < 4.5:1 | A calculated ratio below 4.5 does not meet the threshold just because the rounded display says 4.50. Make the comparison before rounding. |
Calculate sRGB contrast
Two opaque #RRGGBB codes. The displayed ratio is rounded to four decimals; thresholds use the unrounded value.
Two valid colours: thresholds compared.
- Ratio
- 21.0000:1
- AA · ordinary text · 4.5:1
- Threshold met
- AA · large text · 3:1
- Threshold met
- AAA · ordinary text · 7:1
- Threshold met
- AAA · large text · 4.5:1
- Threshold met
s = component / 255 linear = s ≤ 0.04045 ? s / 12.92 : ((s + 0.055) / 1.055)^2.4 L = 0.2126 × R + 0.7152 × G + 0.0722 × B ratio = (max(L1, L2) + 0.05) / (min(L1, L2) + 0.05)
Implication for the record
The calculation accepts only opaque sRGB #RRGGBB colours, without transparency, gradients, background images or other colour spaces. It tests neither criterion exceptions nor every colour pair on the site nor full WCAG conformance. For text over a photograph, examine the actual areas behind the letters and the different crops.
Primary documentation
Documentation consulted on .
DEEPER READING / PRACTICE
Examine obstacles in a user journey
A user can read a page but does not reach its main action. The examination should focus on navigation, understanding and interaction, in several conditions of use.
Updated on .
Priority checks
Browse the items on the keyboard, check the titles and observe validation messages. Control the visibility of the focus, order of reading and access to the necessary information.
Interpretation pitfalls
A automatic control does not cover the entire experience. A visually clear interface may remain difficult to use with a keyboard or support technology.
Working record to retain
A report of obstacles associates path, condition of use, blocked step and proof. The correction must be tested in the condition that has allowed to identify the problem.