Website Accessibility and WCAG: A Guide for Product Teams

Accessibility is often treated as a late-stage polish item, then discovered as a problem when a customer, a procurement team or a legal notice raises it. Building it in from the start is far cheaper than retrofitting, and it improves the product for everyone: better keyboard support, clearer forms and more readable text help all users, not only those with disabilities.

This guide explains what to ask for when you commission a website or app.

What WCAG is

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the most widely used technical standard for accessible web content. They are organised around four principles, often shortened to POUR:

• Perceivable: content can be seen or heard, for example through text alternatives and sufficient contrast.
• Operable: everything works with a keyboard and other input devices, with enough time and no seizure-triggering content.
• Understandable: text is readable, behaviour is predictable and forms help users avoid and fix mistakes.
• Robust: the code works with browsers and assistive technologies such as screen readers.

Conformance has three levels: A, AA and AAA. Most contracts, tenders and regulations target WCAG 2.1 or 2.2 level AA. Check which version and level apply to your market, since requirements vary by country and sector, and take legal advice where compliance is mandatory.

The issues that cause the most real-world problems

Area	What to get right
Colour contrast	Text should meet at least 4.5:1 against its background at level AA (3:1 for large text)
Keyboard access	Every link, button and form control reachable and usable without a mouse, with a visible focus indicator
Text alternatives	Meaningful images have descriptive alt text; decorative ones have empty alt
Forms	Visible labels linked to inputs, clear error messages, no reliance on colour alone
Headings and structure	One logical heading hierarchy and proper landmarks (header, nav, main, footer)
Media	Captions for video, transcripts for audio, no auto-playing sound
Zoom and reflow	Layout works when text is enlarged and on small screens

Build it into the development process

Start in design. Contrast, tap-target size, focus states and error states are cheapest to fix in a design file. Ask your UI/UX designers to include them in the component library.

Use semantic HTML first. A real <button> or <a> gives you keyboard behaviour and screen reader support for free. Custom components built from generic <div> elements need extra ARIA attributes and scripting, and often get them wrong. A useful rule: use ARIA to fill gaps, not to replace native elements.

Manage focus in dynamic interfaces. Modals, menus, single-page route changes and toast messages need deliberate focus handling so keyboard and screen reader users are not lost.

Make it part of “done”. Add accessibility criteria to your definition of done and to pull request reviews, not to a separate end-of-project audit.

How to test

No single tool catches everything. Automated scanners find only a portion of issues, so combine methods:

• Automated checks in the editor and the CI pipeline, to catch missing labels, contrast failures and invalid ARIA early.
• Keyboard-only testing: tab through every key journey and confirm that you can see where you are and complete the task.
• Screen reader checks with at least one common combination on desktop and one on mobile.
• Zoom and reflow checks at 200% zoom and on a narrow viewport.
• Manual review of content, such as link text, headings and error messages.

For high-stakes products, consider an independent audit and, where possible, testing with people who use assistive technology.

Working with an outsourced team

Accessibility is easy to lose when requirements are vague. To protect it:

• State the target in the contract or statement of work, for example “WCAG 2.2 AA for all user-facing pages”.
• Ask for accessible components in the shared design system.
• Require automated checks in the delivery pipeline.
• Agree how issues will be triaged and fixed, and who verifies them.
• Ask for an accessibility statement and a list of known gaps at launch.

Performance and accessibility often reinforce each other, so it is worth reading our Core Web Vitals guide alongside this one, and our small business website checklist covers other basics to confirm before launch.

If you want an accessible website or web app built, our web development services include semantic, standards-based front-end work, and our design team can help from the start. Contact us to discuss your requirements.