TL;DR
We build better digital experiences when we treat accessibility as a core part of user experience design.
A 90-minute audit covers keyboard navigation, focus states, contrast, forms, and media elements.
Quick wins can improve experiences fast: use native controls, add proper labels, make targets at least 24×24 pixels, and ensure 4.5:1 text contrast.
We tie fixes to WCAG 2.2 AA standards for keyboard support and visible focus indicators.
Key priorities before design lock:
- Skip links for navigation
- Helpful error messages
- Target size requirements
- Contrast standards
Ethics matter here—privacy protection, accessibility compliance, and avoiding manipulative design patterns all help build trust with users.
Quick definitions (one line each)
Web Content Accessibility Guidelines (WCAG): Standards to make websites usable for people with disabilities; AA level is the usual target.
Keyboard access: Navigating a website using only Tab, Shift-Tab, Enter, Space, and Arrow keys—no mouse needed.
Focus management: How the visible cursor moves between clickable elements and how users get around a page.
Color contrast: The difference between text and background colors, measured as a ratio—4.5:1 or higher is best for readability.
Semantic HTML: Using real HTML elements like <button>, <label>, and <nav> that have built-in meaning and accessibility.
ARIA: Special attributes we add to HTML elements to give screen readers extra info when standard elements can’t do the job.
Alt text and captions: Written descriptions for images and videos to help users who can’t see or hear the content.
The PM’s 90-minute accessibility audit (end-to-end)
1) Keyboard-only walkthrough (30 min)
First, we unplug the mouse and navigate the product using only the keyboard.
This hands-on approach shows how users with motor disabilities experience our product.
Key actions to test:
- Tab through all interactive elements
- Use Enter and Spacebar to activate buttons and links
- Navigate forms with Tab, Shift+Tab, and arrow keys
- Test dropdown menus and modal dialogs
We document every element we can’t reach with the keyboard.
We also note where the tab order feels weird or out of place.
Common issues we look for:
- Buttons that don’t react to Enter or Spacebar
- Content that appears on hover but not on focus
- Keyboard traps where users get stuck
- Missing skip links on long pages
We snap screenshots of problem spots and jot down steps to reproduce each issue.
2) Focus management & order (15 min)
We check how focus moves through the interface and whether it follows a logical pattern.
Focus indicators need to be visible and easy to spot on all interactive stuff.
Focus indicator checklist:
- All focusable elements show visible focus rings
- Focus indicators meet color contrast standards
- Custom focus styles work in every browser
- Focus never disappears or becomes invisible
We test tab order by moving through each page step by step.
Usually, focus should flow from top to bottom and left to right.
Special focus scenarios:
- Modal dialogs keep focus inside until closed
- Focus returns to the trigger after closing overlays
- Error messages get focus when they show up
- Dynamic content doesn’t break focus flow
3) Contrast & target size check (10 min)
We use browser dev tools or contrast checkers to make sure color combos meet WCAG standards.
All text needs enough contrast against its background.
Minimum contrast ratios:
- Normal text: 4.5:1
- Large text (18pt+ or 14pt+ bold): 3:1
- Non-text elements: 3:1 for important graphics and UI bits
We measure clickable targets to check they hit the right size.
Interactive elements should be at least 44×44 pixels for touch.
Target size evaluation:
- Buttons and links have enough space
- Form controls are easy to tap
- Icon-only buttons meet minimum size
- Targets aren’t crammed together
4) Forms, labels, and errors (15 min)
We review all forms to check for proper labeling and error handling.
Every field needs a clear, programmatic label.
Form accessibility requirements:
- All inputs have connected labels
- Required fields are clearly marked
- Placeholder text doesn’t replace labels
- Fieldsets group related controls
We test error handling by submitting incomplete or invalid forms.
Error messages should be clear and help users fix things.
Error message standards:
- Errors show up near the right fields
- Messages explain what happened and how to fix it
- Required field errors are specific
- Success messages confirm actions
We check that screen readers can understand form structure and requirements using manual keyboard navigation.
5) Motion, media, and interruptions (10 min)
We look for any moving, flashing, or auto-updating content that could cause problems.
Motion can trigger vestibular disorders or even seizures for some.
Motion and animation review:
- Auto-playing videos have pause controls
- Carousels and slideshows can be stopped
- Parallax scrolling can be turned off
- Animations respect system motion settings
We check that users can control interruptions and time limits.
Auto-advancing content should pause if users interact.
Media accessibility features:
- Videos have captions or transcripts
- Audio content has text alternatives
- Auto-play media starts muted
- Time limits can be extended or turned off
6) Summarize & assign (5 min)
We pull together our findings into a prioritized list of accessibility issues.
Each issue gets a severity level and a rough estimate for fixing it.
Issue priority levels:
- Critical: Blocks core functionality for disabled users
- High: Major barriers but some workarounds exist
- Medium: Minor usability headaches
- Low: Nice-to-have improvements
We assign each issue to a team member and set a target date.
Critical issues should go into the current sprint if possible.
The audit summary includes the total number of issues and estimated fix timeline.
We set up follow-up testing to make sure our fixes actually work.
Quick wins to prioritize before design lock
We should focus on simple changes with big impact.
Start with native HTML elements like <button>, <a>, and <input> since they come with built-in accessibility.
Keep focus outlines visible and style them to fit our brand.
Boost contrast on text, icons, focus rings, and error messages to meet WCAG standards.
Make clickable targets at least 24×24 pixels.
Always connect labels to form fields using for and id attributes.
Add skip links and use <header>, <nav>, <main>, and <footer> for page structure.
Don’t rely on color alone to show meaning—use icons or text for required fields and errors.
Offer tap and click options for any drag-and-drop features.
Trade-offs you’ll face
Building accessible products means making smart choices about product strategy.
We face decisions that shape our product management approach.
Native controls give us free accessibility but limit how much we can style.
Custom widgets look great but can break accessibility if we’re not careful.
For testing, automated scans are fast but miss user flow problems.
Overlays patch things up quickly but don’t fix the real code issues underneath.
| Choice | Best for | Risk |
|---|---|---|
| Strict WCAG AA now | Regulated products | More work upfront |
| Defer to post-MVP | Speed-focused launches | Expensive fixes later |
We should use native controls first, then enhance only when needed.
Pair automated testing with manual checks for the best coverage.
Worked example: prioritize fixes with simple math
We use a small RSE score to rank accessibility issues.
The formula is pretty straightforward:
RSE = Reach × Severity ÷ Effort
Reach means the percent of user sessions that hit the problem this quarter, written as a number from 0 to 1.
Severity has three levels: 3 points if it blocks a task, 2 for high friction, 1 for minor issues.
Effort is how much work the fix needs—1 for small, 2 for medium, 3 for large fixes.
Here are two real examples:
A keyboard trap on the checkout button affects 25% of sessions. This blocks users with disabilities from buying products. Reach is 0.25, severity is 3, effort is 1. The RSE score is 0.75.
Low-contrast text on a marketing card affects 60% of sessions. It causes minor reading problems. Reach is 0.60, severity is 1, effort is 1. The RSE score is 0.60.
We fix the checkout trap first—it blocks revenue and hurts more users per unit of effort.
Realistic examples (≤5 lines each)
Enterprise Admin Tools
We fixed keyboard navigation issues in an export feature. The modal lost focus and used generic divs instead of real buttons.
We switched to native <button> elements and restored focus. We also added field labels, focus rings you can actually see, and aria-live regions for feedback.
Support tickets dropped by 41%. Completion time fell by 22%.
Contrast ratios stayed above 4.5:1, and error rates didn’t budge.
Fitness App Onboarding
We saw low user activation because of placeholder-only forms, tiny touch targets, and motion-triggered nausea. The onboarding flow left out people with motor difficulties and vestibular disorders.
We made tap targets bigger—44×44 pixels. Labels were added, reduced-motion options built in, and video captions included.
Day-7 activation improved by 2.3 percentage points. Complaints dropped by 0.4 points.
Accessibility defects stayed under 0.5 per 1,000 monthly active users.
How to bake accessibility into your PRD and rollout
Add accessibility requirements to PRDs under non-functional specs. This means visible focus rings, text contrast at 4.5:1 or higher, proper field labels, modal focus restoration, reduced-motion options, and captions for media.
Acceptance criteria should call out keyboard navigation and screen reader support. For example, “User can complete flow using keyboard only” or “Screen reader announces error and fix.”
Track complaint rates, accessibility defect counts, and form abandonment by input method in analytics. Don’t skip this step—it’s easy to miss real issues otherwise.
For rollout, put features behind flags and set clear thresholds. If complaint rates go over 0.3% or error rates jump above 0.5% for exposed users, stop or roll back.
Keep a 5-10% holdback group for 1-2 weeks after launch. This helps catch regressions before everyone sees them.
Ethics & guardrails (non-negotiable)
We never track health or disability status. Sensitive personal data gets minimized, always.
Our products ship with WCAG 2.2 AA standards built in. Every feature gets tested with keyboard navigation and screen readers before launch.
We never use dark patterns. No hidden prices or fake countdown timers—tricking users is out.
Critical safety and support features stay accessible to everyone, no matter their vision, hearing, or motor abilities.
Pitfalls & better alternatives
Automated audits alone don’t catch real user problems. Pair them with keyboard navigation and screen reader tests.
Custom controls usually break accessibility rules. Start with native HTML elements. Only use ARIA when you really can’t avoid it.
Placeholders replacing labels trip up users and assistive tech. Always use real <label> elements. Placeholders are just hints, not names.
Removing focus outlines makes life harder for keyboard users. Style focus rings—don’t hide them.
Color-only signals don’t work for colorblind users. Add icons or text with color changes. Higher contrast helps everyone, honestly.
Waiting until later makes fixes 3-5 times more expensive. Tackle major accessibility problems before designs get locked in.
Mini FAQ
Do we need WCAG 2.2 AA specifically?
Shoot for AA standards. This covers keyboard navigation, focus management, 4.5:1 color contrast, target sizes of at least 24×24 pixels, and error help messaging. It’s a solid baseline for B2B or B2C products.
If we use a design system, are we done?
Nope. Design systems help but don’t guarantee perfect accessibility. Problems still slip in—focus traps, missing labels, contrast overrides. You still need to test real user flows, even with a polished system.
Are accessibility overlays enough?
No way. Overlays don’t fix the source code and sometimes add new barriers. Treat them as a band-aid while you fix the real issues.
Do PMs need to master screen readers?
Just do some basic smoke testing. Turn on the screen reader, run through key flows, and check that important announcements work. Leave the detailed stuff to QA and UX accessibility pros.
How do we prioritize long accessibility lists?
Use the RSE formula: Reach × Severity ÷ Effort. Fix flow-blockers first, then contrast and labeling, then polish the rest as you go.
Copy-ready 90-minute audit checklist
Keyboard Navigation (15 minutes)
- Try out all user flows using just Tab, Enter, Space, and arrow keys. It can feel tedious, but it’s the only way to spot real issues.
- Watch for focus traps that stop keyboard users from moving forward. If you hit a wall, that’s a red flag.
- Hit Escape to see if modals and dialogs actually close. Sometimes they just… don’t.
- After closing a modal, does focus land back on the trigger element? It should, but sometimes it ends up lost somewhere else.
Focus Management (20 minutes)
- Check if focus indicators have a contrast of at least 3:1 compared to their backgrounds. If you can’t see it, neither can anyone else.
- Tab through the interface and see if the order makes sense. Logical flow really matters here.
- Look for a “Skip to main content” link at the top of each page. If you can’t find it, that’s a problem.
Visual Design Standards (25 minutes)
- Test text contrast ratios. Regular text needs 4.5:1, while large text only needs 3:1. It’s surprising how often this gets missed.
- Measure buttons and links to confirm they’re at least 24×24 pixels. Tiny targets are just frustrating.
- Make sure color isn’t the sole way to communicate something important. If it is, that’s going to trip people up.
Form Accessibility (15 minutes)
- Check that every form label is connected to its input field. If they’re not, screen readers won’t help much.
- Test error messages with a screen reader to make sure they’re announced. Silence here is not golden.
- Review live validation and see if it messes with assistive tech. Sometimes it just gets in the way.
Media and Motion (10 minutes)
- See if animations respect the user’s Reduce Motion settings. Fast movement can be a real issue for some.
- Check that all videos have captions. It’s basic, but often skipped.
- Look at images—do meaningful graphics have alt text? Decorative ones shouldn’t.
- Make sure nothing auto-plays with sound. That’s just annoying, right?
Documentation (5 minutes)
- Log every issue with a severity level and the matching WCAG reference. Details matter.
- Assign an owner for each accessibility problem. Otherwise, things fall through the cracks.
- Create tickets before finalizing designs. Don’t leave it for “later”—it never happens.
