Estimated reading time : 6 min · Published
Choose representative pages and tasks
Start with the home page, a long article, a filtered listing, a form and an error page. Include mobile layouts and published languages. For each journey, record its starting point, intended action and visible confirmation of success.
Keep the URL, viewport, browser and date with each finding. A screenshot alone cannot explain a keyboard trap or feedback announced at the wrong time.
- Reach information from the menu.
- Find a result with a filter.
- Submit and correct a form.
Navigate without a mouse
Reload the page and use Tab, Shift+Tab, Enter, Space and arrow keys as appropriate. Focus should remain visible and move in a logical order. Open menus, change filters, reach links after cards and close dialogs without becoming trapped.
Check skip links and in-page anchors as well. After a jump, reading should continue from the intended section. The W3C preliminary checks are a useful start, not a full audit.
Read the page in other ways
Increase text size and browser zoom to 200%, then test a phone-sized viewport. Essential content and controls should remain available without forced horizontal scrolling. Measure contrast for text, focus indicators and important messages with an appropriate tool.
Use a screen reader to scan headings and links. Headings should describe sections, links should make sense outside their paragraph and informative images need useful alternatives. Decorative images can have an empty alt attribute.
Compare two colours
Enter two opaque hexadecimal colours, for example #285B86. The calculation stays on this page.
Swapping two opaque colours preserves their ratio. Still check their actual roles and every component state.
Large text is at least 18 points (24 CSS pixels), or 14 points bold (about 18.7 CSS pixels). This result compares only two opaque colours: review background images, transparency, focus states and components separately. It is not a complete accessibility assessment.
W3C · WCAG 2.2 · 1.4.3 · WCAG 2.2 · 1.4.11 · WCAG 2.2 · sRGB ·
Test errors and dynamic changes
Submit an empty form and then an invalid address. Feedback should identify the field to fix, stay associated with it and preserve valid answers. After submission, success or failure must be perceivable without relying on colour alone.
For search and filters, check the result count, empty state and announcement of changes to a screen reader. An interface can work with a mouse while its updates remain hard to understand in another mode.
- Exact step that fails.
- Effect on the visitor’s task.
- Expected fix and repeat check.
Prioritise and seek a full evaluation
Fix barriers that prevent reading, navigation, comparison or contact first. Repeat the same journey after each correction. Automated tools can find some issues, but cannot judge whether an alternative text or a journey makes sense.
These preliminary checks do not establish compliance. If an accessibility standard or statement applies to the site, arrange an appropriate evaluation against the relevant standard, such as WCAG or the French RGAA. The prelaunch checklist helps include these checks in the release review.
Check state changes, not only the initial page
Prepare a journey opening navigation, entering a dialog and receiving action confirmation. Record focus placement, announcements and recovery without data loss. An initial screenshot cannot reveal invisible links in a closed panel or a message that vanishes too soon.
Repeat with long labels and a narrow window. Include waiting and failure: a component working in ideal conditions may block recovery when a remote service stops responding.
Design and test a modal dialog · Design mobile navigation and submenus · Write and announce interface status messages
Test a keyboard journey
Proposed case: a link receives focus but a fixed layer hides it. The control exists in code, yet the person cannot tell where they act.
Complete a task with the keyboard, including opening and closing panels. Record order, visibility and focus return; a homepage pass does not cover every state.
- Choose a complete task
- Observe focus at each step
- Document the blocking state
- Test return from a menu
Test website navigation and menus
Check cognitive effort across the whole process
Test beyond the initial form: login, recovery, review and correction can each introduce a barrier. Distinguish repeated input within a single activity from information requested in a later session; WCAG 3.3.7 does not impose storage across sessions.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Situation | Expected result | Check boundary |
|---|---|---|
| Repeated data | Look for automatic population or an available selection. | Browser autocomplete alone does not demonstrate compliance. |
| Password or code | Try filling through a manager and pasting a complete code. | Do not force manual transcription across separate boxes. |
| Correction | Change one answer and repeat the review step. | Record the observed result and remaining obstacle. |
- W3C WAI · WCAG 3.3.7
Read the criterion’s scope and exceptions; this scenario is a practical interpretation, not a compliance certificate.
Turn a warning into a journey check
- Open the relevant state
- Read the finding
- Reproduce the task
- Verify the correction
An automated error list is a starting point. For each finding, add the blocked task, interface state and steps to reproduce it. WAVE can identify a missing attribute; judging alternative text or the ease of a task requires human assessment.
Example check: an informative image has alternative text, but it describes another product. The attribute’s presence is not enough. Compare the meaning, correct the text and read the page without images; complete the applicable manual checks.
Reference documents
- W3C preliminary checks · Source consulted
- W3C WAI · Dialog (Modal) Pattern · Source consulted
- W3C WAI · WCAG-EM
- W3C WAI · Selecting Evaluation Tools · Source consulted
- RGAA
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| WCAG 2.2 · 1.4.3 | 4.5:1 / 3:1 | Normal / large text (18 pt or 14 pt bold); criterion exceptions apply. |
| WCAG 2.2 · 2.5.8 | 24 × 24 CSS px | A smaller target can satisfy the criterion through spacing; other exceptions apply. |
| WCAG 2.2 · 1.4.10 | 320 CSS px | Vertical content without two-dimensional scrolling; exceptions cover inherently two-dimensional content. |
| WCAG 2.2 · 1.4.4 | 200 % | Enlarged text retains content and functionality; exceptions cover captions and images of text. |
| WCAG 2.2 · 3.3.7 | A · same process | Within one process, previously supplied information must be auto-populated or available to select, subject to the criterion’s exceptions. Browser autocomplete alone is insufficient; the site must offer the information already received or avoid requesting it again. |
| WCAG 2.2 · 3.3.8 | AA · authentication | An authentication step requiring recall or transcription needs assistance or an alternative route, subject to the criterion’s exceptions. Test password managers and code pasting; an audio alternative requiring transcription does not by itself remove the cognitive burden. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.