Accessibility in 2 hours – with AI instead of days of manual work

Accessibility matters – but nobody enjoys doing it

If you work on the web, you know the topic. Accessibility isn't a nice-to-have – it's a requirement. With the European Accessibility Act, digital products must be accessible. The theory is clear. The practice looks different: ARIA labels on every element, checking semantic HTML, focus management, contrast modes, screen reader compatibility. It's important – but it's also the kind of work that feels endless.

For grossbyte.io, I wanted to do it properly anyway. And I wanted to test how much AI could take off my plate.

The starting point

The website was functional, looked great – but in terms of accessibility, it wasn't where it needed to be. No skip-to-content link, no ARIA labels on interactive elements, no support for system preferences like prefers-contrast or prefers-reduced-motion. In short: almost everything was missing.

What was built in under 2 hours

Using Claude Code CLI, I have implemented full accessibility for the site. Not just superficially – but to a level that exceeds WCAG 2.1 Level AA in the areas where it has been implemented, with support for system preferences that go beyond the standard. Here is an overview:

Semantic HTML & ARIA

• Every interactive element has a meaningful aria-label
• Navigation with aria-current="page", aria-expanded, aria-controls
• Form fields with aria-required, aria-invalid, aria-describedby
• Error messages with role="alert" for screen readers
• Decorative elements consistently marked with aria-hidden="true"

Focus management

• Skip-to-content link with focus:not-sr-only
• Visible focus styles on all interactive elements (focus-visible:outline-gb-green)
• Focus trap in the mobile menu – Tab stays within the drawer, Escape closes it
• Focus returns to the hamburger button after closing

System preferences

• prefers-contrast: more - contrast values automatically increased
• prefers-contrast: less - neon colors toned down, softer tones
• prefers-reduced-motion - all animations and transitions disabled
• prefers-reduced-transparency - decorative transparent elements hidden
• forced-colors: active - layout works in Windows High Contrast Mode

Manual accessibility mode

In addition to automatic system preferences, there's a toggle button in the header. One click activates .a11y-mode - higher contrast, no animations, no decorative transparencies. The state is persisted in localStorage and survives page reloads.

Contact form

• Every field with proper label association and autocomplete
• Validation errors linked to fields via aria-describedby
• Status messages via aria-live="polite" for screen readers
• Honeypot field with aria-hidden="true" and tabindex="-1"
• Loading indicator with aria-busy on the submit button

iOS zoom fix

A classic that many forget: inputs with a font size below 16px trigger an automatic zoom on iOS. It's not a bug, but it's annoying. Solved with a targeted media query – WCAG 1.4.4 compliant, without disabling pinch-to-zoom.

What surprised me

The quality. I expected to do a lot of manual follow-up. Instead, Claude Code implemented the ARIA patterns correctly – disclosure widgets, live regions, focus traps. These aren't trivial patterns, and the implementation was clean.

What also surprised me: the system preferences. prefers-contrast: less and prefers-reduced-transparency are CSS features I had never actively implemented before. Claude Code not only included them but also chose sensible color values – the neon green accents get softened to a more comfortable green under prefers-contrast: less.

Time investment: perspective

If I had done this manually – checking every element individually, writing ARIA labels, coding focus traps, creating CSS for five different contrast modes, making the contact form accessible, all in two languages – that would have been a project spanning multiple days.

With Claude Code, it took under 2 hours. Including review.

That's not a coincidence. Accessibility is exactly the kind of task where AI has the biggest leverage: the rules are clearly defined (WCAG), the patterns are well-known, and it touches many files at once. It's repetitive, error-prone when done manually – and exactly what AI does well.

The honest take

AI doesn't replace understanding accessibility. You need to know what aria-live does, why a focus trap is necessary, and whether the contrast values make sense. But the implementation – writing the labels, adjusting CSS variables, adding role attributes across dozens of files – that's work nobody enjoys, and AI handles it in a fraction of the time.

The real win isn't just speed. It's the fact that accessibility stops being a tedious obligation you keep putting off. When implementation takes 2 hours instead of 2 days, you just do it.

Accessibility shouldn't be a feature you'll "get to eventually." With AI, there are no more excuses.