When To Bring In a Web Accessibility Consultant

Here’s how accessibility usually shows up in an agency project:

The design gets approved, development is wrapped, and the site is a week from launch when someone asks, “Oh, is this accessible?”

So you bring in a web accessibility consultant, and the audit comes back with forty issues. A few are easy development fixes: a missing form label, a menu that won’t open with the keyboard, or a button that needs a clearer name. Your developer can sort those out pretty quickly.

The trickier ones started months ago in the design file. Maybe the brand color fails contrast across every button, the forms only have placeholder text, or the navigation is a row of icons with no labels.

It’s the website version of checking the electrical after the drywall is up. At that point, every fix takes more time, more explanation, and more budget. That’s why website accessibility really needs to start during the design stage. Keep reading to understand why.

Inclusive Design Decisions Can Help With Accessibility Laws and ADA Compliance

A lot of the decisions that affect accessibility and compliance are design decisions first.

Button colors, form labels, tap targets, link styling, error messages, navigation patterns, and heading hierarchy all shape how easy the site is to use before a developer ever touches it.

If those choices create accessibility barriers, they can turn into bigger problems later for people with disabilities, developers, content editors, and clients. They can also create legal and compliance headaches.

Depending on the client, industry, location, and audience, your team may need to consider accessibility laws like ADA compliance, the European Accessibility Act, Section 508, or another accessibility act that applies to the project.

That’s why I look so closely at the design stage in my role as a web accessibility consultant. I can catch the choices that could cause problems later, while they’re still easy to adjust.

What Web Accessibility Looks Like at the Design Stage

A lot of designers think of accessibility as a developer’s job: code, ARIA, screen reader testing, keyboard behavior. Some of it is. But a surprising amount gets decided before anyone writes a line of code or installs a page builder.

As a web accessibility consultant, here are the design details I look at first:

Color contrast: Body text needs a contrast ratio of at least 4.5:1 against its background, and large text needs 3:1. Button edges, form field borders, and meaningful icons need 3:1 too.
Focus states: Keyboard users need to see where they are on the page. If the design file has no focus style, the developer may leave the browser default, which can clash, or remove it entirely.
Form labels: Placeholder text disappears as soon as someone starts typing. A visible label above each field keeps the form easier to use.
Error states: A red border on its own is easy to miss. Pair color with a clear text message so people know what went wrong and how to fix it.
Links that look like links: If links are only set apart by color, some users won’t spot them. Underlines, clear styling, and strong surrounding copy all help.
Touch targets: WCAG 2.2, part of the Web Content Accessibility Guidelines, asks for interactive targets of at least 24 by 24 CSS pixels, with some exceptions.
Heading structure: Designers pick heading sizes for visual reasons. Screen reader users can move through pages by heading level, so the visual hierarchy needs to support the page structure.

Why the Design Stage Is the Cheapest Place to Fix Accessibility Issues

The design stage is where a lot of accessibility problems are still small.

Small Design Changes Are Faster Before Development

Changing a hex code in Figma takes thirty seconds. Once that same brand color has been built into every button, hover state, card, background section, and reusable component, changing it means hunting through the theme, components, and every page where someone applied it by hand.

The same thing happens with forms, navigation patterns, headings, and interactive states. A tiny design decision can become hours of development clean-up once it has spread across the site.

You Won’t Risk Losing The Client Over Design Changes

There’s a relationship cost too. Telling a client their approved colors need to change a week before launch can be really awkward. Same with explaining that the sleek icon-only navigation needs text labels.

That kind of late change can make your agency look like it missed something. When the design they approve is already accessible, there’s far less to walk back later.

Development Is Smoother When Accessibility Is Planned Early

Developers can fix a lot, but they shouldn’t have to reverse-engineer accessibility into patterns that were never designed for it.

If a design file includes proper focus states, clear labels, logical headings, accessible color combinations, and clear error messaging, development has a much cleaner path.

What Accessibility Consulting During A Web Project Looks Like

When I work with an agency from the start, I’m involved at three key points.

First: Design Review

I review the design before the client sees it. I flag contrast problems, missing states, form patterns, unclear links, confusing headings, and anything else likely to cause trouble later.

Then I suggest fixes that keep the look intact. That might mean using a slightly darker shade, moving a label above a field, adding a focus ring in the brand’s accent color, or giving links a clearer visual treatment. Most of the time, the design still feels like the design.

Second: Component Review

I review key components before the full site gets built. Menus, accordions, tabs, sliders, modals, and forms are where a lot of keyboard and screen reader problems live. Fix a component once, and every page that uses it inherits the fix.

Third: Pre-Launch Accessibility Audits

I audit the finished site before launch. By then, the report is shorter because the bigger design and component issues have already been handled upstream. What’s left tends to be content-level: missing alt text, vague link text, skipped headings, or a page-specific issue that slipped through.

The Goal Is That You’ll Need Me Less Over Time

The biggest benefit of digital accessibility consulting usually shows up on the next project. After a design review or two, your designers start choosing accessible color combinations on their own. Developers build focus states without being asked and each project generally needs less correcting than the one before it.

Over time, accessibility becomes part of how your team works. My role as a web accessibility consultant shifts from catching the same problems to confirming things are already moving in the right direction.

Where to Start with Website Accessibility

If bringing in a web accessibility consultant feels like a ‘do later’ step, your next design file is still a good place to begin.

Before the client presentation, run the color palette through a contrast checker. Add focus and error states to your component library so developers have a clear pattern to follow once the build starts. Use visible labels on form fields, check whether links are relying on color alone, and look at the heading structure while the page is still easy to adjust.

I’d start with the patterns that appear across the whole site: buttons, forms, navigation, headings, links, and cards. When those pieces are more accessible, the improvement carries across a lot of pages.

And if you want a quick way to test the finished site, read “The Mouseless Challenge: The Easiest Keyboard Accessibility Test You’re Not Running”

Ready to Build Website Accessibility Into the Project Earlier?

If you’re a designer, developer, or agency team, you don’t need to wait until launch to find out whether a site has accessibility problems.

My web accessibility consulting services are built for agencies and creative teams that want grounded guidance without slowing the project down.

Book a complimentary consultation, and let’s make accessibility part of the process while the work is still easy to shape.