North Blue Digital

Accessibility

Your site should work for everyone who visits it — not just people with the latest hardware and perfect vision.

Why accessibility matters for your business

Accessibility isn't a nice-to-have or a compliance checkbox. It's a design constraint — like gravity. When you build with it from the start, you get a site that works better for everyone:

15-20% of people have a disability. That's customers you're turning away if your site isn't accessible.
It's a legal requirement. ADA lawsuits against websites have increased every year. Proactive accessibility is cheaper than reactive compliance.
Accessible sites rank better. Proper heading hierarchy, alt text, semantic HTML — the things that make a site accessible are the same things Google uses to understand your content.
It's just good design. Keyboard navigation helps power users. High contrast helps everyone in bright sunlight. Captions help people in noisy environments. Accessibility improvements benefit all visitors.

What WCAG 2.1 AA actually means

WCAG (Web Content Accessibility Guidelines) is the international standard. Level AA is the widely accepted baseline. Here's what it requires in plain language:

Perceivable: All content can be perceived by all users. Images have alt text. Videos have captions. Text has sufficient contrast (4.5:1 for normal text, 3:1 for large text). Nothing relies solely on color to convey meaning.
Operable: Every interaction works with a keyboard. No keyboard traps. Focus indicators are visible. Touch targets are at least 44x44 pixels. Users have enough time to read and interact with content.
Understandable: The page language is declared. Form inputs have labels. Error messages are clear and specific. Navigation is consistent across pages.
Robust: Content works with assistive technologies — screen readers, voice control, switch devices. This means semantic HTML, proper ARIA when needed, and valid markup.

How accessible sites get built

Accessibility isn't bolted on at the end. It's built into every decision from the start:

Semantic HTML first: A <button> is better than a<div role="button" tabindex="0">. Your site uses<nav>, <main>,<article>, <details>,<dialog> — elements that carry meaning, structure, and accessibility for free. ARIA is a last resort, not a first choice.
Keyboard-first interaction: Every interactive element works with Tab, Enter, Space, and Escape. No keyboard traps. :focus-visible for keyboard-only focus indicators that don't clutter mouse interactions.
Respecting user preferences: prefers-reduced-motion,prefers-color-scheme,prefers-contrast — these are the user telling you what they need. Your site honors all of them.
Testing like a user: Automated scanning with axe-core catches the obvious issues. Keyboard walkthroughs catch the interaction issues. VoiceOver spot-checks catch the screen reader issues. Lighthouse accessibility target: 95+.

The AI-generated site problem

The web industry is moving fast toward AI-generated websites. Tools like Bolt, v0, and Cursor can generate a visually polished site in minutes. But there's a catch that most people don't see until it's too late:

AI-generated UI is inaccessible by default.

AI tools optimize for what looks right, not what works right. The browser builds two parallel representations of every page: arender tree (what you see) and an accessibility tree(what screen readers, keyboard users, and assistive technologies use). AI-generated code produces near-zero semantic information for that second tree.

In practice, this means AI-generated components routinely ship with:

<div onClick> instead of <button>— looks clickable, but can't be reached with a keyboard
Styled <div>s instead of<nav>, <main>,<header> — no landmarks for screen reader navigation
Navigation items without list structure — screen readers can't announce "item 3 of 7"
Toggles missing aria-expanded — users can't tell if a menu is open or closed
Icon-only buttons with no accessible name — invisible to assistive technology
Modals without focus trapping — keyboard users get lost behind the overlay

This isn't a bug that'll get fixed in the next model update. It's structural: AI training data skews toward <div>-heavy code, evaluation feedback is visual-only, and token economics favor shorter, less semantic output. Theresearch backs this up.

This is exactly why every line of our code is a decision.Using <nav> instead of<div class="nav"> is a decision. Using<button> instead of<div onClick> is a decision. Unreviewed AI output doesn't make those decisions — it makes the statistically likely choice, which is almost always the wrong one for accessibility. We use AI as a tool, but every element gets reviewed for semantic correctness.

As more of the web gets generated without that review step, the accessibility gap is going to widen. Sites that are intentionally built — semantic HTML, proper ARIA, keyboard-first interaction — will stand out even more. That's where we are, and that's where we're staying.

Common questions