Hacker News Reader

Comment by alib | Hacker News Reader

I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?

View on HN

Good catch - fixed.

You rock.

Why is a clickable div an accessibility nightmare when the button element has a lot of browser-preset styles that are harder to override? Assuming you put all the relevant state styles into place like :hover and :active and whatnot, what's the problem? Button elements are best used in a form. If you aren't submitting a form, what's the button there for?

button { all: unset; }

This removes all the preset browser css styles. An accessible,styled <button> is much easier to achieve than an accessible, styled <div>

What makes it more accessible?

I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.

That’s exactly it. With native buttons and links you get all the accessibility for free. If you attach events to non-interactive elements, you have to do all the accessibility work yourself. In a custom interface, a button outside a form is perfectly valid and the best choice for the above reason.

Yeah, no. If the only reason to do it is to accommodate poorly made accessibility software then count me out. That's bad reasoning and the 'correct' elements will change with the accessibility software.

Logically it should be the reverse. Screenreaders can learn how to detect all clickable elements instead of shoehorning a form control element into places.

Reply on news.ycombinator.com