Designing for Accessibility in Web Apps: A Practical Checklist for Product Teams

Accessibility gets ignored a lot in product planning. That’s a mistake.

If you’re building a web app, accessibility isn’t a nice-to-have polish pass you do right before launch. It affects whether people can sign up, pay, complete tasks, or even understand what’s on the screen. And if your product team has ever shipped a feature that looked great in Figma but fell apart with a keyboard, a screen reader, or just a smaller browser window, you already know the pain.

That’s why designing for accessibility in web apps needs to be part of the process from day one. Not as a compliance chore. Not as a cleanup sprint. As a product quality standard.

I’ve seen teams save weeks of rework by baking accessibility into design reviews, component decisions, and QA checklists early. I’ve also seen the opposite: beautiful interfaces that block users, frustrate support teams, and slow down growth. Which version would you rather have?

Why accessibility belongs in product planning

Accessibility usually gets framed as a legal requirement or a social responsibility. Fair enough. It’s both. But for product teams, the bigger reason is simpler: accessible apps are easier to use for more people.

Think about it. A user with low vision isn’t the only one who benefits from clear contrast and readable text. A keyboard-first power user does too. Someone on a cracked phone screen, in bright sunlight, or using a trackpad with shaky precision also gets a better experience. That’s just good product design.

From a business perspective, accessibility helps with:

• Lower abandonment during onboarding and checkout
• Fewer support tickets about broken flows
• Better usability across devices and input methods
• Stronger performance in regulated industries
• A product culture that catches friction earlier

My opinion? Teams that treat accessibility as part of product thinking build sharper interfaces overall. They stop designing for the ideal user and start designing for actual humans.

Start with the right mindset: accessibility is a system, not a feature

A common trap is assuming accessibility can be “added” later. You can add labels. You can patch contrast. You can fix focus states. But if the core design system ignores accessibility, you’ll keep creating new problems every sprint.

That’s why designing for accessibility in web apps works best when product, design, and engineering share responsibility.

Here’s the simple version:

• Product defines accessible requirements in scope
• Design creates accessible patterns and states
• Engineering implements semantic, keyboard-friendly components
• QA tests real interactions, not just static screens

If one of those steps is missing, the whole thing becomes fragile.

For teams building SaaS products, this often starts with a clear strategy. Our work at Lunar Labs strategy and discovery often surfaces these risks before a single line of code gets written. That early clarity makes the rest of the process a lot cleaner.

A practical accessibility checklist for product teams

Here’s the part you can actually use.

1. Define accessible requirements before design starts

Don’t wait for the UI to exist. Decide what “accessible” means for the product.

At minimum, your requirements should cover:

• Keyboard support for all core flows
• Visible focus indicators
• Color contrast that meets WCAG standards
• Screen reader support for meaningful content and controls
• Clear error handling and recovery
• Responsive layouts that work at common zoom levels
• Touch targets large enough for mobile users

I’d push teams to document these alongside functional requirements. If “users can reset their password” is in scope, then “users can reset their password with keyboard and screen reader support” should be in scope too.

2. Design with semantic meaning, not just visual style

A lot of accessibility problems begin in Figma. Not because designers don’t care, but because visual mockups can hide structure.

Design should clarify:

• What’s a button vs. a link
• Which heading levels create the page hierarchy
• Which form fields are required
• What error state appears after invalid input
• Which elements need persistent labels versus placeholder text
• How modals, drawers, and menus behave

One thing I always recommend: design states, not just happy-path screens. Include hover, focus, disabled, loading, empty, and error states in the same file or component library. If a state doesn’t exist in design, it usually gets invented badly in code.

3. Use color carefully

Color alone should never carry meaning. Ever.

If an error only appears as red text, you’ve already lost some users. If a chart depends on color alone, some people won’t be able to read it. If a CTA is distinguishable only by hue, that’s a problem too.

A better approach:

• Pair color with labels, icons, or text
• Check contrast on text, buttons, borders, and UI controls
• Avoid low-contrast gray-on-gray interfaces
• Test dark mode separately, not as an afterthought

Personally, I think color contrast is one of the easiest accessibility wins. It’s also one of the most overlooked. Strange, right? Teams will spend hours polishing gradients, then ship a critical button that barely clears the background.

4. Make keyboard navigation a first-class path

If a user can’t operate your app with a keyboard, your app isn’t fully usable.

That means every interactive element should be reachable and usable with:

• Tab
• Shift+Tab
• Enter
• Space
• Arrow keys where appropriate
• Escape for dismissing overlays and menus

Check these patterns carefully:

• Dropdown menus
• Multi-step forms
• Date pickers
• Dialogs and modals
• Tooltips
• Sidebars
• Tab interfaces

A lot of modern component libraries look accessible until you try tabbing through them. Then the cracks show. I’ve seen entire workflows stall because focus disappeared into a modal and never returned. That’s not a minor bug. It’s a broken product path.

5. Label everything clearly

Placeholder text is not a label. Icons are not self-explanatory. “Click here” is not a useful CTA.

Strong labels help everyone, but they’re essential for screen reader users. Every input should have a visible label that describes exactly what goes in the field. Error messages should explain the problem and how to fix it.

For example:

• Bad: “Invalid input”
• Better: “Enter a valid email address”
• Better still: “Please enter an email address in the format name@example.com”

The same goes for buttons. “Submit” is fine in some contexts, but “Create account,” “Save changes,” or “Continue to payment” tells users what actually happens.

6. Use headings to create real structure

Headings aren’t decoration. They’re navigation.

Screen reader users often jump through headings to understand a page. If your hierarchy is random, the page becomes harder to scan for everyone. I’d argue this matters just as much for busy product managers skimming a dashboard as it does for assistive tech users.

A sensible structure looks like this:

• One H1 per page
• H2s for major sections
• H3s for subsections
• No skipping levels just because the design looks cleaner

It sounds small, but this is one of those details that separates polished products from messy ones.

7. Design forms that fail gracefully

Forms are where accessibility either shines or falls apart.

Every form should answer a few simple questions:

• What’s required?
• What’s optional?
• What went wrong?
• How do I fix it?
• Can I recover without starting over?

Best practices include:

• Inline validation after submission or on clear interaction boundaries
• Error summaries at the top for long forms
• Field-level error messages tied to the relevant input
• Persistent text that doesn’t vanish as soon as a user types
• Support for autofill without breaking layout

If your app has onboarding, checkout, profile setup, or admin workflows, this section matters a lot. In SaaS especially, the form experience often decides whether a trial turns into an activated account.

8. Make modals and drawers behave properly

Overlays are convenient. They’re also one of the most common accessibility failure points.

A modal should:

• Trap focus while open
• Close with Escape
• Return focus to the triggering element
• Have a clear, accessible title
• Avoid stacking multiple confusing layers

Drawers and flyouts need similar care. If users can’t tell where they are, or if focus jumps around unpredictably, they’ll lose trust fast.

My take: if a component feels clever, test it twice. Clever UI often causes the most accessibility debt.

9. Test with zoom, reflow, and different devices

Accessibility isn’t just about screen readers. It’s also about layout resilience.

Check your app at:

• 200% zoom
• Narrow viewports
• High text spacing
• Reduced motion preferences
• Touch-only interactions
• Keyboard-only navigation

This is especially important for teams designing responsive web apps. A dashboard that looks clean on a MacBook can become a cramped mess on a smaller screen or under browser zoom. Users should never need to pinch and squint just to finish a task.

10. Audit interactive components before they become a design system problem

Once a bad component gets copied across a product, fixing it gets expensive.

That’s why product teams should review reusable components early:

• Buttons
• Form inputs
• Comboboxes
• Tables
• Tabs
• Toasts
• Navigation menus
• Pagination
• Date and time pickers

If you’re building on React and Next.js, this is where a disciplined component architecture pays off. Our web development services are often focused on turning these patterns into reliable building blocks, not one-off UI experiments.

Common accessibility mistakes product teams still make

Even experienced teams miss the same issues.

Placeholder-only inputs

They look tidy, but they disappear when the user starts typing. That makes forms harder to complete and review.

Tiny touch targets

A 24px icon button might look elegant. It also makes mobile users miss taps constantly.

Custom controls that mimic native ones poorly

Native HTML elements are accessible for a reason. Rebuilding a checkbox from scratch usually means redoing keyboard behavior, focus handling, and state announcements too.

Animations that ignore user preference

Motion is fine. Excessive motion isn’t. Users who prefer reduced motion should get it.

Empty states with no next step

A blank screen with a friendly sentence doesn’t help if users don’t know what to do next.

I’ve found that most of these problems come from rushing to visual completion before checking interaction quality. That’s backwards.

How product teams can make accessibility part of the workflow

You don’t need a giant process overhaul. You need a few habits that stick.

Add accessibility checks to design reviews

Before a design gets approved, ask:

• Can this be used with a keyboard?
• Is contrast strong enough?
• Are labels explicit?
• What happens in the error state?
• Does the hierarchy make sense?

Put accessibility acceptance criteria in tickets

If a feature includes a form, modal, table, or navigation change, add accessibility requirements directly to the ticket. Don’t leave it implied.

Test with real assistive tech

Static checkers are useful, but they won’t catch everything. Use:

• VoiceOver on macOS or iOS
• NVDA on Windows
• Keyboard-only navigation
• Browser zoom
• Color contrast tools

Keep a shared component library

A shared system makes it easier to get accessibility right once and reuse it everywhere. That’s a better long-term investment than fixing the same button ten times.

Train people on the basics

Designers don’t need to be lawyers. Engineers don’t need to be accessibility specialists. But everyone should know the core principles and where the common traps are.

Why this matters even more for startups

Startups usually move fast. That’s understandable. But speed without accessibility creates hidden drag later.

Broken forms increase drop-off. Confusing navigation hurts onboarding. Poor contrast makes dashboards harder to use. If your first version skips these fundamentals, you end up paying for them through redesigns, support, and lost trust.

For early-stage products, accessibility can actually be an advantage. It forces clarity. It sharpens the information hierarchy. It makes you think harder about the real user journey, not just the demo path.

That’s one reason many teams want a partner that can handle both product thinking and implementation. Lunar Labs works across design, strategy, and development, so accessibility doesn’t get treated as a separate lane from the rest of the product work. It’s part of the build.

A final checklist you can hand to your team

Before you ship, ask whether your app has:

• Keyboard support for all core interactions
• Visible focus states on every interactive element
• Sufficient color contrast
• Proper heading structure
• Clear labels for every form control
• Error messages that explain how to recover
• Accessible modals, menus, and drawers
• Touch targets that are easy to hit
• Support for zoom and responsive reflow
• Tested screen reader behavior
• Motion settings that respect user preferences
• Reusable components with accessibility built in

If you can’t confidently check those boxes, the product isn’t finished yet.

Build accessibility into the product, not around it

Designing accessible web apps isn’t about perfection. It’s about removing avoidable friction before users run into it.

The teams that do this well don’t treat accessibility as an audit at the end. They treat it as a standard for how the product should work. That mindset leads to cleaner interfaces, fewer bugs, and better outcomes for everyone who touches the app.

If you’re planning a new product or trying to improve an existing one, this is a good moment to bring accessibility into the conversation early. It’s much easier to build it in than to patch it on later.

If you’d like a partner that can help you shape the product, design accessible interfaces, and ship the thing with confidence, take a look at Lunar Labs’ design services. We help teams turn ambitious ideas into web apps people can actually use.