Sometimes an audit comes back and the list of problems is not really a list. It is the same handful of failures repeated across every template, coming from a theme that was bought in 2016, a page builder stacked on top of it, three slider plugins and a menu nobody can open from the keyboard. You could fix it piece by piece. But you might also be paying to patch a site you were planning to replace within a year anyway. An accessible website redesign makes sense when the cost of fixing the old build is close to the cost of a new one, and when a fresh start lets you design out the barriers instead of chasing them. This page explains how we decide, and how we rebuild without losing the content and search traffic you already have.
Redesign or remediate: how we decide
Most sites should be fixed, not rebuilt. Remediation is usually quicker, keeps what works, and our accessibility remediation service handles it. A rebuild earns its place only when the problems are structural.
We look at the audit and ask a few direct questions. Are most failures in the theme and page builder output rather than in content? Would fixing them mean overriding large parts of a theme that is no longer updated? Are there many distinct templates, each broken in its own way? Is the business already unhappy with the design, the speed or the editing experience? If the answers lean yes, a redesign is often the better use of the same effort.
| Signal from the audit | Usually points to fixing | Usually points to rebuilding |
|---|---|---|
| Where the failures sit | Mostly content: alt text, headings, link text | Mostly theme and builder markup repeated on every page |
| Theme status | Maintained, with a child theme for changes | Abandoned or heavily modified without a child theme |
| Number of templates | A few, built consistently | Dozens, each assembled differently by past editors |
| Interactive parts | Standard menus and forms with known fixes | Custom sliders, tabs and popups with no keyboard support |
| Business plans | Happy with the design for a few more years | Rebrand or new services already on the roadmap |
A middle path: rebuilding only the worst templates
The choice is not always all or nothing. On some sites the content pages are fine and the damage is concentrated in a few places: the header and menu, the home page built from a dozen builder widgets, and a product or service listing that nobody can use from a keyboard. In that case we can rebuild just those templates on a clean foundation and fix the rest in place. You get most of the benefit of an accessible website redesign without moving every page, and the work can be spread over a longer period. The risk is that old and new parts sit side by side for a while, so we keep a short list of what has moved and what has not, and test the joins between them, such as a new header sitting above an old page body.
We will tell you if we think fixing is cheaper. A rebuild is a bigger project with more risk, and it should be chosen for good reasons, not because it is the more exciting option.
Why old themes and page-builder sites resist fixing
Multipurpose themes sold years ago often bundled their own builder, their own slider, their own icon font and their own menu script. Each one generates markup the site owner cannot easily change. When a menu’s dropdown only opens on hover, the fix lives in the theme’s JavaScript. When every heading in the builder is a styled div, the fix means rebuilding every section on every page.
Page builders are not the villain here. Modern versions of Elementor and Divi can produce reasonable output when used with care, and our page on Elementor and Divi accessibility fixes covers that path. The trouble is old builds, layered over years by different hands, where the same content is held together by nested containers, custom CSS and widgets from add-on packs that stopped receiving updates.
What we see again and again
- Focus outlines removed sitewide with one line of CSS, then restored nowhere.
- Headings chosen by font size, so the page jumps from H2 to H5 and back.
- Icons from an old icon font read aloud as random letters or nothing at all.
- Text set inside hero images, so it cannot be resized, translated or read.
- Mobile menus that open but trap keyboard focus behind the overlay.
- Brand colors with light gray text that fails contrast on almost every page.
Each item has a fix. When all of them appear together, on every template, the fixes start to look like a rebuild done the slow way.
Accessible website design from the first wireframe
Building it in from the start is far cheaper than retrofitting. In a redesign we make accessibility decisions at the design stage, when they cost a conversation rather than a code change.
Color and contrast. We test the brand palette before the mockups, measuring every text pairing against WCAG 1.4.3, which sets a 4.5:1 ratio for body copy and relaxes to 3:1 once text is large, then measuring buttons, field borders and icons against the 3:1 floor in 1.4.11. If a brand color fails, we find a darker shade for text use while keeping the original for decorative areas. The post on designing for color blindness covers the related issue of not relying on color alone.
Type and spacing. Readable body size, generous line height, and layouts that survive the text spacing changes in 1.4.12 without clipping. Our post on choosing accessible fonts and sizes goes further.
Focus and targets. A visible focus style is designed, not left to browser defaults or deleted. Buttons, links in navigation and icon controls meet the 24 by 24 CSS pixel minimum from 2.5.8. Sticky headers are sized so they do not cover focused elements, which 2.4.11 asks for.
Layout and reflow. Every template is designed to reflow at 320 CSS pixels wide with no horizontal scrolling, which is what 1.4.10 expects, and to work when text is zoomed to 200 percent.
Motion. No auto-advancing carousels by default. Animations respect the visitor’s reduced-motion setting. Background video, if kept, has a visible pause control.
Structure before style
Before anyone picks colors, we map each template’s structure: one H1, logical heading levels, landmarks for header, navigation, main content and footer, a skip link, and a clear order of content when read top to bottom. Design then decorates that structure rather than inventing it.
Build choices that keep the new site accessible
We usually build on a well-maintained WordPress theme, often a block theme or a lean classic theme with a child theme for our changes. Theme quality matters more than any plugin you add later; the post on picking an accessible WordPress theme explains what the directory’s “Accessibility Ready” tag does and does not check.
Plugins are chosen with their output in mind. A form plugin must produce real labels and tie error messages to fields. A menu must respond to every key a keyboard user relies on, the arrows and Escape included. Any slider, tab or accordion is checked by keyboard and by screen reader ahead of being placed on any template, not afterward. Fewer plugins means fewer places for barriers to hide.
We also give editors guardrails: block patterns with correct headings already in place, a limited color set that passes contrast, and alt text prompts on image blocks. A site that is accessible on launch day can drift quickly if editors have no help.
Carrying content and SEO across
A redesign that wrecks search traffic is not a success, however accessible it is. We treat the move as a migration project with its own checklist, and our general website redesign service page describes the wider process.
- Inventory. We crawl the old site and list every URL, its traffic and its inbound links, so nothing valuable gets dropped by accident.
- Content review. Pages are marked keep, merge, rewrite or retire. This is also when we fix headings, link text and alt text in the content itself.
- URL plan. Where URLs change, each old one gets a 301 redirect to its closest match. The walkthrough on tracking down broken links once a new site is live shows how to catch the ones that slip through.
- Metadata. Titles, descriptions and structured data are carried over or improved, not lost in the copy.
- Documents and media. PDFs, videos and images are moved with their alt text, captions and transcripts, and fixed where they were missing.
- Launch checks. After launch we watch Search Console and analytics for drops and broken links. The post on protecting rankings during a redesign covers what to watch in the first weeks.
A fair amount of accessibility work helps search too. Clear headings, descriptive links, real text instead of text in images, and captions all make a page easier for people and search engines to understand. We do not promise ranking gains from accessibility; we just make sure the redesign does not throw away what you had.
How an accessible website redesign project runs
- Audit the current site. If you do not have a recent one, our WCAG 2.2 audit comes first, so the decision to rebuild rests on evidence.
- Plan. Templates, content inventory, URL map and plugin choices.
- Design. Wireframes, then visual design, each reviewed against contrast, focus, target size and reflow.
- Build on staging. Templates are built one at a time, and each is checked by keyboard, screen reader and browser zoom ahead of any content arriving.
- Migrate content. Pages, media and documents move over with fixes applied.
- Test the whole site. A full manual pass on the finished staging site, plus automated scans of every template.
- Launch and watch. Redirects, search and analytics checks, and a follow-up accessibility retest a few weeks in.
The old site keeps running throughout. If it needs urgent care during the project, the post on maintaining a site while a redesign is under way explains how we keep it patched without wasted effort.
What you receive and what we ask of you
At the end of the project you have:
- A new WordPress site tested against WCAG 2.2 Level AA, with a test report for every template.
- A design record of colors, type sizes and focus styles, with contrast results.
- A redirect map from old URLs to new ones.
- Notes on any issue left open, such as a third-party embed, with its effect on users.
- Short editor guidance on headings, links, images and the block patterns we built.
- A retest after launch confirming nothing broke in the move.
The test report says which WCAG 2.2 AA criteria were checked on each template and what the result was. It will not call the new site “ADA compliant,” and we will not tell you it stays accessible without upkeep, because the first plugin update or new landing page can change that.
From you we need:
- A WordPress login with administrator rights on the current site, plus hosting or DNS access for launch.
- Brand assets: logo files, colors, fonts and any brand guidelines.
- Decisions on which pages, services and documents matter most to customers.
- Access to Search Console and analytics, so we can protect traffic.
- One person who can approve designs and content, and who is available during review rounds.
How to judge whether the new site is truly accessible
Do not take the launch announcement on trust, ours included. Test a few things yourself. Start on the home page and move through it with the Tab key alone. Is the focused item visible every time? Does focus travel in the same order you read? Open the menu with the keyboard and close it with Escape. Fill in the contact form, leave a field empty, and see whether the error tells you which one. Zoom the browser to 200 percent and to phone width. Turn on VoiceOver or NVDA and listen to a page.
Then look at content added after launch. If new blog posts and pages added by your team still have headings in order and alt text on images, the guardrails are working. If they do not, the site is already sliding back.
Redesign mistakes that bring the barriers back
- Testing only at the end. Fixing a design after the build is the expensive path a redesign was meant to avoid.
- Picking a theme from a demo. Demos rarely show keyboard behavior. Test the theme before committing.
- Keeping the old slider “for now.” Temporary carry-overs tend to become permanent.
- Copying content without fixing it. Migrating old fake headings and missing alt text gives you an old site in new clothes.
- Forgetting redirects. Old links break, traffic falls, and the redesign takes the blame.
- Adding an overlay at launch. If the new site needs a toolbar to be usable, the redesign has not done its job.
Redesigning yourself or hiring a team
A small business with a simple site can do a lot alone: choose a well-tested theme, keep plugins few, follow the editor guidance in our post on writing accessible web content, and check each page with a keyboard and a free scanner. That is a real option for a five-page site.
Bring in help when there are many templates, a store or booking system, documents and video to migrate, or meaningful search traffic to protect. When you talk to any agency, ask these questions. Will accessibility be checked at the design stage or only after build? Which screen readers do you test with? How do you handle redirects and search data? Who writes alt text and fixes headings during migration? What testing happens after launch? Will you show us a test report for each template?
Keeping a redesigned WordPress site accessible after launch
Launch day is when the new site is in its finest shape. After that, plugin updates, new content and new campaigns slowly erode what was built. A redesign should end with a plan for that: editor guidance, a scheduled retest of key templates, and someone trying each update on a staging copy first.
We can take that on as part of regular WordPress care, so the work done in the redesign is still there a year later. To see how redesign fits alongside audits, fixes and monitoring, visit the overview of our accessibility work.
Content and design: Guides
Step-by-step guides on the individual tasks behind this service:
- Accessible Web Content: What Editors Control
- Alt Text for Decorative Images: When to Use Empty Alt
- Video Captions for Accessibility: Get Them Right
- Transcripts for Accessibility: Podcasts and Audio
- Accessible PDF Files on Your Website: What to Fix
- Accessible Fonts: Size, Spacing and Readable Type
- Color Blind Friendly Website: When Color Can’t Carry Meaning
- Plain Language Writing for Your Website: A US Guide
- Accessible Tables: Headers, Captions and Phones
- Buttons vs Links: Which to Use for Accessibility
- Animation Accessibility: Parallax, Video and Reduce Motion
- Accessible Icons: SVG, Icon Fonts and Social Links