Do not treat one automated score as accessibility approval. Before launch, test representative pages with automated tools and real keyboard use, review focus order, headings, links, images, forms, contrast, reflow, motion and error recovery, test priority journeys with relevant assistive technology, record issues with owners and severity, and retest after fixes.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Choose representative pages and priority journeys
A pre-launch review should cover more than the homepage. Select a representative sample of templates and states: the main landing page, service pages, navigation, enquiry or checkout forms, search, account areas, error messages, modal dialogs and any page with video, animation or downloadable content. Include the mobile layout and the browsers and devices the audience is likely to use.
Map the journeys that matter to the business and to the visitor. A person should be able to understand the offer, move through the navigation, complete the primary form, recover from an error and receive a meaningful confirmation without relying on a mouse, perfect vision or a particular input method.
W3C recommends evaluating accessibility early and throughout development. The final review is therefore a release gate, not the first time accessibility is considered. Keep a list of known exceptions and confirm whether each one blocks a priority journey or creates a serious information barrier.
- Representative page templates and component states
- Priority customer and staff journeys
- Mobile, desktop and relevant browser coverage
- Error, empty, loading and confirmation states
- Known exceptions with owners and release decisions
Use automated tests as a starting point, not a verdict
Automated tools can quickly expose missing alternative text, invalid labels, some colour-contrast problems, document-language issues and structural errors. Run them on the selected pages and fix repeatable component-level failures at their source so the same defect is not corrected one page at a time.
A clean automated report does not prove that the site is accessible. W3C states that no tool alone can determine accessibility and that knowledgeable human evaluation is required. Automated checks cannot reliably decide whether alternative text communicates the right purpose, whether a heading structure makes sense or whether an error message helps someone recover.
Keep the output useful: record the page, component, rule, evidence, impact, owner and retest result. Avoid presenting a single score as a guarantee of conformance, because it can hide untested journeys and issues the tool cannot recognise.
- Run more than one appropriate automated check where practical
- Fix shared component problems at source
- Review false positives and untested criteria
- Record evidence and an accountable owner
- Retest the exact page and state after correction
Complete the site with a keyboard and visible focus
Start at the address bar and use Tab, Shift+Tab, Enter, Space, arrow keys and Escape to operate the site. Every interactive control should be reachable, usable and dismissible without a mouse. Watch for keyboard traps, menus that cannot be closed, carousels that steal focus and custom controls that look clickable but never receive focus.
Check that focus moves in an order that preserves meaning and matches the visible task. When a modal opens, focus should enter it appropriately; when it closes, focus should return to a sensible trigger. W3C's focus-order guidance emphasises that sequential navigation must preserve meaning and operability.
The current focus must also be easy to see. Do not remove the browser outline unless it is replaced with a stronger indicator that remains visible against each background. Test sticky headers, cookie banners and overlays so they do not hide the focused element.
- All actions reachable and operable by keyboard
- No keyboard traps or unexpected focus jumps
- Logical focus order through each priority journey
- Visible focus indicator on every interactive element
- Correct focus handling for menus, dialogs and validation
Review content, structure and forms like a user
Read the page by headings and links. Each page needs a descriptive title, one clear primary heading, a logical heading hierarchy and link text that makes sense outside its sentence. Images that communicate information need purposeful alternative text; decorative images should not add noise to the reading order.
Every form control needs a programmatic label and any required format or instruction should be available before the person makes an error. When validation fails, identify the field, explain the problem in plain language and preserve the person's work. Do not rely on colour alone to indicate required fields, status or failure.
Zoom and reflow should not destroy the task. Check the site at increased text size and narrow viewport widths, looking for clipped text, overlapping controls, horizontal scrolling in ordinary reading content and buttons that become impossible to reach. Test motion controls and respect reduced-motion preferences where animation is not essential.
- Descriptive page titles, headings and link text
- Purposeful alt text and quiet decorative imagery
- Labels, instructions and understandable error recovery
- Readable contrast without colour-only meaning
- Usable zoom, text spacing, reflow and reduced-motion behaviour
Test assistive technology on the journeys that matter
Use a screen reader on at least the priority journeys and listen to the actual names, roles, states and announcements exposed by the interface. Check navigation landmarks, headings, form labels, expanded and collapsed states, status messages and validation. Visual appearance cannot confirm what assistive technology receives.
Where the audience or risk justifies it, include people who use assistive technology in the evaluation. GOV.UK guidance recommends combining automated and manual testing, checking common assistive technologies and including disabled users. A delivery team can find technical failures; a person completing a real task can reveal friction that a checklist misses.
Document the assistive technology, browser, device, journey and result. The goal is not to claim that every possible combination was tested. It is to provide credible evidence for the combinations most relevant to the service and a plan for issues found after launch.
- Priority journeys with a relevant screen reader
- Names, roles, states and status announcements
- Landmarks, headings and form navigation
- Relevant speech, zoom or switch-input testing
- User evaluation where audience and risk require it
Make accessibility a release decision and an ongoing responsibility
Classify every open issue by user impact, affected journey and available workaround. A cosmetic inconsistency is not equivalent to an enquiry form that cannot be submitted with a keyboard. Give blocking and serious issues an owner and retest date, and record the person authorised to accept any residual risk.
Keep the evidence with the product: the page sample, automated reports, manual checklist, assistive-technology notes, fixed issues and known limitations. If formal conformance or a regulated accessibility statement is required, arrange an appropriately qualified audit rather than treating an internal checklist as certification.
Continue testing after launch. New content, plugins, campaign pages and component changes can reintroduce barriers. Digi Startup India can include accessibility requirements, manual review and testable acceptance criteria in a premium website delivery plan so accessibility remains part of design, engineering and content—not a last-minute score.
- Severity based on user and journey impact
- Named owner and retest evidence for every issue
- Formal audit where regulation or assurance requires it
- Known limitations communicated accurately
- Regression checks for future content and releases
Further reading
Frequently asked questions
Does a high Lighthouse accessibility score mean the website is accessible?+
No. It is useful evidence for the checks Lighthouse can automate, but it cannot judge every WCAG requirement or whether real tasks make sense with a keyboard or assistive technology. Combine automated results with manual and user-focused evaluation.
Should accessibility testing wait until the website is finished?+
No. Test components, content and journeys throughout design and development, then run a representative pre-launch review. Early testing makes shared problems easier to correct and leaves the launch review focused on integration and real tasks.
What should block a website launch?+
An issue should be treated seriously when it prevents or substantially disadvantages people completing an important journey, accessing essential information, understanding an error or controlling the interface. The release decision should consider user impact, scope, workaround and legal or contractual obligations.
Do we need a professional accessibility audit?+
It depends on the service, jurisdiction, contractual requirements and the assurance you need. Internal testing is essential but is not automatically a formal conformance audit. Use qualified independent review when regulation, procurement or risk requires stronger evidence.