#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
The <a role="button" tabIndex={0} onClick={} onKeyDown={} /> has one use case: you have something that needs to be visually a link wrapping alongside text, with an action that does a button behavior. The reason for this is that you can never make <button /> element wrap like an inline element as display: inline; just simply does not work on a real button element. It always ends up as inline-block in minimum.
Of course it would be ideal to design things so that this would never happen, but everywhere I've been at there has eventually been a need for "look like a link, behave like a button" component. And the same way the other way around, "look like a button, behave like a link".
To avoid this we'd need to have the whole chain of things accounted for when creating things: the architecture of the site should go for progressive enhancement first, the designers should be aware of avoiding designing links that are not links, the developers should then be aware to work with progressive enhancement as their core principle which does clarify when to use a real button, and when it is a link. Docs should also exist to support doing things right. Break one part in this chain and the mess crawls back into existence, eventually.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The
<a role="button" tabIndex={0} onClick={} onKeyDown={} />has one use case: you have something that needs to be visually a link wrapping alongside text, with an action that does a button behavior. The reason for this is that you can never make<button />element wrap like an inline element asdisplay: inline;just simply does not work on a real button element. It always ends up asinline-blockin minimum.Of course it would be ideal to design things so that this would never happen, but everywhere I've been at there has eventually been a need for "look like a link, behave like a button" component. And the same way the other way around, "look like a button, behave like a link".
To avoid this we'd need to have the whole chain of things accounted for when creating things: the architecture of the site should go for progressive enhancement first, the designers should be aware of avoiding designing links that are not links, the developers should then be aware to work with progressive enhancement as their core principle which does clarify when to use a real button, and when it is a link. Docs should also exist to support doing things right. Break one part in this chain and the mess crawls back into existence, eventually.