News for hackers. Stuff that matters.
Re:HTML First – Six principles for building simple, maintain... by zlg_codes on Sunday November 12, 2023 @04:48PM (#38244423)
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?
Re:HTML First – Six principles for building simple, maintain... by meowtimemania on Sunday November 12, 2023 @07:36PM (#38245619)
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>

Re:HTML First – Six principles for building simple, maintain... by zlg_codes on Monday November 13, 2023 @01:15AM (#38247503)
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.

Re:HTML First – Six principles for building simple, maintain... by alib on Monday November 13, 2023 @12:19PM (#38252605)
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.
Re:HTML First – Six principles for building simple, maintain... by zlg_codes on Tuesday November 14, 2023 @03:17PM (#38269061)
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.