On this page
Accessibility is often treated as a final audit, performed once the design is approved and the build is nearly done. By then, fixing contrast, focus behavior or heading structure can mean revisiting decisions across the whole site. Building accessibility into a redesign from the start is less work and produces a better experience for everyone.
Agree on a reference standard
Teams commonly use the Web Content Accessibility Guidelines as a reference. Agree which level you are aiming for so designers, developers and content authors share the same target. Avoid claiming formal conformance unless it has been properly evaluated.
Design checkpoints
During design, check:
- Color contrast between text and background, including text over images and on buttons.
- Information not conveyed by color alone, for example error messages that also use text or icons.
- Visible focus states for links, buttons and form fields.
- Readable typography with sensible sizes, line lengths and spacing.
- Touch targets large enough to use comfortably on phones.
- Motion that is purposeful and can be reduced for people who prefer less movement.
Content checkpoints
Content authors play a major role:
- Use headings in a logical order to structure pages.
- Write link text that makes sense out of context, rather than generic phrases.
- Provide alternative text for informative images.
- Use plain language and explain specialist terms.
- Provide captions or transcripts for video and audio.
Build checkpoints
Developers should use semantic HTML elements for their intended purpose, label every form field, announce errors clearly and ensure everything can be reached and operated with a keyboard. Custom components such as menus, dialogs and tabs need appropriate roles, states and keyboard behavior. Use the native element when one exists.
Forms deserve extra care
Forms are where accessibility problems most directly cost enquiries. Each field needs a visible label, instructions should appear before the field, errors should identify the field and explain how to fix it, and the form should not time out unexpectedly.
Test with more than one method
Automated tools find some issues quickly, such as missing labels or insufficient contrast. They cannot judge whether alt text is meaningful or a journey makes sense. Combine automated checks with keyboard testing, screen reader spot checks and, where possible, feedback from people who use assistive technology.
Include documents and third-party tools
PDFs, embedded maps, booking widgets and chat tools are part of the experience. Review their accessibility and choose providers who take it seriously. Offer alternatives where a third-party tool falls short.
Keep it going after launch
Accessibility can regress as content changes. Include checks in editorial guidance and development workflows, and provide a way for visitors to report problems.
Why it matters for the business
An accessible site serves more people, reduces friction in key journeys and reflects well on the organisation. It also tends to be better structured, which supports maintainability and clear communication. Building it in from day one makes those benefits part of the design rather than an afterthought. Write the agreed checkpoints into the project plan so they are reviewed at each stage, not only at the end.
Turn this topic into a project plan
Use these supporting guides to prepare the details for your redesign discussion.
Put this into practice
Planning a move like this?
See how a scoped website redesign project handles content, URLs, integrations and launch.
