Insights / Threads
How to maintain accessibility after a redesign
Maintaining accessibility after a redesign means making it part of the process, not a final review. It has to be present in design, components, development, content, QA, and maintenance to prevent a visual improvement from creating new barriers.
Maintaining accessibility after a redesign starts before launch
Maintaining accessibility after a redesign is not achieved with a quick audit at the end. If you wait until the whole website is already built, many issues will already be embedded in templates, components, and visual decisions that are hard to change easily.
The sensible approach is to review accessibility from wireframes, prototypes, and the design system. The earlier accessibility criteria enter the process, the less they become a patch and the more naturally they work as a way to design better.
In public-sector website redesigns, this matters even more. You are not only changing a visual layer: you are touching access to procedures, information, and services that many people need to use.
A redesign can break accessibility that used to work
A redesign can make accessibility worse even when the result looks more modern. New colors can reduce contrast. New menus can break keyboard navigation. New components can lose labels, roles, or states.
The same thing happens with content. When pages are reorganized, texts are simplified, or documents are migrated, useful headings, descriptive links, contextual help, or structures that previously supported comprehension can disappear.
That is why it is worth accepting something uncomfortable but necessary: redesigning does not automatically mean improving. If it is not controlled, a visually cleaner website can become less usable for part of the population.
The design system should include accessibility from the ground up
The best way to maintain accessibility is to bring it into the design system. Buttons, forms, modals, menus, cards, alerts, and reusable components should be created with criteria for contrast, focus, states, semantics, and keyboard behavior.
This prevents the same issue from being fixed in twenty different places. If the base component is accessible, every new page starts from a better position. If the base component fails, the failure is replicated with fairly depressing efficiency.
Our recommendation is to document usage rules, variants, states, and examples. Accessibility does not live only in the code: it also lives in how the team uses each piece.
Content can also break accessibility after a redesign
Maintaining accessibility after a redesign is not only design and development work. Content also matters: headings, links, alternative text, documents, instructions, error messages, and form microcopy.
A link that says “click here,” an informative image without a text alternative, or a PDF uploaded without structure can introduce barriers even if the template is correct. Accessibility degrades quickly when editorial maintenance is careless.
That is why it is important to define criteria for the people publishing content. If the editorial team does not know what to review, the website can launch accessibly and start breaking two weeks later. Something that happens far too often.
Accessibility QA should be part of the normal workflow
Accessibility QA should be part of the publishing workflow, not a phase reserved for the end. Every relevant change should review keyboard use, focus, contrast, structure, forms, and behavior with assistive technologies when applicable.
Automated tools help detect obvious issues, but they are not enough. They do not always identify whether a message is understandable, whether the reading order is logical, or whether a component is usable in a real journey.
The useful approach is to combine checklists, manual testing, and reviews of critical pages. Especially on public-sector websites: home, procedures, forms, search, key informational pages, and frequently used documents.
Maintaining accessibility requires owners and periodic reviews
Accessibility is maintained better when someone owns it. If it remains a collective responsibility, it often ends up being nobody’s responsibility. It is necessary to define who reviews, who approves, who fixes, and how often audits happen.
It is also worth scheduling periodic reviews. A redesign can launch well and then degrade because of new campaigns, plugins, modules, documents, content changes, or small accumulated urgencies.
Our view is clear: accessibility is not a launch milestone, it is a maintenance practice. Publishing an accessible website is good. Keeping it accessible six months later is where you see whether the process was serious.
Frequently Asked Questions
To maintain accessibility after a redesign, you need to integrate it into the design system, components, development, QA, and content management. Auditing only at the end is not enough: it has to be part of the process and the maintenance that comes afterward.
Because changing layouts, colors, components, navigation, or content can break contrast, focus states, hierarchy, labels, and keyboard behaviors that used to work. A redesign may improve the visual interface, but it can also introduce new accessibility barriers.
Accessibility should be audited from the early stages: design, prototype, development, and pre-launch. If it is reviewed only at the end, issues are more deeply embedded in the system and therefore harder and more expensive to fix because they require rework.
It should include contrast, visible focus, keyboard navigation, semantic structure, forms, error messages, alternative text, headings, reusable components, content, and testing with assistive technologies.
No. After launch, accessibility needs to be maintained with periodic reviews, editorial QA, control over new components, team training, and audits of critical pages. Accessibility degrades if nobody takes care of it day to day.
To dig deeper into this topic
