The short answer
Start accessibility work with the task that matters: can a person understand the offer, reach the form, correct mistakes and receive confirmation using different ways of interacting? Combine a keyboard walkthrough, content and form review, zoom and reflow checks, automated diagnostics and accountable retesting. This is practical triage, not a guarantee of WCAG conformance or legal advice.
- Test a complete customer task rather than isolated pages.
- Visible, unobscured focus and recoverable form errors are commercial essentials.
- Automated scans find some issues but cannot establish complete conformance.
- Record impact, owner, evidence and retest status for every finding.
On this page
Define the journey before checking components
Accessibility is easier to act on when the review follows a real customer outcome. Choose a critical journey such as understanding a service, opening navigation, reaching a quotation form, correcting an error and submitting it. Include consent layers and other overlays because they can interrupt the path.
W3C describes its Easy Checks as a first review only. A page may appear to pass and still contain significant barriers. Use this checklist to expose priorities and create acceptance evidence, not to certify a website or make a legal conclusion.
Write down the start, successful end and blockers before testing. A fictional Swiss consultancy might define success as selecting advisory services, reading the engagement scope, submitting a callback request and receiving a clear confirmation.
- Choose one high-value task and one information-only task.
- Include navigation, overlays, forms, errors and confirmation.
- Test representative mobile and desktop templates.
- Separate observed barriers from assumptions.
| Journey step | Customer needs | Failure that blocks progress | Evidence |
|---|---|---|---|
| Understand service | Clear heading and readable explanation | Ambiguous structure or missing content | Page review |
| Reach enquiry | Predictable navigation and link purpose | Keyboard-inaccessible menu | Keyboard recording |
| Submit details | Labels, instructions and recoverable errors | Unlabelled field or lost input | Form test |
| Confirm outcome | Clear status and next step | Silent failure or focus left behind | Receipt and focus check |
Run a 15-minute keyboard walkthrough
Put the mouse aside. Use Tab and Shift+Tab to move, Enter or Space to activate controls, and Escape where a dialog or menu should close. At every step, confirm where focus is, whether its order makes sense and whether the focused control can be seen.
A keyboard trap is a serious blocker: focus enters a component but cannot leave through expected keys. Also watch for controls skipped entirely, duplicate stops, focus jumping into hidden content and custom widgets that do not respond like their native equivalents.
Repeat the walkthrough after opening navigation, validation errors and consent controls. Dynamic states often behave differently from the initial page.
- Start at the browser address bar and reach main content.
- Open and close every control on the journey.
- Complete the form and intentionally trigger errors.
- Confirm focus moves to useful feedback after submission.
| Step | Focus visible | Order logical | Control works | Result |
|---|---|---|---|---|
| Dismiss consent | Yes or no | First relevant action | Enter and Escape | Pass, fix or investigate |
| Open navigation | Yes or no | Trigger then menu | Enter, arrows if designed, Escape | Pass, fix or investigate |
| Correct email error | Yes or no | Error then field | Tab and typing | Pass, fix or investigate |
| Submit enquiry | Yes or no | Button then status | Enter | Pass, fix or investigate |
Check focus against sticky and layered content
WCAG 2.2 includes a Level AA criterion requiring that a component receiving keyboard focus is not entirely hidden by author-created content. Sticky headers, cookie banners, chat launchers and bottom action bars are common sources of obstruction.
Scroll through the page by keyboard and inspect focus near every fixed element. Test at narrow widths and increased zoom, where a modest banner can occupy much of the viewport. Closing an overlay should return focus to the control that opened it unless the interaction has a better documented destination.
Do not solve obstruction by removing visible focus. Adjust offsets, layout, stacking and scroll behavior so the user can both locate and operate the control.
- Test fixed headers and bottom bars at multiple viewport sizes.
- Open stacked overlays in realistic combinations.
- Confirm dialog focus is contained while open and restored on close.
- Check anchor targets are not hidden beneath headers.
Review headings, links and image alternatives
A meaningful page title and heading hierarchy help people understand location and structure. Review the outline without relying on visual size. Headings should describe the following content, while ordinary emphasis should remain ordinary text.
Link text should make sense in context. Repeated links called Learn more create avoidable ambiguity when they point to different services. Name the destination or action. Images need alternatives that convey their purpose; decorative images should not create noise.
Contrast and colour checks need real states, including hover, focus, disabled controls, errors and text placed over imagery. Avoid using colour alone to communicate status.
- Check one clear page title and descriptive main heading.
- Read links out of surrounding prose.
- Match alternative text to image purpose.
- Inspect normal, hover, focus, error and disabled states.
Test forms, errors and recovery
A form should identify each field, explain unusual formats and preserve useful input when something goes wrong. Placeholder text is not a durable label. Required status and error messages should remain understandable without colour or position alone.
Submit empty, malformed and realistic values. Confirm the error identifies the problem and how to fix it, then check where keyboard and screen-reader focus goes. Simulate a network or delivery failure as well as validation failure. The visitor should not lose a carefully written message.
Success deserves the same care. State what was accepted and what happens next without claiming guaranteed inbox delivery or a response time the business cannot meet.
- Associate visible labels with controls.
- Keep instructions available while typing.
- Describe errors specifically and retain valid values.
- Test failure and success in the production delivery path.
| Test | Expected behavior | Block launch when |
|---|---|---|
| Missing required value | Field identified with correction guidance | User cannot locate or understand error |
| Invalid email | Format problem explained without clearing other fields | Form loops or discards content |
| Delivery failure | Honest message and retained input | Interface reports false success |
| Accepted submission | Status receives focus and next step is clear | No confirmation or inaccessible status |
Zoom, reflow and visual states need human review
Increase browser zoom and test narrow windows. Content should remain readable and operable without text colliding, controls disappearing or horizontal scrolling becoming necessary for ordinary prose. Data tables may need a labelled, keyboard-accessible scroll region.
Do not disable user scaling. Test long translated labels, large error messages and browser text settings because production content often breaks layouts that looked stable with short design copy.
Check orientation and virtual keyboard behavior on a real mobile device. A focused field should remain visible and the submit action should not be covered.
- Test enlarged text and narrow reflow.
- Look for clipping, overlap and hidden actions.
- Inspect tables and other intentional two-dimensional content separately.
- Repeat with realistic translated strings.
Use automation as evidence, not a verdict
Automated tools are useful for repeatable detection of issues such as missing labels, invalid attributes and some contrast failures. They cannot judge whether alternative text is meaningful, heading labels are helpful, focus order follows the task or an error is understandable.
Run automation across representative templates and interaction states, then combine results with keyboard, zoom, content and assistive-technology review. Where proportionate, include people with disabilities in research and testing.
A high automated score is not proof of conformance. Record the tool, version, URL, state and date so a later scan can reproduce the finding.
- Scan representative templates, not only the homepage.
- Open menus, dialogs and errors before scanning those states.
- Deduplicate component-level findings.
- Retest manually after a fix.
Turn findings into owned acceptance criteria
An issue list becomes useful when it identifies affected users, the blocked task, the component owner and evidence required to close it. Prioritize barriers that prevent navigation, understanding, input or confirmation before cosmetic imperfections.
Write acceptance criteria in observable terms. For example: At 200 percent zoom, the contact journey can be completed without content overlap; or, after an invalid submission, focus reaches the error summary and every error links to its field. Avoid vague requirements such as make the site accessible.
Retest the original journey and related components. Shared navigation or form changes may fix several pages, but they may also create regressions elsewhere.
- Record severity, task impact, component and owner.
- Attach reproduction steps and expected behavior.
- Require retest evidence before closure.
- Keep unresolved blockers visible in launch signoff.
YOUR QUESTIONS, ANSWERED
Frequently asked questions
Does passing this checklist prove WCAG conformance?
No. It is a focused first review. W3C states that pages can appear to pass easy checks and still have significant barriers. Comprehensive evaluation requires broader testing.
Can an automated accessibility score replace manual testing?
No. Automation can find some technical patterns but cannot reliably judge meaning, task flow, focus order or understandable recovery.
Which journey should a business test first?
Start with the task most important to customers and revenue, such as finding a service and completing an enquiry. Include errors and confirmation.
Is WCAG 2.2 AA mandatory for every Swiss business?
This guide makes no legal conclusion. WCAG is a technical standard. Obtain advice for the specific business, service and jurisdictions involved.
Can an accessibility overlay make the website compliant?
No tool or overlay can establish complete conformance by itself. Fix barriers in content, design and code, then test the actual journey.
CHECK THE DETAIL
