Explore
Accessibility for Early-Stage Products: What Actually Matters

Accessibility for Early-Stage Products: What Actually Matters

Accessibility can feel overwhelming. For an early-stage product, it doesn't need to be. Here's the 20% of effort that covers 80% of the impact.

Accessibility for Early-Stage Products: What Actually Matters

Accessibility often gets framed as a compliance requirement — something you add before a legal review or a large enterprise contract. That framing is both too narrow and too late.

The real case for accessibility in early-stage products is simpler: it makes your product work for more people, and most of the high-impact work takes almost no extra time when done from the start.

Here's the practical shortlist for an MVP.

Keyboard navigation

Every interaction that works with a mouse should work with a keyboard. Tab to focus, Enter or Space to activate, Escape to close.

This matters for:

  • Users who can't use a mouse (motor disabilities)
  • Power users who prefer keyboard navigation
  • Screen reader users (who navigate primarily by keyboard)

In practice:

  • Use semantic HTML (<button>, <a>, <input>) — these have keyboard support built in
  • Don't remove :focus-visible styles (the tab outline). Style it to match your design, but don't remove it
  • For custom components (dropdowns, modals, date pickers), implement keyboard behaviour manually or use an accessible primitive library like Radix Vue

Semantic HTML

The browser gives you a lot of accessibility for free — if you use the right elements.

<button> announces itself to screen readers as interactive. <div onclick> doesn't. <nav> marks a navigation region. An unstyled <div> doesn't. <h1>, <h2>, <h3> create a document outline screen reader users navigate by. Generic <div> elements don't.

The rule: use the element that semantically matches what you're building. Don't reach for a <div> when a <button>, <article>, <section>, <label>, or <input> is more appropriate.

Colour contrast

Low contrast between text and background is the most common accessibility issue in SaaS products — and one of the easiest to fix.

WCAG AA requires:

  • 4.5:1 contrast ratio for normal text
  • 3:1 for large text (18px+ regular, 14px+ bold)

Check your colour combinations with a contrast checker (browser extension or the built-in check in Figma). Your brand colours might not meet contrast ratios — it's better to discover this in Figma than after you've built the product.

Form labels

Every form input needs a visible label. Not a placeholder. A label.

Placeholders disappear when you type. When they're the only indication of what an input is for, users — especially screen reader users — lose context the moment they start typing.

<!-- Wrong -->
<input type="email" placeholder="Email address">

<!-- Right -->
<label for="email">Email address</label>
<input id="email" type="email" placeholder="jane@example.com">

If you want a visually minimal form without visible labels, use a visually-hidden label (visible to screen readers, not to sighted users). Don't skip the label entirely.

Focus management in dynamic UIs

Modern web apps are full of dynamic content: modals, drawers, toasts, multi-step forms. Each of these needs deliberate focus management.

Opening a modal: Move focus to the first interactive element inside the modal.

Closing a modal: Return focus to the element that opened it.

Form errors: Move focus to the first field with an error, or to an error summary at the top.

Without this, keyboard users lose their place in the UI every time something changes. It's a significant usability problem that's invisible to anyone testing with a mouse.

Alt text for images

Every meaningful image needs alt text that describes what it communicates. Decorative images (icons, background textures) should have alt="" to be ignored by screen readers.

<!-- Meaningful image -->
<img src="dashboard.png" alt="The analytics dashboard showing page views, sessions, and conversion rate">

<!-- Decorative -->
<img src="wave-bg.svg" alt="">

Product screenshots in your landing page are often overlooked here. A screen reader user visiting your marketing site should get the same information from alt text that a sighted user gets from the screenshots.

What to skip for now

You don't need to achieve WCAG AA compliance across every corner of your product before launch. The highest ROI items are above. What you can defer:

  • Full WCAG 2.1 AA audit (do this before an enterprise sales motion)
  • ARIA patterns for highly complex interactions (get the basics right first)
  • Automated accessibility testing in CI (helpful, but not an early-stage priority)

The tooling that helps

  • axe DevTools browser extension — scans your page and highlights accessibility issues with explanations
  • Keyboard testing — close your trackpad and navigate your product with Tab, Shift+Tab, Enter, Escape. This is the fastest way to find keyboard navigation issues.
  • Screen reader — VoiceOver (Mac), NVDA (Windows), or Orca (Linux). Use it with eyes closed for 10 minutes and you'll learn things about your product you didn't know.

The honest case

Accessible products serve more users, work better on diverse input methods, and tend to have cleaner code (semantic HTML is structurally better HTML). The cost of getting it right from the start is low. The cost of retrofitting it later is high.

For an early-stage product, the ceiling isn't full WCAG compliance — it's "this works for everyone using our most important journeys." That's achievable in a day of focused attention.

Building a product that works for everyone? Let's build it right →

Back to all articles