Paths Subjects Questions Quizzes Pricing Search
Intermediate Open Free

Why a Pixel-Perfect Fake Button Fails Screen Readers Anyway

A <div> is styled with CSS to look pixel-identical to a real button — rounded corners, a shadow, a hover state, a click handler. Visually, nobody could tell it apart from a native button.

What happens when a screen reader's accessibility tree encounters it?

Solution

The correct answer is "It's reported as a generic, non-interactive container."

The accessibility tree reports a styled <div> as a generic container, not as an interactive element, even though it's pixel-identical to a real button visually — a screen-reader user tabbing through the page won't land on it, and if they somehow reach it, it won't be announced as "button" or respond to Enter/Space by default.

Screen readers don't infer interactivity from visual appearance, so it's not announced as "button" automatically. This isn't an error condition in the accessibility tree — it's silent, which is exactly what makes it a dangerous, easy-to-miss bug. It also isn't skipped entirely; it's present in the tree, just described incorrectly.

Share this question

← Back to Accessibility and Inclusive Design practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.