Accessibility in a Website Redesign: A Practical Guide

Web accessibility means building a site that people with disabilities can perceive, understand, navigate and use. That includes people who are blind and use screen readers, people with low vision who enlarge text, people who can't use a mouse, people who are deaf or hard of hearing, and people with cognitive differences. It also helps everyone else, from someone squinting at a phone in bright sunlight to someone using a laptop with one hand.

A redesign is an ideal time to get accessibility right. You're already rethinking colors, layout, navigation and forms, and building accessibility in from the start is usually much easier than fixing it after launch.

This guide covers the basics a non-technical owner should understand and ask for, based on materials from the Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C), the organization that develops web standards.

WCAG and the POUR Principles

The Web Content Accessibility Guidelines, known as WCAG, are the W3C's international standard for web accessibility. The current version is WCAG 2.2, published in October 2023. It builds on WCAG 2.0 from 2008 and WCAG 2.1 from 2018, and content that meets 2.2 also meets the earlier versions. WCAG 2.2 has also been approved as an ISO standard. A future WCAG 3 is in development but is still a draft.

WCAG is made up of testable requirements called success criteria, grouped into three levels: A (the most basic), AA and AAA (the most demanding). Level AA is a common target for organizations. If your business has specific legal obligations, ask a qualified advisor which version and level apply to you.

Everything in WCAG sits under four principles, remembered by the acronym POUR:

• Perceivable: people must be able to perceive the content, for example through text alternatives for images, captions for video and enough contrast to read text.
• Operable: people must be able to use the interface, for example with a keyboard instead of a mouse, and navigation should be clear.
• Understandable: content and controls should make sense, with readable text, predictable menus, and forms that explain what they need and what went wrong.
• Robust: the site should work reliably across browsers and assistive technologies such as screen readers, which depends on clean, standard code.

Color and Contrast

Contrast is the difference in brightness between text and its background. Light gray text on a white background might look elegant on a designer's large monitor but can be hard for many people to read.

At Level AA, WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, which it defines as roughly 18 point, or 14 point bold. Buttons, form field borders and meaningful icons need sufficient contrast too. Free contrast checkers let you test any pair of colors, so check your brand palette early, before it's applied to every page.

Don't rely on color alone to carry meaning, either. A form that marks mistakes only by turning a field red leaves out people who can't easily distinguish that color. Add a text message or an icon as well.

Images and Alt Text

Alt text is a short written description attached to an image. Screen readers read it aloud, and browsers show it if the image fails to load. WAI's images tutorial suggests deciding based on the image's purpose:

• Informative images, such as a photo of a finished project, need a brief description of what matters about them.
• Functional images, such as a logo that links to the homepage, should describe the action or destination rather than the picture.
• Decorative images that add nothing to understanding should have empty alt text, so screen readers skip them.
• Images that contain text should repeat that text in the alt text, though real text is usually the better choice.

During the content audit, add alt text as a column in your spreadsheet so it gets written alongside the page copy instead of as an afterthought.

Headings and Page Structure

Headings do more than make text bigger. Screen reader users can jump from heading to heading to skim a page, much as sighted readers scan for bold titles. For that to work, headings must be real heading elements in the code, arranged in a logical order: typically one main heading for the page, then sections and subsections, without skipping levels.

Other structural basics help too. Each page should have a unique, descriptive title, the page's language should be set in the code, and link text should describe where the link goes rather than saying click here.

Keyboard Access

Some people navigate entirely with a keyboard or a device that works like one. You can test this yourself. Click into the browser's address bar, then press Tab to move forward through links and buttons and Shift+Tab to move back. Check that:

1. You can reach every link, button, menu and form field.
2. A visible outline or highlight shows where you are at all times.
3. The order makes sense and follows the visual layout.
4. You never get stuck, for example in a pop-up you can't close without a mouse.
5. Drop-down menus open and close from the keyboard.

Designers sometimes remove the default focus outline because they find it untidy. Ask for a well-styled focus indicator instead; WCAG requires keyboard focus to be visible.

Accessible Forms

Contact, booking and quote forms are often where a website does its most important work, so they deserve extra care:

• Every field needs a visible label that stays in place. Placeholder text inside the box isn't a substitute, because it disappears as soon as someone starts typing and assistive technologies may not treat it as a label.
• Labels should be connected to their fields in the code, so a screen reader announces the right label for each one.
• Explain up front which fields are required and what format is expected, such as for dates.
• When something goes wrong, describe the error in text, close to the field, and say how to fix it.
• Make buttons and checkboxes large enough to tap and click easily.

Test Early and Keep Testing

Automated checkers can catch some problems quickly, but they can't judge everything, such as whether alt text actually makes sense. WAI's Easy Checks offer a short manual review of page titles, alt text, headings, contrast, zoom, keyboard focus and form labels. WAI is clear that passing these checks doesn't mean a page is fully accessible, so for important sites, consider a fuller evaluation that includes people who use assistive technologies.

Key takeaways

• WCAG 2.2 is the current W3C accessibility standard, organized around the POUR principles: perceivable, operable, understandable and robust.
• Check color contrast early: at least 4.5:1 for normal text and 3:1 for large text at Level AA.
• Write alt text based on each image's purpose, and use empty alt text for purely decorative images.
• Use real, logically ordered headings, and make sure everything works with a keyboard and a visible focus indicator.
• Give every form field a visible, connected label and clear, text-based error messages.

Sources

• W3C WAI: WCAG 2 Overview
• W3C WAI: Accessibility Principles
• W3C WAI: Understanding Success Criterion 1.4.3, Contrast (Minimum)
• W3C WAI: Images Tutorial
• W3C WAI: Forms Tutorial
• W3C WAI: Easy Checks, A First Review of Web Accessibility