How to make accessibility part of a website redesign.

Define the target before requesting estimates

Start with the accessibility standard, level, legal or procurement obligations, priority user tasks, supported technologies, third-party systems, and evidence required at acceptance. A vague request for an “accessible website” makes proposals difficult to compare and leaves important assumptions unresolved.

Review the current site early with automated checks, keyboard use, zoom, reflow, and representative assistive technology. An audit can identify inherited content, component, and integration risks. It should inform scope, not become a promise that one report will cover every user experience.

Make accessible content part of migration

Headings, link purpose, image alternatives, captions, transcripts, table structure, instructions, error messages, document formats, and plain language all depend on editorial choices. Inventory these needs alongside page copy and assets so they are not left to developers at the end.

Decide which old documents and media will remain public, who will remediate them, and what can be replaced with structured web content. Give editors rules and fields that support meaningful alternatives rather than treating accessibility as optional metadata.

Design interaction states, not only ideal screens

Specify visible focus, keyboard order, hover and focus parity, errors, success, loading, expanded and collapsed controls, disabled elements, dialogs, menus, and form help. Review contrast, text size, spacing, target size, motion, zoom, and layouts with long content.

Use familiar interface patterns where they solve the task. A visually original control that hides its name, state, or operation creates implementation and testing risk. Responsive prototypes should show how priority journeys work without relying on color, pointer precision, or a particular screen size.

Combine tools with human task testing

Development should use semantic HTML and native controls where possible, then add accessible names, relationships, status messages, and focus behavior where needed. Test components while they are built rather than waiting for complete pages.

Before launch, complete critical tasks with a keyboard, screen reader, zoom, reflow, reduced motion, and form errors. Automated tools catch useful classes of defects but cannot decide whether content is understandable or a journey is coherent. Include regression checks in the same launch plan as links, analytics, redirects, and performance.

Make accessibility an operating responsibility

• Scope: name the standard, pages, journeys, systems, and exclusions.
• Content: assign alternatives, captions, documents, and review.
• Design: provide annotated components and every important state.
• Development: define implementation and acceptance criteria.
• Testing: combine automated, keyboard, assistive, and task review.
• Handover: train editors and record how defects will be handled.