Why this matters
Blind and low-vision users access the web with screen readers (such as JAWS, NVDA, or VoiceOver), braille displays, magnification, custom color schemes, and keyboard-only navigation. When a site relies on visual cues alone, or when interactive controls are not coded with accessible names and roles, the result isn’t merely inconvenience—it can be a complete lockout from essential services such as booking appointments, accessing health information, comparison shopping, or completing checkout. Under U.S. disability law, digital spaces that function as places of public accommodation are expected to provide equal access. Practically, this means designing and coding for perceivability, operability, understandability, and robustness from the outset.
Where modern websites commonly break
The most frequent barriers fall into a handful of patterns. Each one is simple to describe but impactful in practice—especially when combined on a single page or across a site’s shared components.
1) Low color contrast and text that looks like “placeholder gray”
Fashionable palettes often set light text on light backgrounds or rely on subtle color differences for emphasis. For many users (including those with low vision, color-vision differences, or on bright mobile screens), this makes body copy, form labels, and buttons illegible. Contrast needs vary by text size and weight, but as a rule of thumb: if you have to squint, it’s a fail.
2) Unlabeled icons and image-only buttons
Icon-only controls—shopping carts, filter chips, close “X” buttons—must expose an accessible name. If the element is an image or SVG without a text label or proper ARIA attributes, screen readers will announce “button” with no context, or worse, nothing at all. Users can’t activate what they can’t identify.
3) Keyboard traps and broken focus order
Keyboard users rely on a logical Tab sequence and a visible focus indicator. Complex menus, popovers, sliders, and modals frequently trap focus or send it somewhere unexpected. If you can’t reach a “Place Order” button—or can’t escape a modal—you can’t complete the task.
4) Headings used for style, not structure
Screen readers use headings to build an outline of the page. When headings are skipped (jumping from H1 to H4) or faked with bold divs, the outline breaks. Users lose the ability to navigate quickly to sections like “Reviews,” “Shipping,” or “Payment.”
5) Forms with missing labels, unclear errors, and CAPTCHAs
Inputs need programmatic labels; placeholders are not labels. Error messages must announce which field failed and why, and they should be reachable by keyboard with focus returned intelligently. CAPTCHAs should have accessible alternatives (e.g., non-visual challenges or out-of-band verification).
6) Auto-rotating carousels and motion that overrides control
Carousels that auto-advance steal focus and hide content before assistive technology can read it. Motion or parallax effects that cannot be paused can produce disorientation and prevent task completion.
7) “Custom” components that skip semantics
A div that looks like a button is still a div to a screen reader—unless it is given the correct role, name, state, and keyboard handlers. Sliders, toggles, date pickers, and infinite scroll lists are frequent offenders when built from scratch without accessibility in mind.
A quick diagnostic you can run in minutes
- Turn off your mouse. Can you open the menu, select a product variant, add to cart, and checkout using only the keyboard?
- Follow the focus. Is the currently focused element always visible, with a clear outline or highlight?
- Zoom to 200% on a laptop. Does content reflow without overlap or hidden text? Can you still reach all controls?
- Inspect a few icons. Do “cart,” “search,” “close,” and “filter” have programmatic names (not just tooltips)?
- Trigger an error. Submit a blank form. Are errors announced, specific, and associated with the field?
What barrier-driven harm looks like
Harm is not abstract. It looks like the inability to book a needed medical appointment because the calendar control can’t be operated by keyboard. It looks like being unable to add required detail to a form because the label is missing and the screen reader only says “edit text.” It looks like abandoned carts when the “Checkout” button is a decorative image without an accessible name. In each case, a person is denied a service others receive effortlessly.
How to capture evidence when you encounter barriers
Thorough documentation transforms a frustrating experience into a clear, verifiable record:
- Screenshot or short screen recording of the barrier, including any error messages.
- Date and time, the full URL, and the device/browser used.
- Exact steps you attempted (e.g., “Pressed Tab from address field; focus disappeared and did not reach the Submit button”).
- Assistive tech context if applicable (e.g., “VoiceOver on iPhone,” “NVDA on Windows”).
If a specific purchase, booking, or deadline was missed due to the barrier, note the consequence (e.g., “Could not register for a class before the cutoff,” “Could not complete pharmacy refill,” “Lost a weekly sale price”).
For organizations: triage and fix the systemic causes
Sustainable accessibility comes from improving components rather than one-off pages. Most barriers originate in shared building blocks—buttons, form fields, modals, and navigation. Fixing those at the design-system level eliminates entire classes of problems site-wide.
- Design: set contrast tokens with sufficient ratios; specify focus states as first-class visual assets; require text labels for icons.
- Frontend: map every interactive control to the correct semantic element or ARIA role/name/state; wire keyboard handlers for Enter/Space/Escape and arrow keys where applicable.
- Content: write meaningful alt text and headings; avoid using placeholder text as labels; provide captions/transcripts for media.
- QA: add keyboard-only and screen-reader checks to acceptance criteria; regression-test shared components whenever they change.
Accessibility is good business
Accessible sites reduce support costs, expand market reach, and improve SEO and performance metrics by encouraging semantic HTML and clean structure. Conversely, inaccessible experiences increase abandonment, refunds, and reputational risk. Investing in accessibility is both a legal and a commercial imperative.
Frequently asked questions
“If we add an accessibility overlay, are we covered?”
Overlays and automated widgets cannot fix missing labels, broken focus order, or non-semantic components. Real accessibility is built into the code and design—not toggled on after the fact.
“Is color contrast the only issue for low-vision users?”
No. Contrast is one piece. Equally important are focus visibility, scalable layouts at higher zoom, readable type, and clear labeling of controls.
“Do mobile experiences have different rules?”
The principles are the same. Mobile adds constraints: touch targets must be large enough; zoom should not be disabled; sticky elements must not obscure content; and orientation locks should not block access.
How The Brensilber Law Firm helps (briefly)
When barriers deny equal access to services, we help clients turn evidence into action. Our approach emphasizes careful documentation, clear articulation of harm, and outcomes that drive meaningful fixes—so the experience improves for everyone who comes after you. If you experienced any of the issues described here, contact us to discuss your options or explore more resources on our Resource Hub.