A bank app reads out "Unselected, Button" three times where account names should be. A telehealth session launches with the microphone muted and controls no one can find. A chat field insists it's "Read Only" while it accepts typing for every sighted user. Each of these is a real barrier a screen reader user reported firsthand, and each one stopped a task cold.
For risk managers, these aren't cosmetic defects. A barrier that blocks a bill payment, a medical appointment, or a customer service request is the kind that surfaces in ADA Title III complaints. Here are the mistakes that let them ship, and how to stop them.
Why These Mistakes Keep Happening
Most of these failures are invisible on screen. The account list looks fine. The chat field looks editable. A visual QA pass, or an automated scan, can report clean results while a Screen Reader Testing session fails in the first thirty seconds.
There's also an ownership gap. Components come from third-party vendors, design systems, and embedded widgets. Everyone assumes someone else verified the experience with Assistive Technology. Your organization still carries the liability.
Mistake 1: Treating Unlabeled Controls as a Minor Defect
Why it happens: Developers build selectable list items from generic elements and style them to look right. The visible text exists, but it isn't exposed as the control's accessible name. Nothing breaks visually, so nothing gets flagged.
Consequence: A screen reader announced each account option only as "Unselected, Button." No names, numbers, or balances. The user couldn't tell the accounts apart, and the only options were guessing or asking a sighted person for help. In a financial flow, guessing means paying from the wrong account.
Fix: Require every interactive control to expose a programmatic name that matches its visible label. That's WCAG 4.1.2 (Name, Role, Value) and 2.5.3 (Label in Name). Where visible text exists, use native elements or [aria-labelledby](/glossary/aria-labelledby) to bind it to the control. Use [aria-label](/glossary/aria-label) only when no visible text is available. Pay special attention to selection lists for accounts, saved cards, and addresses.
Mistake 2: Assuming Embedded Third-Party Tools Are Someone Else's Problem
Why it happens: Video conferencing and chat widgets are procured as finished products. Teams assume the vendor handled accessibility, and nobody tests the actual launch experience.
Consequence: In the telehealth case, the meeting controls for the microphone, camera, and messaging were never spoken Assistive Technology all, and focus couldn't be moved to them. The microphone started muted, so the patient couldn't speak to the provider. After a few minutes of troubleshooting, the appointment Web Accessibility Specialist rescheduled with a provider who Web Accessibility Specialist tightly booked.
Fix: Build Accessible Procurement into your vendor process. Request an Accessibility Conformance Report based on the Voluntary Product Accessibility Template, then verify it. Reports describe a product in general; they don't prove your configuration works. Run Screen Reader Testing on the exact join flow a patient or customer will use, from the emailed link onward. Write remediation obligations into the contract.
Mistake 3: Letting Auto-Launch Flows Skip the User's Controls
Why it happens: Product teams optimize for speed. Launching the session automatically from an email link reduces clicks, and defaulting the microphone to mute is a reasonable privacy choice for sighted users who can see the toggle.
Consequence: Defaults become traps when the control that reverses them can't be reached. The privacy default silently converted into a total communication failure.
Fix: Any state that a user must change to proceed needs a reachable, announced control (WCAG 2.1.1 Keyboard, 4.1.2). Announce state changes with status messages (WCAG 4.1.3). If a default can lock someone out, provide an accessible alternative path, such as a clearly labeled phone fallback.
Mistake 4: Trusting That "It Works for Me" Settles the Matter
Why it happens: The chat field accepted typing normally with the screen reader off. A developer or sighted tester confirming that would reasonably close the ticket.
Consequence: With the screen reader running, the same field Web Accessibility Specialist announced as "Read Only" and wouldn't take input. Something in the page's code conflicted with Assistive Technology behavior. The user couldn't enter a name or order number to fix a wrong shipment, and the company had largely eliminated phone support, so no other channel remained.
Fix: Make Conformance Testing require a pass with Assistive Technology least one screen reader before release, not just visual and automated checks. Inspect form fields for misapplied readonly or aria-readonly attributes, and for scripts that toggle them. Test with the screen reader on, then off, and compare behavior.
Mistake 5: Fixing the One Blocker and Ignoring the Journey
Why it happens: Teams triage by ticket. A single reported defect gets a single patch, and the surrounding flow stays unexamined.
Consequence: A barrier that stops a payment or appointment is a signal about the whole path. In the chat example, the button to start the conversation Web Accessibility Specialist accessible, yet the very next step failed. Partial Conformance across a flow still produces total failure for the user.
Fix: When a blocker turns up, audit the full journey end to end: entry point, authentication, selection, confirmation, and error recovery. Assign ownership through Accessibility Governance so each critical flow has a named accountable owner.
Prevention Checklist
- Every selectable item announces a meaningful name, not just its role.
- Third-party components are tested in your configuration, not accepted on a vendor report alone.
- Default states (muted, disabled, read-only) can be reversed with an announced, keyboard-reachable control.
- Release gates include Screen Reader Testing, with the screen reader on and off compared for form behavior.
- Payment, scheduling, and support flows are tested start to finish, not component by component.
- Contracts require vendors to remediate accessibility defects on a defined timeline.
- Each critical flow has a named owner under your Accessibility Governance program.
- Blocker reports trigger a journey-level review, not a single-ticket fix.
If your team lacks the development capacity to remediate quickly, managed options such as UsableNet Assistive exist; evaluate them against your own risk tolerance and the terms of any indemnity. Whatever route you choose, test what your payment, scheduling, and support flows sound like to someone who can't see them.
