Saving Your Client's Site from the 2026 Accessibility Reckoning

Imagine you're a freelance web designer

It's 11 p.m. on a Tuesday, and you're staring at a Slack message from a client: "Hey, we got a letter from a law firm about our website's accessibility. Can you take a look?" Your stomach drops. You built that site two years ago with a slick dark theme and some fancy hover effects. You thought you were done. But the web doesn't stand still, and neither do the rules. Accessibility isn't a nice-to-have checkbox anymore—it's becoming the law in many places. In the US, the Department of Justice's final ADA Title II rule requires state and local governments to meet WCAG 2.1 Level AA by April 24, 2026, for larger entities, and by April 26, 2027, for smaller ones (Federal Register). In the EU, the European Accessibility Act applies to products and services after June 28, 2025 (EUR-Lex). Even if your client isn't a government body, the pressure is mounting. And it's not just about lawsuits—it's about real people who can't use your site. So, let's roll up our sleeves and do a practical audit. I'll walk you through a realistic scenario, showing you exactly what to look for and how to fix it, using the standards that matter.

Start with the basics: contrast and color

First, let's check the colors. The most common problem, by far, is low-contrast text. The WebAIM Million study found that 83.9% of home pages had low-contrast text (WebAIM Million). That's staggering. And the human cost is real: about 1 in 12 men have some form of color vision deficiency (NEI). So, if you're using color alone to convey meaning, you're already failing.

For your client's marketing site, you probably have a hero section with light gray text on a white background. Let's measure it. WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (WCAG 2.1). Pull up a contrast checker, and you'll see that #767676 on #FFFFFF is only about 4.6:1—just barely passing. But if it's #999999, you're at 2.8:1, and you're failing. My advice: don't skate by. Set a minimum body font size of 16px, and use a contrast ratio of at least 7:1 for body text if you want to be safe (WCAG 2.1). And don't rely on color alone; pair it with labels, icons, or patterns (WCAG 2.1).

Also, check your focus states. UI components—like buttons and form fields—need a contrast ratio of at least 3:1 against adjacent colors (WCAG 2.1). And make sure that when a keyboard user tabs to an element, the focus indicator is visible (WCAG 2.1). In our scenario, the client's primary button is dark blue on white, but the focus outline is a subtle gray that blends in. Fix that by using a high-contrast focus ring, like a 2px solid yellow outline.

Make sure the layout doesn't fall apart

Next, let's talk layout. Your client's site might look great on a 27-inch monitor, but what happens when someone zooms in to 400%? WCAG 2.1 SC 1.4.10 Reflow requires that content can be presented without loss of information and without two-dimensional scrolling at a width equivalent to 320 CSS pixels (W3C). That means your layout should be flexible.

If you built with a fixed-width container, you're in trouble. Instead, use fluid grids with relative units like percentages, fr, em/rem, and vh/vw (MDN). And for images, set max-width: 100%; height: auto; so they never overflow their container (MDN). In our scenario, the client's pricing table has three columns, but on a narrow viewport, it squishes into unreadable mess. A better approach is to use CSS Grid with grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)), so columns wrap as needed.

Also, don't forget about text resizing. Users should be able to zoom text up to 200% without loss of content or functionality (W3C). That means avoid using viewport units alone for font sizing, because they prevent zooming. Instead, combine them with fixed units, like font-size: calc(1rem + 0.5vw) (MDN). And use clamp() for fluid type that scales within safe limits, such as font-size: clamp(1rem, 2.5vw, 2rem) (MDN).

Keyboard navigation: don't leave anyone behind

Now, let's test with a keyboard. WCAG 2.1 SC 2.1.1 requires that all functionality is operable through a keyboard interface (W3C). In our scenario, the client's navigation menu is a hover-only dropdown—that's a no-go. If you can't tab to it and open it with Enter or Space, it's failing.

Also, when you tab through the page, the focus order should be logical. And when a component receives focus, it must not be entirely hidden by other content (WCAG 2.2). That means no sticky headers that cover the focused element. You might need to add scroll-margin to your sections.

In our fix, we'll convert that dropdown to a button that toggles a list, using semantic HTML like <nav>, <ul>, and <button>. And we'll ensure that the focus indicator is always visible. A simple rule: use :focus-visible to style keyboard focus, and never remove the default outline unless you provide a clear replacement.

Forms: label, identify errors, and make it easy

Forms are often a nightmare. The WebAIM Million study found that missing form labels were among the top six errors (WebAIM). WCAG 2.1 SC 1.3.1 requires that form fields have programmatically associated labels (W3C). That means using <label for="id"> or aria-labelledby. Don't rely on placeholder text alone—it disappears when you type.

And when a user makes an error, WCAG 2.1 SC 3.3.1 requires that the error is identified in text and described to the user (W3C). The HTML5 constraint validation API can help, but it's not enough—you need to provide clear, specific messages. In our scenario, the client's contact form has an email field that just says "Please fill out this field"—that's not helpful. Instead, we'll use JavaScript to set custom validation messages, like "Please enter a valid email address." And remember, client-side validation is not a security measure; you must validate on the server too (MDN).

Images, animations, and responsive images

Let's look at images. Every meaningful image needs alt text (WCAG 2.1). If it's decorative, use empty alt text. In our scenario, the client's blog has an infographic with no alt text—that's a fail. Write a concise description that conveys the same information.

For performance and layout stability, set explicit width and height attributes on images so they reserve space before loading, preventing layout shifts (MDN). And use srcset and sizes to let the browser choose the right resolution, or the <picture> element for art direction (MDN). Also, use modern formats like WebP or AVIF—lossy WebP is 25-35% smaller than JPEG (MDN), and AVIF is about 50% smaller than JPEG (MDN), but you'll need fallbacks via <picture>.

Now, about that fancy animation you added. WCAG 2.1 SC 2.3.3 (Level AAA) says that motion animation triggered by interaction can be disabled unless essential (W3C). Even if you're not targeting AAA, it's good practice to respect users' preferences. Use the prefers-reduced-motion media query to tone down or disable animations for users who request that (MDN). In our scenario, the client's homepage has a looping carousel that auto-advances—that can be disorienting. We'll add a pause button and disable the auto-advance when prefers-reduced-motion is set.

Modern CSS to the rescue: container queries and :has()

You might be thinking, "This is a lot of work." But modern CSS can make responsive design easier. Container queries let components respond to the size of their container, not just the viewport (MDN). This is a game-changer for reusable components. For example, you can have a card that looks great in a sidebar and a wide column, without writing a dozen media queries.

And the :has() selector allows you to style a parent based on its children (MDN). For instance, you can add a border to a section that contains an image with a certain class. These features are widely supported now—container queries since February 2023, :has() since December 2023 (MDN).

In our scenario, the client's product grid is built with a fixed number of columns. Instead, we'll use container queries to adjust the number of columns based on the container's width. That way, the same component works in the main content area and in a narrow sidebar.

Bottom line

Accessibility is not a one-time fix; it's an ongoing practice. But the single best move you can make right now is to run an automated audit using tools like WAVE or axe, and then manually test with a keyboard and a screen reader. Don't be overwhelmed—start with the low-hanging fruit: contrast, alt text, form labels, and keyboard navigation. The WebAIM Million study shows that the six most common errors account for 96% of all detected errors (WebAIM). Fix those, and you'll be ahead of most sites. And remember, the deadline is coming—whether it's the ADA, the EAA, or just your own conscience, make your sites accessible. Your users—and your lawyer—will thank you.

Sources

• MDN Web Docs - Responsive design: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• WebAIM Million - https://webaim.org/projects/million/
• Federal Register (DOJ ADA Title II rule) - https://www.federalregister.gov/documents/2024/04/24/2024-07758/nondiscrimination-on-the-basis-of-disability-in-accessible-web-information-and-technology
• W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
• MDN Web Docs (@container) - https://developer.mozilla.org/en-US/docs/Web/CSS/@container