WCAG 2.2: 8 Practical Checks for Accessible Business Websites

WCAG 2.2 is a set of web accessibility guidelines that helps teams make content usable for more people, including people with disabilities. For a business website, the practical goal is clear: visitors should be able to understand the offer, request a service, and complete important tasks without avoidable barriers.

A useful review looks beyond the home page. It follows complete journeys, such as choosing a service, filling a quote form, and correcting an error. This article explains eight checks that turn the guidelines into practical design, testing, and maintenance work.

Understand the standard before building a checklist

The W3C WCAG 2.2 Recommendation defines testable success criteria at Levels A, AA, and AAA. A conformance target includes a level and a scope. Passing a few automated checks does not establish conformance for an entire website.

The standard covers more than visual design. It addresses how people perceive content, operate controls, understand interactions, and use assistive technology. W3C’s Understanding WCAG 2.2 documents explain the criteria and their intent in more detail.

Use the exact criterion when making a formal assessment. The checks below are a planning approach, not a replacement for the full standard. They help a business team ask better questions and collect useful evidence.

1. Define the journeys and states in scope

Start with the work a visitor needs to complete. A roofing website may include reading service details, requesting an estimate, uploading photos, and receiving confirmation. Each step can introduce a different barrier.

List the pages and interface states involved. An open menu, validation message, cookie notice, and date picker may not appear in a simple page inventory. Yet users still need to operate them.

Next, include the handoffs. If the quote form sends visitors to an external booking tool, review that part of the experience too. A usable landing page cannot compensate for a booking process that some customers cannot finish.

Record ownership for each part. Marketing may own page content, while a vendor controls the booking widget. Clear ownership makes it easier to fix findings and decide which supplier questions need an answer before launch.

2. Follow the journey with a keyboard

Try important tasks without a mouse. Move through links, menus, fields, dialogs, and buttons. Check that focus follows a sensible order and that the user can tell which control currently has it.

For example, open a request-a-quote dialog and complete its fields. Then close it and check where focus goes. A user should not lose their place or become trapped inside an element with no usable exit.

Sticky banners deserve special attention. A fixed header or chat panel can cover the control a person is trying to use. Review focus visibility and obstruction against the relevant WCAG 2.2 accessibility guidelines, including their exceptions and level requirements.

Repeat the check after triggering errors. A form can work on the first pass but become difficult to navigate when it inserts a summary or moves fields. Test the state users actually face after a mistake.

3. Make forms explain what they need

Every field should communicate its purpose. A visible label helps users understand what to enter, and the underlying markup should connect that label to the control. Placeholder text alone is a weak substitute because it disappears during entry.

State required formats before users submit. If a photo upload accepts only certain file types or sizes, explain those limits near the control. If an address field needs a unit number, make that requirement clear.

When validation fails, identify the field and explain how to fix it. Avoid relying only on a red border. A message such as Enter a phone number with an area code provides more help than Invalid input.

Also preserve valid work. If a customer misses one field, do not clear the rest of the quote request. Review repeated entry within the same process, especially where the system already holds information the user has supplied.

4. Review structure and meaning with assistive technology

Headings should describe the content and form a useful structure. A visitor who navigates by headings should find services, prices, process details, and contact options in a logical order. Do not use heading levels merely to change font size.

Check names and roles for interactive controls. An icon-only button needs a meaningful accessible name. A button that opens a menu should communicate its state through suitable markup, rather than relying only on the icon changing shape.

For a booking page, review the date picker and availability messages. A screen reader user needs to know which date they chose and whether a slot is available. Visual highlights alone do not communicate the full state.

Manual testing takes skill. Ask an experienced reviewer to test representative journeys with suitable browser and assistive technology combinations. Anomoz’s guide to software testing services explains how specialized checks can fit into a wider release plan.

5. Check content at different sizes and presentations

Increase text size and zoom, then review whether content remains readable and usable. Watch for cut-off labels, overlapping controls, and panels that hide important information. A layout that looks neat at one width may fail when a visitor changes their display settings.

Use sufficient contrast for text and relevant interface details according to the applicable criteria. Also check hover, focus, disabled, and error states. A control may look clear in its normal state but lose contrast after interaction.

Images need appropriate text alternatives. Describe meaningful content, while allowing assistive technology to ignore purely decorative images. A photo of a completed roof may need different treatment from a logo or a diagram explaining a service process.

For video and audio, plan the required alternatives early. Adding accurate captions or other support after the content campaign launches often creates avoidable rework. Include those tasks in the content brief and acceptance criteria.

6. Make touch and pointer actions forgiving

Small controls create practical problems on phones and for people with limited precision. Review target size and spacing against the relevant criteria, including exceptions. Do not assume that a control is adequate simply because one team member can tap it.

Consider a service-area map with many small markers. Provide another way to choose a location, such as a list or search field. That can help people who cannot perform precise pointer actions.

Similarly, a drag-and-drop task board should offer an alternative when the applicable criterion requires one. A menu that moves a job to another status can make the same action available without dragging.

Test gestures in context. A floating call button might cover a form’s Next button on a small screen. Review the whole layout with notices, keyboards, and expanded menus visible, rather than judging each component in isolation.

7. Review sign-in and help as part of the journey

Customers may need to sign in before viewing quotes or invoices. Check whether the authentication flow introduces avoidable barriers. Review password manager support, copy-and-paste behavior, and the relevant accessible authentication requirements.

Do not make a memory puzzle the only route without assessing alternatives and exceptions. A technically secure sign-in can still prevent legitimate customers from completing their task. Security and accessibility teams should review the same flow together.

Help should remain easy to find. If a site provides contact or assistance mechanisms across pages, check their placement and consistency where the criteria apply. A customer should not have to relearn where support lives at every step.

Also test expired sessions and recovery. If a user spends time completing a detailed service request, explain a timeout clearly and handle their entered information appropriately. An error at the final step can undo an otherwise usable experience.

8. Keep evidence and prevent repeated defects

For each finding, record the page or state, affected task, relevant criterion, steps to repeat, and observed behavior. Add a clear expected result. This gives the developer something concrete to fix and the reviewer something concrete to retest.

Automated scans help catch some issues repeatedly. However, they cannot judge every question about meaning, navigation, or task completion. Combine them with manual review and, where possible, feedback from people with disabilities.

Fix shared components at their source. If every page uses the same inaccessible menu, changing twenty individual pages is less useful than repairing the menu component. Then retest it in several contexts to catch layout-specific effects.

Track accessibility findings with the same discipline as other defects. The approach in Anomoz’s article on release testing evidence can help preserve scope, retest results, and open exceptions.

A practical review of a quote request

Take one quote form from entry to confirmation. First, complete it with a keyboard. Check labels, order, focus, and the ability to use every control. Then submit it with a missing required field and review the error path.

Next, repeat the task with text enlarged and at a narrow screen width. Open the date picker and upload control. Confirm that the layout does not hide instructions or the action needed to continue.

Finally, review the same flow with assistive technology and check the confirmation state. The user should know the request succeeded and what happens next. If the app sends a reference by email, make sure the on-screen result also provides the information needed to understand completion.

Use the findings to improve the shared form components. Then apply the same tests to booking changes, contact forms, and account registration. This builds reusable evidence without assuming that one successful page proves the whole site works.

Keep legal scope separate from the technical target

WCAG is a technical standard. Legal duties depend on factors such as the organization, jurisdiction, service, and applicable rule. Do not treat a WCAG version or an automated score as a universal legal certificate.

Agree on the technical target with the people responsible for the project, and obtain legal guidance where needed. Document what the assessment covered and what remains outside it. Accurate scope makes the result more useful to everyone involved.

Include content editors in prevention

Developers cannot prevent every future content problem. Give editors simple guidance for headings, link text, image alternatives, and media. Show examples drawn from the actual website so the rules feel concrete.

For example, a service page link should explain its destination instead of repeating a vague phrase across several cards. A new image should have a purpose before someone writes its alternative text. Add a short review step when publishing new pages, and keep more detailed testing for changes to shared templates or interactive components.

Review complete tasks, then maintain the result

Choose a meaningful customer journey and check its content, controls, errors, and confirmation. Use WCAG 2.2 as the detailed reference, and keep evidence for the actual states reviewed. Accessibility becomes more sustainable when it forms part of ordinary content and software work.