Accessibility costs far less to build in than to bolt on. An accessible website redesign treats inclusion as a requirement from the first brief, so colors, components, content and code are shaped around it at every stage. The result is a site that more people can use, including visitors with visual, motor, hearing or cognitive impairments, older clients and anyone browsing one handed on a phone in bright sunlight.
This article sets out how to fold accessibility into each phase of a redesign, based on how we run web design projects. It focuses on process and decisions rather than a full list of standards, so your team knows what to ask for and when.
Why a redesign is the right moment
Fixing accessibility on a live site usually means patching templates one issue at a time. A redesign lets you solve the causes at source: the color palette, the type scale, the component library and the way editors publish content. Decisions made there carry through to every page automatically.
There are commercial reasons too. Accessible sites tend to have clearer structure, which helps search engines and AI assistants understand content. Forms with proper labels and error messages are easier for everyone to complete. Businesses that sell to European consumers also need to consider the European Accessibility Act, which has applied since June 2025 to many digital services. The practical benchmark most organizations use is WCAG 2.2 at level AA.
Write accessibility into the brief and contract
If accessibility is not in the scope, it tends to be the first thing trimmed when deadlines tighten. Make it explicit from the start:
- State the target standard, typically WCAG 2.2 AA, for both language versions.
- Define how conformance will be tested, with which tools and by whom, before sign off.
- Require that third party components such as booking tools, chat widgets and payment pages are reviewed as well, since visitors experience them as part of your site.
- Agree who fixes issues found after launch and within what timeframe.
Audit the current site before designing anything
An audit of the existing site shows which problems are systemic and which are isolated. Run automated checks with tools such as axe or WAVE across your main templates, then do a short manual review: navigate key journeys using only a keyboard, test with a screen reader such as VoiceOver or NVDA, and zoom the browser to 200 percent.
Group findings by cause. A missing focus style, a low contrast brand color or an unlabeled icon button usually appears on hundreds of pages but needs fixing only once in the new design system.
An accessible website redesign starts in the design system
The design phase is where most accessibility is won or lost. Build these requirements into the design tokens and components before page layouts begin.
Color and contrast
Body text needs a contrast ratio of at least 4.5 to 1 against its background, and large text at least 3 to 1. Interface elements such as input borders, icons and focus indicators need at least 3 to 1 against adjacent colors. Test brand colors early. If a signature color fails for text, keep it for large headings or decorative elements and define an accessible variant for body copy and buttons. Never rely on color alone to convey meaning, such as red for errors, without a text label or icon.
Typography and spacing
Choose typefaces that remain legible at small sizes in both Arabic and English, and set comfortable line heights. Layouts should work when users increase text spacing or zoom, without text being clipped or overlapping.
Interactive components
Design every state for buttons, links, fields and menus: default, hover, focus, active, disabled and error. The focus state must be clearly visible and must not be hidden behind sticky headers or banners. WCAG 2.2 also sets a minimum target size for pointer inputs, so small icon buttons need adequate size or spacing.
Structure content for people and assistive technology
Accessible content is mostly good writing with sound structure. Give your content team clear guidance:
- One H1 per page, followed by headings in a logical order, not chosen for their visual size.
- Descriptive link text that makes sense out of context, rather than repeated generic phrases.
- Alt text that conveys the purpose of an image, and empty alt text for purely decorative images.
- Captions for videos and transcripts for audio.
- Plain language, short paragraphs and lists for steps and options.
For bilingual sites, set the correct language attribute on each page and on any mixed language passages, so screen readers switch pronunciation. Arabic pages need the right direction settings, and alt text and form labels must be translated, not left in English.
Build and test with accessibility in the workflow
During development, use semantic HTML before reaching for ARIA attributes. Native buttons, links, lists and form controls come with keyboard support and meaning built in. Custom components such as menus, tabs, carousels and modals need careful keyboard handling and focus management.
Testing works best in layers:
- Automated checks in the build process, which catch a portion of issues quickly, such as missing labels and contrast failures.
- Manual keyboard testing of every template and key journey.
- Screen reader testing on the journeys that matter commercially: navigation, forms, booking and checkout.
- Testing with real users where possible, including people who rely on assistive technology.
Avoid accessibility overlay widgets as a substitute for this work. They do not fix underlying code issues and can interfere with the assistive tools visitors already use.
Keep it accessible after launch
New pages, campaigns and plugins can reintroduce problems within weeks. Protect the investment by adding accessibility checks to your publishing workflow, training editors on headings, links and alt text, and scheduling a periodic audit of top templates. Publishing an accessibility statement with a contact route also gives visitors a way to report barriers so you can fix them.
| Redesign phase | Accessibility task |
|---|---|
| Brief | Set WCAG 2.2 AA as a requirement for both languages |
| Discovery | Audit the current site and group issues by cause |
| Design | Build contrast, focus and target size into tokens and components |
| Content | Headings, link text, alt text, captions and plain language |
| Build | Semantic HTML, keyboard support and automated checks |
| Launch and beyond | Manual testing, editor training and periodic audits |
Frequently asked questions
Does accessibility limit design quality?
No. Accessibility shapes decisions about contrast, focus states, spacing and structure, but it leaves plenty of room for distinctive branding and considered visual design. Many of the most refined sites are also highly accessible, because clarity and legibility are part of good design rather than constraints on it.
Is automated testing enough to confirm accessibility?
Automated tools are valuable but they catch only a portion of issues. They cannot judge whether alt text is meaningful, whether focus order makes sense or whether a custom menu works with a screen reader. Manual keyboard and screen reader testing on key journeys is essential before launch.
Do Arabic pages need separate accessibility testing?
Yes. Arabic pages have their own language and direction settings, translated labels and alt text, and sometimes different fonts. Screen readers need the correct language attribute to pronounce content properly. Testing each language version separately avoids gaps that appear only in right to left layouts.
A site more people can use and trust
An accessible website redesign produces a clearer, more usable site for every visitor and protects you from costly retrofits later. It also signals care, which matters to clients choosing who to trust.
If you would like accessibility built into your next redesign from the outset, we would be glad to discuss your site and the steps involved.
