3 ms·
The thing that bothers me about this whole insistence that, for accessibility purposes, it is vitally important that we correctly employ links and buttons to e
by jameshart 4y ago
The thing that bothers me about this whole insistence that, for accessibility purposes, it is vitally important that we correctly employ links and buttons to ensure that users of assistive technologies can correctly anticipate whether an interaction will go somewhere or do something...
Why do only assistive technology users get treated with that level of respect?
Because let's be clear - for sighted users interacting with this person's webpage, whether the markup is a link or a button, they evidently plan that visually it's just going to be a paint roller icon, inside an area of the screen of indeterminate size which is going to be somehow interactable.
Apparently it's not important to consider whether I, a user not currently employing assistive tech, might need to know before I click it whether that control will cause a page navigation, carry out an operation, or what.
It might be a link; it might be a button; it might just be a decorative picture of a paint roller. It might interact on hover, on click, or on double click. Who knows!
This definition of accessibility as something distinct from usability, where frontend devs will torture themselves over the semantic markup that they use to ensure clarity of purpose for accessibility purposes, has somehow become completely divorced from the world of UX design, where visual indications of affordances are no longer seen as valuable.
- Timwi 4y agoOnce upon a time, links had an underline and buttons had a beveled frame. We seen to have somehow come to accept the visual designers’ claim that, for some reason, we can't do that anymore.
- runarberg 4y agoSighted users normally have a whole bunch of CSS to convey the same information (as is recommended by most [all?] accessibility standards). Users of assistive technology have to rely on the semantics of the document. Also sighted users get this information as well. If you hover over a link, it displays the target href in the lower corner or your window.
- jameshart 4y agoThe article does not mention changing what the control looks like, only how it is marked up. The design is shown as settled - a roller icon - and the only question to be decided is if that icon is implemented as a link or a button in the DOM. And there’s no hover-link-pop up on a mobile phone touchscreen.
- runarberg 4y agoWell actually the article is wrong on the markup, it should be neither a link nor a button, but a <details> <summary>
- darekkay 4y ago> Also sighted users get this information as well. If you hover over a link, it displays the target href in the lower corner or your window. You shouldn't rely on that: it won't work on mobile nor for users who don't want or can't use a mouse (e.g. people with a motoric disability).
- runarberg 4y agoThe target usually shows as well if you navigate using the keyboard. But you are right, I shouldn’t rely on that, and I don’t, I style my links with CSS so that sighted users can distinguish them by their styles. The location is a bonus. Also if sighted mobile users want to see the location, I think they can click and hold the link, and see it in the context menu.
- deleted 4y ago[deleted]