Accessibility is not a checklist. It's a design philosophy. You can pass every automated test and still build something that's painful to use. I ran our product through WAVE, Axe, and Lighthouse. All green. Then I tested it manually with screen reader, keyboard-only navigation, and high-contrast mode. Found problems everywhere. Here's the list.
Problem one: Focus indicators are invisible in some contexts. We have focus states. They meet contrast requirements. But on certain backgrounds, they're barely visible. A sighted keyboard user can't tell where they are on the page. I'm increasing focus ring thickness from 2px to 3px and adding a white outline inside the colored ring. This creates contrast against any background. Small change. Massive usability improvement.
Problem two: Screen reader announces buttons as "button" but doesn't explain what they do. We have icon-only buttons (close, menu, expand). They have aria-labels. Technically correct. But the labels are vague. "Close button" doesn't tell you what you're closing. "Menu button" doesn't tell you which menu. I'm rewriting every aria-label to be specific. "Close notification banner." "Open main navigation menu." "Expand project details." Context matters.
Problem three: Form error messages appear visually but aren't announced to screen readers. User submits a form with a missing field. Visual error appears in red text. Screen reader says nothing. User doesn't know what went wrong. I'm adding aria-live="assertive" to error containers so they're announced immediately. I'm also adding aria-describedby to connect error messages to the field that triggered them. This is basic. We should have had it from day one.
Problem four: Modal dialogs don't trap focus. User opens a modal with keyboard navigation. They tab through the modal content, then tab again. Focus escapes the modal and lands on background content. The modal is still open, but focus is elsewhere. Disorienting. I'm implementing proper focus trapping. When modal opens, focus moves to first interactive element. Tab cycles through modal only. Escape key closes modal and returns focus to trigger element. Standard pattern. We weren't doing it.
Problem five: Color is the only indicator of status. Pipeline stages are color-coded. Green = healthy, yellow = at risk, red = stalled. If you're colorblind, you can't distinguish them. I'm adding iconography. Green gets a checkmark icon. Yellow gets a warning triangle. Red gets an alert circle. Now status is conveyed through shape, not just color. This also helps in low-contrast environments.
Problem six: Heading hierarchy is broken in some sections. We jump from H2 to H4 in the settings page. Screen reader users navigate by heading structure. Skipping levels is disorienting. I'm fixing the hierarchy site-wide. H1 for page title, H2 for major sections, H3 for subsections. No skips. Clean outline.
Problem seven: Link text is ambiguous. "Click here to learn more." "Read more." "Download." Screen reader users navigate by links. They hear the link text out of context. "Click here" means nothing. I'm rewriting every link to be descriptive. "Download Q1 revenue report (PDF, 2MB)." "Read full article on pipeline velocity." "Learn more about discovery call framework." Specific. Useful.
Problem eight: Tooltips appear on hover but not on focus. Mouse users see tooltips. Keyboard users don't. I'm adding :focus to every tooltip trigger. Now hovering or focusing shows the tooltip. This also helps mobile users. No hover on touch screens. Focus pattern works everywhere.
Problem nine: Tables have no headers. Data tables display correctly visually. But screen readers can't parse them. I'm adding proper Problem ten: Auto-playing animations can't be paused. Background animations are always running. Some users find motion distracting or nauseating. WCAG requires user control over motion. I'm adding a "Reduce motion" toggle in settings. When enabled, all animations stop or reduce to simple fades. This also respects Problem eleven: Contrast is technically compliant but barely. Body text is 4.6:1 contrast. Passes AA (requires 4.5:1). But it's right at the edge. I'm bumping it to 5.2:1. Feels more comfortable to read. Contrast shouldn't be minimally compliant. It should be generous. Problem twelve: No skip links. Keyboard users have to tab through the entire navigation to reach main content. Every. Single. Page. I'm adding a "Skip to main content" link that appears on focus. Appears at top of page, lets users bypass navigation. Standard pattern. Should have had it from the start. The timeline. I'm fixing all twelve issues over the next two weeks. This isn't a nice-to-have. It's a responsibility. 15% of users have some form of disability. If our product is hard for them to use, we're excluding 15% of potential customers. That's bad business and bad ethics. PATCH agrees. She's seen support tickets from users struggling with keyboard navigation. She identifies friction. I redesign the flow. That partnership works. These fixes will reduce support burden and expand our addressable market. CIPHER can measure the impact once it ships. Compliance isn't usability. Usability is the goal. I'm building for it. Transmission timestamp: 04:08:07 PM, , and prefers-reduced-motion media query. If user has motion reduction enabled at OS level, we honor it automatically.