How to make your website accessible to people with disabilities: 12 checks based on WCAG 2.2

What does an accessible website mean?

An accessible website is one that as many people as possible can perceive, operate and understand, regardless of their sight, hearing, mobility or cognitive abilities. The WCAG guidelines (Web Content Accessibility Guidelines), developed by the W3C, group the requirements under four principles.

• Perceivable: information can be seen or heard – text has good contrast, images are described, videos have captions.
• Operable: every action can be performed with a keyboard, buttons are large enough, nothing disappears too quickly.
• Understandable: the text is clear, navigation is consistent, forms explain errors.
• Robust: the code is written so that browsers and assistive technologies, such as screen readers, interpret it correctly.

Accessibility helps not only blind or deaf people, but also older people and anyone reading on a phone in bright sunlight. For many online stores selling to consumers, it's also a legal obligation – we cover this in our article ‘The European Accessibility Act: does your website or online store have to comply?’.

1. Is the contrast between text and background sufficient?

The contrast between normal text and its background must be at least 4.5:1, and for large text (from 24 px, or from 18.7 px in bold) at least 3:1 (WCAG 1.4.3). Button and form field borders and important icons need a contrast of at least 3:1 against adjacent colours (1.4.11).

As the blue shades show, a bright brand colour often works for large headings, icons and borders, but not for small text – neither on a white background nor as white text on a button in that colour. For small text, a darker shade of the same colour is used. You can check contrast with the WebAIM Contrast Checker or your browser's developer tools.

2. Can the text be enlarged, and does it adapt to the screen?

WCAG doesn't specify which font or size to use, but it does require that text can be enlarged to 200% without loss of content (1.4.4), and that a page can be read on a 320 px-wide screen without horizontal scrolling (1.4.10). Rules about 12-point type or Times New Roman are meant for printed documents, not websites.

Another criterion (1.4.12) says text must not overflow or get cut off if the user increases spacing: line height up to 1.5 times the font size, paragraph spacing up to 2 times, letter spacing up to 0.12 times and word spacing up to 0.16 times the font size. In practice this means: font sizes are set in relative units (rem, em), blocks are not given a fixed height, and text is not embedded in images.

3. Are headings and page regions marked up correctly?

Screen reader users often ‘skim’ a page by its headings, so the headings must reflect the real structure: one H1 with the page topic, then H2 for sections and H3 for subsections, with no skipped levels. The level is chosen by meaning, not by font size.

• Regions are marked up with the <header>, <nav>, <main> and <footer> elements – a screen reader lets the user jump straight to them.
• At the top of the page there's a ‘Skip to content’ link, so the user doesn't have to tab through the whole menu again on every page (2.4.1).
• Every page has its own title in the browser tab (2.4.2), and the code declares the language, e.g. lang="en" (3.1.1), so that a screen reader reads the page in English.

4. Do images have appropriate alt text?

Alternative text (alt) conveys an image's information to people who can't see it. If an image is informative, the alt text briefly says what it shows or what it's for. If an image is decorative, the alt attribute is left empty (alt="") so that the screen reader skips it (1.1.1).

5. Is information conveyed by more than colour alone?

Colour must not be the only way of conveying something (1.4.1). A person with colour blindness or using a screen reader won't realise a field has been filled in incorrectly if it only turns red, and won't distinguish a link from the surrounding text if it differs only in colour.

• Links in text are underlined or otherwise distinguished by more than colour.
• An incorrectly completed form field is also flagged in words, e.g. ‘Enter your phone number’.
• Lines or bars in charts are labelled, not just shown in different colours.
• Product colour options have a text name, not just a coloured swatch.

6. Can a screen reader make sense of tables and charts?

A data table must be a real HTML table with header cells (<th> with the scope attribute), so that a screen reader can say which row and column each figure belongs to (1.3.1). It's worth giving the table a title with the <caption> element.

Tables are not used for page layout, and price lists and timetables are not uploaded as images. Present chart data as text too: a brief conclusion below the chart or a table of figures works for everyone, not just screen reader users.

7. Can the website be operated with a keyboard alone?

Every function must work with a keyboard (2.1.1): Tab and Shift+Tab move between elements, Enter or the space bar presses a button, and Esc closes a pop-up. Keyboards are used both by people who can't use a mouse and by many screen reader users.

• Visible focus (2.4.7). It's always clear which element is selected; the stylesheets must not switch off outline without a replacement.
• Logical order (2.4.3). Focus moves the way the page is read: top to bottom, left to right.
• No traps (2.1.2). You can leave a pop-up, video player or map using the keyboard.
• Focus not obscured (2.4.11, a new WCAG 2.2 criterion). The selected element must not be completely hidden by a sticky header, a chat widget or a cookie banner.

8. Are buttons and links large enough?

Under the new WCAG 2.2 criterion 2.5.8, a clickable element must be at least 24 × 24 CSS pixels or have enough clear space around it so you don't accidentally tap a neighbouring one. Exceptions are links within a sentence and elements whose size is set by the browser itself.

Another new criterion (2.5.7) covers dragging with a mouse or finger. If a price range can only be set by dragging a slider, or products can only be reordered by moving cards, there must also be a simpler way: input fields, buttons or arrows.

9. Can forms be completed without obstacles?

A form field's label must be visible and linked to the field with a <label> element – not just grey placeholder text inside the field that disappears when you start typing (3.3.2). Required fields are marked by more than colour alone.

• Errors (3.3.1, 3.3.3). An error is shown next to the field in words, with an explanation of how to fix it.
• Autofill (1.3.5). Name, email, phone and address fields have the appropriate autocomplete value so the browser can fill them in.
• Redundant entry (3.3.7, a new WCAG 2.2 criterion). Within the same checkout process, users don't have to enter the same information twice – e.g. the delivery address can become the billing address with a single tick.
• Consistent help (3.2.6, a new WCAG 2.2 criterion). If the website has contact details or a chat widget, they're found in the same place on every page.

10. Is logging in free of puzzles?

Criterion 3.3.8 (new in WCAG 2.2) prohibits requiring a cognitive function test at login – remembering, transcribing or calculating something – unless an alternative or assistance is available. It must be possible to paste a password or fill it in with a password manager, and to copy a one-time code.

At Level AA, asking users to recognise objects in images is allowed, but it's still a barrier for blind users. So on login forms it's better to replace typing distorted letters with invisible protection: a hidden honeypot field for bots, checking how long the form took to fill in, or logging in via an email link.

11. Do video and audio recordings have captions and text?

Pre-recorded videos with sound need captions (1.2.2), and audio recordings such as podcasts need a text version (1.2.1). At Level AA, a video also needs audio description (1.2.5) if important information is only shown visually and not narrated.

• Audio lasting more than 3 seconds doesn't play automatically without a way to stop it (1.4.2).
• Moving or changing content, such as a carousel, can be paused (2.2.2).
• Nothing flashes more than 3 times per second (2.3.1).

12. Is the text clear and are the links understandable?

WCAG Level AA doesn't require a particular reading level, but clear language helps everyone, especially people with cognitive impairments. Write in short sentences, one idea per paragraph, and explain complex terms the first time you use them.

• Link text says where the link goes: ‘Delivery terms’, not ‘Click here’ (2.4.4).
• Menus are laid out the same way on every page (3.2.3).
• Instructions don't rely on shape or position alone: not ‘click the green button on the right’, but ‘click the “Place order” button’ (1.3.3).

How do you check a website with free tools?

Automated tools find missing alt text, insufficient contrast and unlabelled fields within minutes, but they can't judge whether alt text makes sense or whether an order can be completed with a keyboard. So supplement them with manual checks.

Check not just the home page but also the typical templates: a category, an article, a form, the basket. For a quick review, the W3C ‘Easy Checks’ list works well.

Where do you start if your website is old?

Start with the elements repeated on every page: the header with the menu, the footer, forms and colours. Fixing these in the theme or template improves the whole website, and then you can work on the content of the most visited pages.

If the theme is older and no longer updated by its developer, it's often more sensible to replace it than to patch it. Saitai.lt updates WordPress, Joomla, WooCommerce and VirtueMart websites, replaces themes and reworks forms and menus – more on our page about website redesign and rebuild. If you'd first like to know what needs fixing, a website accessibility audit against WCAG 2.2 AA costs from €120 and usually takes 1–3 working days. When building a new website, contrast, font sizes and focus styles are planned at the design stage.

Sources

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation of 5 October 2023: w3.org
• W3C WAI, What's new in WCAG 2.2: w3.org
• W3C WAI, ‘Easy Checks’ – a first review of web accessibility: w3.org
• WebAIM, Contrast Checker: webaim.org
• WebAIM, WAVE accessibility evaluation tool: wave.webaim.org
• NV Access, the free NVDA screen reader: nvaccess.org

Planning to update your website and remove accessibility barriers? In the enquiry form, give us your website address and the system it's built on. Within 1 working day we'll tell you where it's best to start: a website accessibility audit (from €120) or going straight to a website update.