What makes a website easier to use and more accessible

This guide explains who is shut out by common design choices, what WCAG 2.2 asks for in plain terms, the checks you can run yourself, what automated tools cannot find, and where the law comes into it. It is not legal advice.

Say you run a dental clinic, and your booking page looks smart. It uses light grey text on a pale background, a calendar that can only be operated by clicking a day with a mouse, form fields whose labels vanish when you start typing, and your price list is a photograph of a printed sheet with no description.

Each of those shuts somebody out:

• A patient with low vision cannot read the grey text.
• A patient who uses the keyboard alone, perhaps because of a tremor, cannot select a date.
• A patient using a screen reader hears “edit text, edit text, edit text” with no idea which field is which, and nothing at all for the price list.
• A patient in a bright car park on a phone cannot read the grey text either.

None of these is exotic. The booking page works for the designer and fails for everyone who does not share the designer’s eyes, hands and screen.

The World Health Organization estimates that 1.3 billion people, 16% of the world’s population or 1 in 6, experience significant disability (fact sheet dated 7 March 2023). That is a count of people with disabilities, not of your potential customers, but it shows the scale of what a design choice can exclude.

The W3C Web Accessibility Initiative (WAI) goes wider than permanent disability. Accessible design also helps older people whose abilities change with age, people using small screens, people with temporary limits such as a broken arm or lost glasses, people in situations such as bright sunlight or no audio, and people on slow connections. In its words, accessible design

“improves overall user experience and satisfaction, especially in a variety of situations, across different devices, and for older users.”

That is the practical case for an owner: the changes that serve a screen reader user, such as clear labels, readable contrast, and text you can resize, also serve the customer on a phone outdoors.

WCAG is a technical standard with testable criteria. It is organized around four principles, which WAI describes this way:

• Perceivable. Information and interface parts must be presentable in ways people can perceive (for example, text alternatives for images, captions for video, enough contrast).
• Operable. Interface parts and navigation must be operable (for example, everything works from a keyboard, with a visible focus indicator).
• Understandable. Content and operation must be comprehensible (for example, labels and clear error messages).
• Robust. Content must work with current and future assistive technologies.

Each criterion sits at level A, AA or AAA, from least to most demanding. Which level to aim for is, in the W3C’s words, “fundamentally a policy decision”, so ask what a supplier means when they say “accessible”.

Version 2.2 was published on 5 October 2023. Content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, because later versions add criteria rather than changing existing ones, and the W3C encourages people to use the latest version. The studio’s own standard is WCAG 2.2 AA: we build and test against it.

Six of the new criteria are the ones owners are most likely to notice:

The older criteria still matter more for most sites. The ones that cause the most visible problems are text contrast, text alternatives for images, keyboard operation, visible focus and form labels.

WAI publishes a set of “easy checks” and is clear about what they are worth:

“These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have significant accessibility barriers.”

They give you a first reading, not a verdict.

Try these on your most important page, such as your contact page or checkout:

1. Read the page title in the browser tab. It should say what the page is, and differ from page to page.
2. Check the images. Informative images need a text description, and decorative ones should have an empty description so screen readers skip them. WCAG 1.1.1 requires a text alternative serving “the equivalent purpose” for non-text content. Our guide to website images that help customers understand your offer covers writing it.
3. Look at the headings. They should form an outline of the page, not be chosen for their size.
4. Check text contrast. WCAG 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18 point, or 14 point bold). Free contrast checkers take two colors and tell you the ratio. Logos are exempt; ordinary body text on a brand-colored background is not.
5. Zoom to 200%. WCAG 1.4.4 requires that text can be resized up to 200 percent without loss of content or functionality. Nothing should overlap, vanish or need sideways scrolling.
6. Put the mouse down and use Tab. Can you reach every link, button and form field, in a sensible order? Can you always see where you are (WCAG 2.4.7)? Can you operate everything with the keyboard (2.1.1)?
7. Check each form field has a visible label. Labels should stay visible while typing, and error messages should say what to fix.
8. Check video and audio. Spoken content needs captions or a transcript.
9. Look for moving or flashing content. Anything that moves for more than five seconds needs a way to pause it.
10. Try it on a phone. Large, well-spaced targets and readable text are covered in why mobile design needs its own decisions.

Free tools such as Lighthouse (built into Chrome) will catch missing image descriptions, low-contrast text and missing form labels. They cannot catch everything, and the people who make them say so. Lighthouse’s documentation notes that some checks, such as whether interactive controls are keyboard-focusable and whether the page has a logical tab order, need manual testing. WAI states that “some accessibility checks just cannot be automated and require manual intervention” and that in some cases tools can give inaccurate results.

A script can tell you an image has a description. It cannot tell you the description is useful. It cannot tell you that the focus order makes sense, that a label means what it should, or that a date picker is usable with a screen reader. A passing automated score is a floor. It does not show the site is accessible, and it is not a certificate.

It depends on where you operate, and we cannot tell you which law applies to you. WAI says “web accessibility is required by law in many situations”, and keeps a list of government policies for 45 countries and regions. The list differs by country, covers the public sector, the private sector or both, and may cite WCAG 2.0, 2.1 or 2.2, or no particular version.

WAI’s own caveat is clear:

“W3C does not make regulations. The information on this page is not legal advice. Please consult legal authorities for the appropriate jurisdiction.”

So the honest position is this. If you sell or operate in a place with accessibility rules, ask a lawyer in that jurisdiction what applies to your business, and then use WCAG as the technical checklist.

This article does not tell you whether you are compliant, and no checklist, script or studio can responsibly promise legal compliance on your behalf.

The scope depends on how the site was built. Some fixes are quick edits: colors, labels, image descriptions, heading order. Others need changes to templates, such as a menu that only works with a mouse or a form widget that cannot be reached by keyboard. In a redesign or new build, the criteria can be built in and tested before launch. That is how we work: accessibility is one of the nine lenses every site is reviewed through before launch, and the standard is WCAG 2.2 AA.

It is also worth saying what accessibility work does not do. It does not make a poorly written page persuasive. It does not replace testing with real users who rely on assistive technology, which is the strongest evidence you can get. And because content changes, a site that conformed at launch can drift when new pages and images are added without the same care, so someone has to own the checks after launch. Our guide to website maintenance covers what that routine involves.

If you are planning a new site or a redesign, put the accessibility standard in the scope in writing, so “accessible” means WCAG 2.2 AA and not a general intention. Our website design and development work is built and tested against that standard, and the checks above show you what to ask for. To see how phone use overlaps with accessibility, read why mobile design needs its own decisions. When you want to talk it through, you can discuss your project with us.

W3C, “Web Content Accessibility Guidelines (WCAG) 2.2”: https://www.w3.org/TR/WCAG22/

W3C Web Accessibility Initiative, “WCAG 2 Overview”: https://www.w3.org/WAI/standards-guidelines/wcag/

W3C Web Accessibility Initiative, “Introduction to Web Accessibility”: https://www.w3.org/WAI/fundamentals/accessibility-intro/

W3C Web Accessibility Initiative, “Web Accessibility Laws and Policies”: https://www.w3.org/WAI/policies/

W3C, “Understanding Conformance” (WCAG 2.2): https://www.w3.org/WAI/WCAG22/Understanding/conformance.html

W3C Web Accessibility Initiative, “Easy Checks: A First Review of Web Accessibility”: https://www.w3.org/WAI/test-evaluate/preliminary/

W3C Web Accessibility Initiative, “Web Accessibility Evaluation Tools List”: https://www.w3.org/WAI/test-evaluate/tools/

W3C Web Accessibility Initiative, “Understanding Success Criterion 1.4.3: Contrast (Minimum)”: https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html

W3C Web Accessibility Initiative, “Understanding Success Criterion 2.5.8: Target Size (Minimum)”: https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

W3C Web Accessibility Initiative, “Images Tutorial”: https://www.w3.org/WAI/tutorials/images/

World Health Organization, “Disability” fact sheet, 7 March 2023: https://www.who.int/news-room/fact-sheets/detail/disability-and-health

Chrome for Developers, “Lighthouse overview”: https://developer.chrome.com/docs/lighthouse/overview