A local business website is accessible when people can discover the business, understand its services, and complete essential tasks using different browsers, devices, input methods, and assistive technologies. An automated scan can find some coding patterns, but it cannot prove that a person can book, call, get directions, read a policy, or recover from an error. Start with the real customer journey and combine automated findings with manual task tests.
Map essential pages and tasks
List the home page, service pages, location and hours, contact, booking, quote, checkout, directions, privacy, and policy pages actually used by customers. For each, define a concrete task and success evidence. Examples include finding today's hours, activating a telephone link, requesting an appointment, submitting a form, reading a confirmation, and cancelling or changing a request.
Test without an administrator session and use invented personal data where possible. Include desktop and mobile layouts, portrait and landscape, slow or interrupted connections, and a representative browser set. Record the URL, device, assistive technology, expected outcome, observed outcome, and evidence. A page passing an audit while its booking widget cannot be operated is not an accessible result.
Run a structured first review
W3C's Easy Checks covers page titles, headings, alternative text, contrast, zoom, keyboard access, labels, instructions, and errors. Use it as an organized first pass, while preserving its limitation: preliminary checks do not establish complete WCAG conformance.
Confirm that every page has a descriptive title and a logical heading structure. Images that convey information need appropriate alternatives; decorative images should not create noise. Text and controls should remain understandable at increased zoom and text size without hiding content or forcing two-dimensional scrolling for ordinary reading. Check contrast in normal, hover, focus, error, and disabled states.
Test keyboard and focus behavior
Complete every essential task with a keyboard only. Focus should be visible, move in a logical order, reach menus and dialogs, and never become trapped. Skip links should bypass repeated navigation where needed. Buttons, links, disclosures, date pickers, maps, chat widgets, and cookie controls need keyboard operation that matches their purpose.
Watch what happens when a modal opens and closes. Focus should enter intentionally, remain within a true modal while it is active, and return to a sensible control afterward. Sticky headers and overlays must not conceal the focused item. Do not interpret a large target or colorful outline as success unless the actual action works.
Inspect forms, labels, and errors
The W3C Forms Tutorial recommends associated labels, grouped controls, clear instructions, validation, and useful feedback. Inspect contact, quote, newsletter, booking, account, and payment forms. Visible labels should remain available after typing, required fields and formats should be explained, and related choices should be grouped meaningfully.
Submit blank, malformed, and incomplete entries. W3C's Error Identification guidance says automatically detected errors should identify the affected item and describe the problem in text. Error color can help, but it cannot be the only signal. Confirm that screen readers announce the error, focus reaches a useful location, valid entries remain populated, and correction leads to a verified submission.
Review content and third-party tools
Read service descriptions, hours, pricing, eligibility, location, and policies for clarity. Expand abbreviations, use plain links that describe their destination, and avoid instructions based only on color or position. A PDF menu, image-only flyer, or embedded social post needs an accessible equivalent when it carries essential information.
Test hosted booking, payment, map, review, chat, and consent tools as part of the same journey. The business remains responsible for the customer experience even when a provider renders the widget. Record limitations and maintain an alternative route, such as a clearly labeled phone or email option, but do not use the alternative as an excuse to leave the primary task unusable.
Include assistive-technology and human testing
Use at least one current screen reader with the browsers it supports. Navigate by headings, landmarks, links, controls, and errors. Test speech input or voice-control naming where relevant, magnification, high contrast, reduced motion, and mobile screen-reader gestures. Verify that opening hours, address, prices, and form status are exposed in a meaningful reading order.
Invite people with relevant disabilities into usability testing when feasible, define the tasks, and compensate them fairly. Preserve findings without collecting unnecessary disability or personal data. Automated tools, expert review, and user testing answer different questions and are stronger together.
Keep an evidence-led remediation record
Prioritize failures that block contacting, booking, buying, locating, or understanding the business. For each issue, record the page, component, task impact, reproducible steps, expected behavior, fix owner, release, and retest evidence. Recheck shared templates and every instance of a third-party widget.
The final conclusion should name the tasks, pages, devices, browsers, and assistive technologies tested, the blockers fixed, and what remains untested. Accessibility is a maintained operating condition, not a one-time score or badge. Re-run the critical journey after design-system, plugin, content, or booking-provider changes.
Sources
- Easy Checks - A First Review of Web Accessibility — W3C Web Accessibility Initiative
- Forms Tutorial — World Wide Web Consortium Web Accessibility Initiative
- Understanding Success Criterion 3.3.1: Error Identification — W3C Web Accessibility Initiative