Accessibility Audit Checklist for Modern Web Apps (WCAG-First, Dev-Friendly)

Accessibility audits don’t need to feel like a giant compliance project. For modern web apps, they work best when they’re treated like part of product quality, right alongside performance, security, and usability. That’s the mindset I’d start with every time.

If you’re building a SaaS product, a customer portal, or a complex dashboard, an accessibility audit checklist gives your team a clear way to catch issues before users do. And yes, users do notice. A missing label, a broken focus state, or a modal that traps keyboard users can turn a polished app into a frustrating mess fast.

The good news? You don’t need to boil the ocean. A strong audit process can be practical, repeatable, and dev-friendly. That’s what this list is about.

Why accessibility audits matter more than ever

Modern web apps are dense. They’ve got nested navigation, live data tables, filters, drawers, dialogs, and lots of dynamic states. That’s exactly where accessibility breaks down.

A solid accessibility audit checklist helps you:

Catch issues early, before they get buried in product polish
Improve the experience for keyboard and screen reader users
Reduce legal and compliance risk
Make design systems cleaner and easier to scale
Build products that feel more refined for everyone

Personally, I think accessibility is one of the clearest signs that a team cares about craft. A product can look great and still fail people in the first 10 seconds. Why build something that only half-works?

If you’re building with a startup mindset, accessibility also protects your roadmap. It’s cheaper to fix patterns in a component library than to patch the same bug across 40 screens later. That’s why teams working with a partner like Lunar Labs’ web development team often benefit from baking accessibility into the build process instead of treating it like a cleanup pass.

How to use this accessibility audit checklist

You don’t need to run every check in one giant marathon. I’d break it into layers:

Design review: catch structural and visual issues before code ships
Component audit: test reusable UI elements in isolation
Page-level audit: inspect real workflows and edge cases
Manual testing: keyboard, screen reader, zoom, and contrast checks
Regression review: confirm fixes hold after new releases

A checklist works best when it’s tied to specific ownership. Designers should know what to look for. Developers should know which patterns are safe. Product managers should know which bugs block release. That shared responsibility keeps accessibility from becoming one person’s side quest.

1. Check semantic structure first

Before you touch fancy tools, look at the page structure. This part matters more than people think.

What to verify

One clear <h1> per page
Heading levels follow a logical order
Landmarks exist where they make sense: header, nav, main, footer
Lists are coded as lists
Buttons are buttons, not clickable divs
Links are links, not styled buttons pretending to be links

If the semantics are wrong, assistive tech users have to work harder to understand the page. That’s not a small issue. It’s the foundation.

My opinion? This is the easiest accessibility win and the one teams skip most often. Fixing semantics usually improves SEO and maintainability too, so there’s almost no downside.

2. Make sure every interactive element is keyboard accessible

If someone can’t use your app without a mouse, the experience is incomplete. Full stop.

Test these things

Can you tab through every interactive element?
Does the focus order match the visual order?
Can you trigger buttons with Enter and Space?
Can you close dialogs with Escape?
Can you move through menus, tabs, and date pickers using only the keyboard?

Keyboard testing exposes real problems fast. Try it on a login form, a pricing calculator, or a settings panel. If focus disappears or lands somewhere random, users will feel it immediately.

A lot of teams assume that “clickable” means usable. It doesn’t. I’ve seen beautiful interfaces fail the first keyboard pass because someone used a div for a custom control and never wired up the behavior properly.

3. Inspect focus states and focus visibility

Focus indicators are one of the most overlooked pieces of UI. They’re also one of the most important.

Audit checklist

Every interactive element has a visible focus state
Focus styles aren’t removed without a replacement
Focus contrast is strong enough to see on light and dark backgrounds
Focus rings don’t get cut off by overflow or layout constraints
Modal dialogs trap focus correctly and return it to the trigger on close

A hidden focus outline is a classic mistake. So is a focus ring that’s technically there but practically invisible because it blends into the background. That’s bad UX, not just bad accessibility.

If you use a design system, make focus styles part of the component spec. Don’t leave them to chance. That’s the kind of detail that separates a decent UI from one that feels intentional.

4. Review color contrast and visual readability

Color contrast affects users with low vision, color blindness, and anyone trying to read in bad lighting. Which is, honestly, most of us at some point.

Check for

Text contrast meets WCAG requirements
Icons that convey meaning also have enough contrast
Placeholder text isn’t doing the job of a label
Disabled states are still distinguishable, but not unreadably faint
Status colors work with more than just color alone

I’m a big fan of design systems here because they make contrast easier to standardize. If your primary button passes contrast on one page and fails on another, the system needs work.

Remember that contrast isn’t only a text issue. Form borders, chart labels, chips, badges, and empty states all need a quick look too.

5. Audit forms with extra care

Forms are where accessibility problems love to hide. They’re also where users care the most, because forms usually mean signups, payments, onboarding, or critical updates.

Your accessibility audit checklist for forms

Every input has a programmatic label
Required fields are clearly marked
Instructions appear before the field, not only in placeholder text
Error messages explain what went wrong and how to fix it
Errors are announced to screen readers
Validation doesn’t rely on color alone
Grouped controls, like radio buttons and checkboxes, use fieldsets and legends where appropriate

Real example: if a user enters an invalid email, “Invalid input” isn’t enough. Better would be: “Enter a valid work email address, like name@company.com.” That’s specific, useful, and less frustrating.

Personally, I think forms reveal the quality of an entire product team. If the form experience is sloppy, there’s a good chance the rest of the interaction model is too.

6. Check all custom components and patterns

Modern web apps love custom UI. Tabs, comboboxes, dropdowns, modals, tooltips, sliders, accordions, toast systems. Great for product flexibility, risky for accessibility.

For each custom component, confirm

It has the correct roles, states, and properties
It behaves predictably with keyboard input
It announces changes clearly to assistive tech
It works at different viewport sizes
It doesn’t rely on hover alone

Custom components are where teams often need a tighter collaboration between design and engineering. If you’re building a component library or reworking an app shell, Lunar Labs’ design services can help turn those patterns into something consistent and accessible from the start.

One quick note: if a native HTML element can do the job, use it. Native controls come with behavior you’d otherwise have to recreate and maintain. That’s a lot of work for no real prize.

7. Test screen reader support on core workflows

You don’t need to become a screen reader expert overnight, but you do need to test the main user paths.

Start with these workflows

Sign up or log in
Search and filter content
Edit a profile or settings screen
Submit a form with errors
Open and close a dialog
Switch tabs or change views

Look for:

Meaningful labels
Correct reading order
Announced state changes
Helpful button names
No duplicate or confusing announcements

A screen reader should help someone understand the UI, not turn every action into a guessing game. If a button says “Submit” in the visual UI but “button” to the screen reader, that’s a problem. If a toggle changes visually but doesn’t announce its state, that’s a problem too.

My take: this is one of the most humbling parts of the audit. It forces you to experience the product differently, and that usually exposes hidden assumptions fast.

8. Verify responsive behavior and zoom support

Accessibility doesn’t stop at screen readers. Users zoom, resize text, rotate devices, and use small screens all the time.

Check the following

The interface still works at 200% zoom
Text reflows without horizontal scrolling where possible
Content doesn’t overlap or get clipped
Sticky headers and sidebars don’t block important controls
Touch targets are large enough on mobile
Orientation changes don’t break the layout

This matters a lot in dashboards and web apps packed with data. Tables often break first. Side panels often get cramped. Fixed-position elements often cover content. It’s the kind of thing that looks fine in a desktop Figma frame and falls apart in real use.

Responsive accessibility is one reason strong product teams value strategy and discovery work early on. It helps define constraints before the interface gets locked in and expensive to change.

9. Review motion, animation, and timing

Motion can make an app feel polished, but it can also make it harder to use.

Audit for

No essential information is conveyed by animation alone
Animations are subtle and purposeful
Motion can be reduced for users who prefer it
Auto-advancing content can be paused or stopped
Timed interactions don’t punish slower users

A flashy interface isn’t always a better interface. I’d rather see one clean transition than a dozen decorative animations that slow down the task.

If your product uses motion to communicate state, make sure it still works when animations are disabled or reduced. Otherwise, some users lose context the moment the UI changes.

10. Check content clarity and link purpose

Accessibility isn’t just code. It’s language too.

Look for

Clear, specific link text
Buttons that describe the action
Avoiding “click here” and “read more” without context
Plain language in labels, errors, and instructions
Consistent terminology across screens

For example, “View invoice for March 2026” is better than “View more.” That tiny change makes the interface easier to scan with sight and easier to understand with assistive tech.

I’d also review empty states and helper text carefully. These screens are often written late, which means they can end up vague or inconsistent. A little editorial discipline goes a long way.

11. Audit media, charts, and non-text content

Charts, videos, icons, and image-based UI can be a pain point if they’re not handled with care.

Confirm

Images have useful alt text or are correctly marked decorative
Icons that carry meaning have accessible labels
Charts include text summaries or data tables when needed
Videos have captions
Audio has transcripts when appropriate

If your app uses analytics dashboards or financial data, this step matters a lot. A chart without a textual fallback can leave users guessing. That’s not acceptable when the interface is supposed to help them make decisions.

12. Validate error handling, alerts, and live updates

Modern apps rely on dynamic updates everywhere. That’s great until users miss what changed.

Review

Inline errors are tied to the relevant inputs
Global alerts are announced appropriately
Success and failure states are clear
Live regions aren’t overused
Async loading states are visible and understandable

The tricky part here is balance. If every tiny update gets announced, the app becomes noisy. If nothing gets announced, users miss important feedback. I like to think of it as signal, not chatter.

This is especially relevant in SaaS products where users are dealing with long sessions, saved states, filters, and background updates. The UI needs to tell the truth about what’s happening.

13. Check automation, but don’t trust it blindly

Automated tools are useful. They catch obvious issues fast. But they won’t tell you whether the experience actually makes sense.

Use automation to catch

Missing labels
Contrast failures
Invalid ARIA usage
Broken heading structure
Some keyboard and landmark issues

Then do the manual part. Every time.

My personal rule: if a tool says the page passed, I still test the actual workflow. A green report doesn’t mean the UI is usable. It just means the obvious problems didn’t trip the scanner.

14. Document fixes and turn them into patterns

An accessibility audit should leave your product better than it found it. But it should also make the next release easier.

Record

What failed
Where it failed
Why it failed
How it was fixed
Whether the fix should become a design-system pattern

This is where teams start to mature. One broken modal becomes a reusable accessible modal. One confusing error message becomes a content guideline. One form issue becomes a validation rule for the whole app.

That’s the difference between patching and improving.

A practical workflow for running your next audit

If you want a process that won’t fall apart mid-sprint, I’d use this order:

Review the highest-traffic user flows
Check semantics and keyboard behavior
Test forms, dialogs, and navigation
Scan for contrast and responsive issues
Run screen reader checks on key tasks
Log findings with screenshots or short recordings
Prioritize by user impact, not just effort
Fix patterns in the shared component library
Re-test before release

That workflow keeps the work focused. You’re not just checking boxes. You’re improving the product where it actually matters.

Make accessibility part of product quality, not a separate cleanup phase

The best accessibility audit checklist is the one your team can actually use every sprint. It should be specific enough for developers, clear enough for designers, and practical enough for product managers to support.

If you’re building a startup product, a SaaS platform, or a web app with serious growth plans, accessibility isn’t extra polish. It’s part of making the product trustworthy. Users feel that difference.

Ready to build a more accessible web app?

If your team wants help turning accessibility from a one-off audit into a repeatable product standard, Lunar Labs can help. We partner with ambitious teams on strategy, design, and development, and we care about the details that make digital products easier to use and easier to scale.

Explore our web development services if you need a team that can build accessibility into the product from day one. If you’re still shaping the product direction, start with strategy and discovery to align accessibility, UX, and engineering before the first release.

Want a partner who thinks about the whole product, not just the screens? That’s where we do our best work.