3 ms·
This is a very limited view that (understandably so) forgets that screen readers and other accessibility tools do offer more UX that is normally not obvious for
by kaoD 2y ago
This is a very limited view that (understandably so) forgets that screen readers and other accessibility tools do offer more UX that is normally not obvious for us, able developers.
This for example is very wrong if you take accessibility into account:
> Yes, I know that some sectioning elements actually have some UX attached to it. But not that much UX if you compare it to the real interactive elements. Not getting your heading levels right is not at all as destructive as using divs instead of links.
We often forget about accessibility users, not because we don't care about them (well, sometimes that too, I'm sick of hearing "we can't spend that much time on such a small percentage of users"), but because we are not even aware of how accessibility tools make use of the semantics around HTML. We don't live in the "accessibility world" and it's not ingrained in our development practices so it doesn't even cross our minds. We already fail at non-accessible UX (as the article correctly points out; which BTW also affects accessibility) so how can we not fail at providing the means to navigate via tools we don't even use?
I've recently been tasked with fixing a web app to make it more accessible (due to government mandate), and using a screen reader to debug has been an eye-opening experience (no pun intended). I wish every developer tried a screen reader at least once.
For example, do you know how important the different WAI-ARIA patterns are? See for example the alert pattern[0] or how landmark regions[1] (which the paragraph above dismisses as having very little UX) help accessibility users navigate.
Have you ever tried the full-page accessibility tree [2] in the browser's devtools?
There is so much hidden UX that we take for granted as sighted users, such as communicating field set relationships visually (by having related fields be close, or e.g. padded at the same level) instead of providing accessible UX like grouping those under an actual properly labeled `fieldset`.
I know it's not your fault as a sighted user (out of sight, out of mind; goes both ways) but I'm a little saddened by the state of accessibility good practices -- both because they're not taught anywhere and because the platform sometimes fights against us (e.g. as one of the other threads points, manually setting heading levels is a pain in the ass).
Accessibility users should be able to navigate the web too. And not only those with visual impairments -- proper accessibility is not only for screen readers.
[0] https://www.w3.org/WAI/ARIA/apg/patterns/alert/ https://www.w3.org/WAI/ARIA/apg/patterns/alert/
[1] https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/
[2] https://developer.chrome.com/blog/full-accessibility-tree https://developer.chrome.com/blog/full-accessibility-tree
- Simran-B 2y agoI once tried out a screen reader out of personal interest but gave up after an hour or so due to how frustrating the experience was. I couldn't find the right key combinations or had a hard time remembering them because there are so many and none of them seemed intuitive. I also accidentally toggled some option using the wrong keys and then other basic things stopped working with no apparent way to recover from that. My suggestion would be to improve the UX of screen readers for sighted developers, e.g. by adding a little bit of UI to access the most important features without having to study the tool for days.
- Joeri 2y agoI would recommend using the VoiceOver / TalkBack feature on your phone instead. It's a lot more intuitive. With VoiceOver learning to use the rotor gives you the experience that fully blind people are likely to use. https://support.apple.com/en-us/111796 https://support.apple.com/en-us/111796