9 Accessibility Questions to Ask a Web Designer Before You Hire Them

You found a web designer. Their portfolio looks great, the price is reasonable, and they can start next month. Before you sign anything, there is one conversation that can save you thousands of dollars and a legal headache down the road: a short talk about accessibility.

Here is the uncomfortable truth most business owners never hear. The vast majority of websites being built today — including by talented, well-reviewed designers — are not accessible. WebAIM, a respected research group, scans the top one million home pages every year, and they consistently find that over 95% of them have detectable accessibility failures. That means the default outcome, the thing that happens if you say nothing, is a website that some of your customers literally cannot use and that puts you at risk of an ADA demand letter or a European Accessibility Act complaint.

The good news: you do not need to become a technical expert to protect yourself. You just need to ask the right questions and know what a good answer sounds like. If a designer gets visibly uncomfortable, waves the questions away, or promises a magic plugin will handle it, that tells you everything you need to know.

Here are nine questions to ask, what you are really trying to learn from each one, and the green flags and red flags to listen for.

1. “Do you build to WCAG 2.1 Level AA?”

This is the single most important question, and it is a litmus test. WCAG (Web Content Accessibility Guidelines) is the international standard for accessible websites, and “2.1 Level AA” is the specific version and level that nearly every law points to — the Americans with Disabilities Act in the US, the European Accessibility Act in the EU, and equivalents in Canada, the UK, and Australia.

A designer who works on accessibility will recognize “WCAG 2.1 AA” instantly and tell you whether it is part of their normal process or an add-on. A designer who has never built accessibly will hesitate, ask what that is, or say “we follow best practices” without naming the standard.

Green flag: “Yes, AA is our baseline” or “We can build to AA, here’s what that adds to the timeline.”

Red flag: A blank stare, or “Our sites are all mobile-friendly and fast” — which is real work, but it is not accessibility.

2. “How do you handle images and alt text?”

Alt text is a short written description of an image that screen readers (the software blind and low-vision people use) read aloud. It is one of the most basic accessibility requirements and one of the most commonly skipped. Asking about it is an easy way to see if a designer thinks about the details.

You want to hear that they write meaningful alt text for images that carry information, mark decorative images so screen readers skip them, and — importantly — that they will set up your content management system so that you can add alt text yourself later. A site that is accessible on launch day but gives you no way to describe the photos you upload next month is only half a solution.

Green flag: “We write alt text for launch images and we’ll show your team how to add it going forward.”

Red flag: “The platform handles that automatically.” It does not. Auto-generated alt text is unreliable and often wrong.

3. “Can the whole site be used with just a keyboard?”

Many people cannot use a mouse — because of motor disabilities, tremors, or because they navigate by keyboard or switch device. Every menu, button, form field, popup, and slideshow on your site must work when someone presses Tab, Enter, and the arrow keys instead of clicking.

This is also where a lot of fancy design breaks. Custom dropdown menus, image carousels, “hamburger” mobile menus, cookie banners, and popup modals are the usual offenders. A designer who tests with a keyboard will say so without prompting. One who does not will treat the question as unusual.

Green flag: “We test every interactive element with the keyboard, including menus and popups.”

Red flag: “Everything is clickable, so it’s fine.” Clickable is not the same as keyboard-accessible.

4. “How do you check color contrast?”

If text does not stand out enough from its background, people with low vision, color blindness, or anyone using a phone in sunlight cannot read it. WCAG sets specific minimum contrast ratios (4.5 to 1 for normal text), and there are free tools that check a color combination in seconds.

This question matters extra if you have specific brand colors. Pale gray text, light buttons, and text laid over photos are the most common contrast failures, and they are usually invisible to a designer who is not measuring. A good designer will tell you they check brand colors against the contrast minimums and will flag any of your brand colors that do not pass — and propose a slightly adjusted shade rather than just ignoring the problem.

Green flag: “We run your palette through a contrast checker and adjust any combinations that fail.”

Red flag: “We’ll make it look good” with no mention of measuring anything.

5. “How will the forms work for someone using a screen reader?”

Forms are where you make money — contact forms, booking forms, checkout, newsletter signups — and they are one of the hardest things to get right. Each field needs a proper label that is connected to its input (not just gray placeholder text that disappears when you start typing), required fields need to be marked in a way screen readers announce, and error messages need to point clearly to the field that has a problem.

A broken form is not just an accessibility failure; it is lost revenue from every customer who cannot complete it. This question quickly separates designers who think about real-world use from those who only think about how things look.

Green flag: Specific talk about labels, required-field indicators, and error messages.

Red flag: “We use a form plugin, it’s all handled.” Many popular form tools are not accessible out of the box.

6. “Are you planning to use an accessibility overlay or widget?”

This is a trap question, and the answer is revealing. Accessibility overlays are third-party widgets — often sold under names involving “accessiBe,” “UserWay,” and similar — that you paste onto your site, and they promise instant compliance, usually for a monthly fee. You may have seen the little wheelchair or person icon in the corner of a website.

The problem: these overlays do not work. They have been widely criticized by the accessibility community, blind users frequently report that they make sites harder to use, and — crucially — they do not protect you legally. Hundreds of businesses using these widgets have still received ADA lawsuits. A designer who proposes an overlay as the accessibility plan either does not understand the issue or is looking for a shortcut.

Green flag: “No, overlays don’t actually fix the underlying code and they don’t protect you legally.”

Red flag: “We’ll add a widget that makes the whole site compliant for $49 a month.” Walk away from this answer.

7. “How do you test the site before launch?”

There are two parts to good testing, and you want to hear about both. Automated tools (like axe, WAVE, or Lighthouse) scan a page in seconds and catch common, code-level problems — but they only catch roughly a third to half of all issues. The rest require a human to actually use the site: navigating with a keyboard, turning on a screen reader, checking that the reading order makes sense.

A designer who only runs an automated scan and calls it done will hand you a site that passes a robot’s check but still fails real users. The best answer combines both: automated scans to catch the obvious, plus manual keyboard and screen-reader testing on the important pages.

Green flag: “Automated scans plus manual keyboard and screen-reader testing on key pages.”

Red flag: “We run Lighthouse and aim for a high score.” A high Lighthouse score is necessary but nowhere near sufficient — plenty of sites scoring 95+ still get sued.

8. “Will you give me an accessibility statement and document what you did?”

An accessibility statement is a page on your website that explains your commitment to accessibility, the standard you aim for, and how someone can report a problem. It is good practice, it is expected (sometimes required) under laws like the EAA, and it signals good faith if you ever face a complaint.

Beyond the public statement, you want some record of what was tested and what conformance level the site reached. This documentation matters enormously if you ever receive a demand letter — being able to show that you took deliberate, documented steps toward accessibility is part of what protects you. A designer who does this routinely is one who takes the work seriously.

Green flag: “We provide an accessibility statement and a short report of what we tested and fixed.”

Red flag: No idea what an accessibility statement is.

9. “What happens when I add new content after launch?”

This is the question that protects you long-term, and almost nobody asks it. Your website is not frozen on launch day. You will add blog posts, upload product photos, publish PDFs, embed videos, and run promotions. Every one of those is a chance to introduce a new accessibility problem — a photo with no alt text, a PDF that screen readers cannot read, a video with no captions, a popup that traps the keyboard.

A thoughtful designer will set your site up so that doing the right thing is easy: an alt-text field that is hard to ignore, templates that keep heading structure correct, and a short guide for your team. The difference between a site that stays accessible and one that degrades within months comes down to this handoff.

Green flag: “We’ll set up your CMS and give your team a short guide so new content stays accessible.”

Red flag: “Once it’s launched, it’s accessible.” Nothing stays accessible on its own.

What to do with the answers

You are not grading a technical exam. You are looking for a pattern. A designer who is comfortable with these questions, names the WCAG standard, talks about real testing, and rejects overlays is someone who will build you a site that works for everyone and reduces your legal risk. A designer who deflects, name-drops a magic widget, or treats accessibility as an exotic extra is someone whose work you may have to pay to fix later — or worse, defend in a complaint.

If accessibility is not already in your designer’s proposal, ask for it in writing before you sign: which WCAG version and level they will meet, what testing they will do, and what they will hand off to keep the site compliant. Put it in the contract. It is far cheaper to specify accessibility upfront than to retrofit it — retrofitting a finished site typically costs several times what it would have cost to build correctly from the start.

And if you already have a site built by someone who clearly did not ask any of these questions, do not panic. Start by running a quick check yourself to understand where you stand, then prioritize the highest-impact fixes — forms, navigation, contrast, and alt text usually cover most of the real-world barriers.

You do not need to know how to code to hold a web designer to a good standard. You just need to ask — and to recognize a confident, specific answer when you hear one.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.