Accessibility for Web Designers: A WCAG Guide That Doesn't Suck

Accessibility is one of those topics every web designer knows they should care about and most quietly ignore.

The reason isn’t malice. It’s complexity. The official WCAG documentation is 600+ pages. The accessibility guides that try to summarize it usually start with the moral case and end with so many requirements that nobody knows where to start.

The result: most freelance web designers build sites that are partially accessible by accident. The ones that get audited fail badly. The ones that don’t get audited keep failing silently until a client gets a complaint or a lawsuit.

Here’s the version of accessibility I wish someone had taught me when I started. Practical, prioritized, and actually doable on a real freelance project.

Why accessibility matters more than you think

The moral case is real: 1 in 5 people has some form of disability. Building inaccessible sites excludes them from your client’s business.

But the practical case is what’ll convince a skeptical client.

Legal exposure is growing. The number of accessibility-related lawsuits has been climbing every year. Small businesses are increasingly targets. A simple compliance letter from an attorney can cost the client thousands to settle.

SEO benefits are real. Google’s crawlers experience the web more like an assistive technology than a human. A site that’s accessible is usually a site that’s more crawlable. Alt text, semantic HTML, clear heading hierarchy, and keyboard navigation all correlate with better search rankings.

It’s an upcharge. “Basic accessibility” can be a $1,200-$2,000 add-on to your standard package. Most clients will say yes if you frame it as both a legal protection and an SEO benefit.

You don’t need to be an accessibility expert. You need to know enough to deliver a site that hits WCAG AA on the basics, and to know when to refer a client to a specialist for more advanced compliance.

What WCAG AA actually requires (the short version)

WCAG (Web Content Accessibility Guidelines) has three levels: A (minimum), AA (the standard most projects target), and AAA (high-bar, rarely required).

WCAG AA boils down to four principles, called POUR:

Perceivable. Users can perceive the content. Means: visible text contrast, alt text for images, captions for video, content that adapts to assistive tech.

Operable. Users can operate the interface. Means: keyboard navigation works, no time limits that can’t be extended, no content that flashes seizure-triggers.

Understandable. Users can understand the content and the UI. Means: language is identified, form errors are clear, navigation is predictable.

Robust. The site works across browsers, devices, and assistive technologies. Means: clean HTML, semantic markup, ARIA only when needed.

That’s WCAG AA. Most of it is achievable through good design and clean code, without buying tools or hiring specialists.

The 10 things that cover 80% of accessibility

If you don’t have time to dig into the 600-page WCAG spec (you don’t), these 10 things will get most freelance projects to substantially accessible.

1. Use real headings in order

H1 → H2 → H3 → H4. No skipping levels. Every page has exactly one H1. Headings describe the section that follows, not just look big.

Screen readers use headings to let users navigate quickly. A page with no H2s makes screen reader users tab through every paragraph to find content. Heading structure is invisible to sighted users and critical for blind users.

2. Write descriptive alt text on all meaningful images

Decorative images get empty alt (alt=""). Meaningful images get a description that conveys what the image communicates.

Bad: alt=“image of a person” Good: alt=“Andrea sitting at a desk reviewing wireframes on her laptop”

For logos, use the company name: alt=“debrieft logo”

For complex images (charts, infographics), describe the data the image conveys, not just what it looks like.

3. Ensure 4.5:1 contrast ratio for text

WebAIM’s contrast checker is the tool you’ll use a hundred times. Body text needs a 4.5:1 contrast ratio against its background. Large text (24px+ or 19px+ bold) can drop to 3:1.

Common failures: light gray text on white, white text on light pastel backgrounds, brand accent colors used for text without enough contrast.

The fix is usually small: nudge the gray darker, increase the font weight, or change the background slightly. Run every text-on-background combination through the contrast checker before you ship.

4. Make all interactive elements keyboard accessible

Tab through your entire site without using the mouse. Can you reach every link, button, and form field? Can you submit forms? Can you open and close modals?

If yes, you’ve cleared the biggest accessibility bar. If no, you have keyboard accessibility issues that affect any user who can’t use a mouse.

Common failures: custom dropdown menus that open on hover only, modals that trap focus inside or escape it, links that aren’t actually links (div with onClick instead of a tag).

5. Show visible focus indicators

When a user tabs through the site, the currently focused element needs a visible outline or highlight. The browser default works fine. Don’t strip it with outline: none unless you replace it with something equivalent or better.

This affects every keyboard user and many screen reader users. Removing focus indicators is one of the most common accessibility failures in beautifully designed sites.

6. Label every form input

Every input field needs a <label> element associated with it. Placeholder text is not a label. Screen readers don’t reliably read placeholders.

<label for="email">Email address</label>
<input id="email" type="email" />

For visually subtle designs that hide the label text, use aria-label instead, but never use placeholder-only inputs as labels.

7. Clear error states for forms

When a form fails, the error message should be: visible, descriptive, and announced to assistive tech.

Bad: a red border around the field with no explanation Good: an error message below the field that says “Please enter a valid email address” and is announced via aria-live="polite".

This affects everyone using the form, not just disabled users. Clear error states reduce form abandonment across the board.

8. Don’t rely on color alone

If you indicate a status or category with color, also use a label or icon. Red text + an icon = accessible. Red text alone = problematic for users with color blindness.

This comes up in form errors, status badges, and data visualization. Add a second signal (icon, label, pattern) beyond just color.

9. Provide captions for video and transcripts for audio

If the project includes video or podcast embeds, captions and transcripts are required for AA. Most video hosts (YouTube, Vimeo, Wistia) have built-in captioning tools.

For a freelance project without a dedicated content team, the practical move: budget for transcript service ($1-$2 per minute) and include it as a line item in the quote.

10. Test with a screen reader

This is the single best thing you can do for accessibility. Run your finished site through a screen reader and listen.

Mac: VoiceOver (Cmd+F5 to toggle) Windows: NVDA (free download) iPhone: VoiceOver in Accessibility settings Android: TalkBack in Accessibility settings

Spend 20 minutes navigating your site without looking at the screen. The issues become obvious. Headings that don’t make sense out of context. Buttons labeled “click here.” Images with no description. Forms that can’t be completed without seeing the screen.

You don’t need to be a screen reader expert. You need to hear what your site sounds like to a user who depends on one. Most of the fixes after a screen reader test are 10 minutes of work and dramatically improve the experience.

What you can skip (until you can’t)

You don’t need to nail every WCAG criterion on every project. Some are uncommon enough that you can address them only when relevant.

Skip until needed:

• AAA-level requirements (specific contrast ratios, sign language interpretation)
• ARIA labels on standard HTML elements (semantic HTML usually doesn’t need ARIA)
• Custom focus management for complex JS widgets (unless you’re building one)
• Site translation and language attribute requirements (relevant for multi-language sites only)

Don’t skip:

• The 10 items above
• Any client who’s in a regulated industry (healthcare, finance, government, education)
• Any client who’s already received an accessibility complaint
• Any client who serves an audience that disproportionately includes disabled users (seniors, accessibility-focused services)

For these clients, hire or refer to an accessibility specialist for a full audit. Don’t try to wing AA compliance on a high-stakes project.

Selling accessibility to clients

The hardest part of accessibility isn’t the technical work. It’s selling it as a line item.

The pitch that works: present it as risk management plus SEO plus reach.

“Including basic accessibility (WCAG AA) protects your business from a growing wave of accessibility-related complaints and lawsuits. It also improves how Google indexes your site, which can improve your search rankings. And it makes your site usable for an additional 15-20% of your audience who currently can’t access standard sites. The cost is €1,200 as an add-on to the base package, or we can skip it. What works for you?”

Most clients say yes. Especially after you describe how a demand letter from an attorney can cost €5,000-€10,000 to settle, even when the claim has no merit.

The few who decline accept the risk in writing. You note it in the contract: “Site does not include WCAG AA accessibility compliance. Client acknowledges this and accepts associated risks.” This protects you when the demand letter eventually arrives.

The 30-minute audit

Before shipping any freelance project, run a 30-minute accessibility audit. Use these tools in order:

1. WAVE browser extension (5 minutes). Catches the obvious failures: missing alt text, contrast issues, structural problems. Free.

2. Keyboard navigation walkthrough (10 minutes). Tab through every page. Verify focus indicators, dropdown behavior, modal handling, form completion.

3. Screen reader walkthrough (10 minutes). Listen to one or two key pages. Verify headings make sense, links describe destinations, images have meaningful alt text.

4. Color contrast spot check (5 minutes). Run every text-on-background combination through WebAIM’s contrast checker. Fix the ones that fail.

30 minutes gets you to substantially accessible on a typical small business site. That’s enough for most projects, enough to justify the upcharge, and enough to protect both your client and your professional reputation.

Accessibility isn’t a separate skill you have to master. It’s a set of habits you build into your normal design and build process. Once the habits are there, accessible sites become the default. The bar isn’t perfection. It’s not making the same 10 obvious mistakes everyone else makes.

You’ll get most of the way there with the 10 habits above. That’s enough to deliver real value, protect your client, and stop being part of the problem.

---

debrieft generates a brief that includes accessibility as a default consideration. The intake form asks about audience characteristics, and the brief includes an accessibility note in every project. Your client gets a portal. You get a dashboard. Both in sync. Try it free at debrieft.app