6 ms·
This is fun to see as an experiment but hopefully nobody does this in real life. This breaks accessibility, reader mode, screen readers, etc.
by grodriguez100 3y ago
This is fun to see as an experiment but hopefully nobody does this in real life. This breaks accessibility, reader mode, screen readers, etc.
- blowski 3y agoI don't really know much about this area of UI. Can you explain why this breaks accessibility? I did load it in reader mode (macOS Safari), and there were no paragraph breaks - is that similar to the experience of a screen reader?
- bropher 3y agoSee this short section on semantic html: https://developer.mozilla.org/en-US/docs/Glossary/semantics#semantics_in_html https://developer.mozilla.org/en-US/docs/Glossary/semantics#...
- troupo 3y agoScreen readers know how to deal with common page elements. So they know how to announce and interact with page breaks, headers, lists, buttons, links etc. If everything is a span, everything becomes just text. It doesn't only apply to screen readers. Regular actions like keyboard navigation becomes broken. For example, on the page, you cannot tab between "click to expand" "buttons". And so on and so on :)
- jmhammond 3y agoIn case someone happens to read my comment down here, I just want to highlight > actions like keyboard navigation becomes broken is also an accessibility issue. Not everyone can use a mouse. Keyboard navigation should be the easiest possible thing to test and ensure works…
- troupo 3y agoIndeed. Good accessibility benefits everyone, even the non-disabled people. And that's even before we start the whole discussion on how everyone will be disabled at one point or another in their lives and so on :)
- infotainment 3y ago> Good accessibility benefits everyone, even the non-disabled people. …until features start getting killed because they can’t be made to work well on screen readers. I’ve seen it happen and it strikes me as unfortunate.
- troupo 3y agoYeah, it' a sad state of things. Since there's no real money in screen readers, no one invests enough to make them better (e.g. to work with highly dynamic interfaces). Since they don't work in a lot of situations, people are disinclined to implement features that don't work well with screen readers. It's almost an impasse
- ajanuary 3y agoIt has role and aria attributes, so I think it actually isn't that bad. It's just `<span role="heading" aria-level="3">` is an awfully long way to spell out `<h3>`.
- wizzwizz4 3y agoTheory and practice hardly even exchange notes, when it comes to digital accessibility.
- infotainment 3y agoScreen readers are basically everything you hated about developing for IE6, but in an alternate world where there are 3 different IE6’s each of which works completely differently.
- wizzwizz4 3y agoThree? Definition lists are read completely differently in Firefox, Edge, or Edge-in-IE-mode in Windows 11 Narrator. Multiply JAWS, NVDA, Narrator, VoiceOver, Orca, ChromeVox by Firefox, Chromium, IE, WebKit, Opera Mini. (Some of those combinations aren't possible, but 20 isn't an overestimate.) Then realise: it's not just screenreaders. It's Braille displays, sip-and-puffs, Magnifier, High Contrast mode, keyboard navigation, speech recognition… Seemingly nobody tested any of it before they gave it to the end-user, so now it's your job, as the web developer, to make something that works. Good luck! I recommend settling for "doesn't make it worse", since that's almost achievable.