2 ms·

Not if you are good with ur aria tags.

by dartos 3y ago

janosdebugs 3y ago
That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.
- egeozcan 3y ago
  Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder. I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way. I have many stories like this. I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things. When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
yreg 3y ago
That's not true. Aria isn't a replacement for proper markup. Accessibility software is rather brittle even when you do everything right. It's a bad idea to push it.
- nsonha 3y ago
  Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
  - justinmarsan 3y ago
    Even the Aria docs say you should rely on semantics and only use Aria for when that's not possible... I'd much rather use a <button> that exposes itself as such and has well known interaction functions, then create my own div and have to handle the clicks, keyboard navigation, navigation shortcuts and so on... That actually requires a lot more knowledge than HTML semantics, and unless you test frequently with expert and non-expert assistive tech users, you won't know what kind of UX issues you'll be creating for them...
  - kypro 3y ago
    > They ARE made for accessibility and accessibility only Sure, but have you ever used a screen reader? Support for aira markup is often limited and if you confuse things with semantically muddled HTML you're almost guaranteed to degrade accessibility. The more basic and "standard" you can keep your HTML the less likely users using assistive technology will run into problems. Aria is great, especially the basic stuff like aria-label, but where you can avoid using it you should. I've worked on accessibility projects for years, treating aria as a source of truth or something that can be relied on isn't a good idea. We might get there eventually, but we're not there today.
  - cqqxo4zV46cp 3y ago
    Someone says “accessibility software is brittle” and your response is based on a “should”? Great. Another developer that sees accessibility as another specs compliance fetishism exercise instead of actually being way to make things easier to use for more people.
    - nsonha 3y ago
      specs compliance fetishism would be semantic web. The reason so much has been written on it is that it's so messy and practically people never get it right. HTML is so overloaded for multiple functions (content, logic, presentation and now accessibility), so is it really a surprise that it sucks at all of these?

Not if you are good with ur aria tags.

by dartos 3y ago

Not if you are good with ur aria tags.

janosdebugs 3y ago

That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.

egeozcan 3y ago
Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder. I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way. I have many stories like this. I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things. When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)

yreg 3y ago

That's not true. Aria isn't a replacement for proper markup. Accessibility software is rather brittle even when you do everything right. It's a bad idea to push it.

nsonha 3y ago
Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
- justinmarsan 3y ago
  Even the Aria docs say you should rely on semantics and only use Aria for when that's not possible... I'd much rather use a <button> that exposes itself as such and has well known interaction functions, then create my own div and have to handle the clicks, keyboard navigation, navigation shortcuts and so on... That actually requires a lot more knowledge than HTML semantics, and unless you test frequently with expert and non-expert assistive tech users, you won't know what kind of UX issues you'll be creating for them...
- kypro 3y ago
  > They ARE made for accessibility and accessibility only Sure, but have you ever used a screen reader? Support for aira markup is often limited and if you confuse things with semantically muddled HTML you're almost guaranteed to degrade accessibility. The more basic and "standard" you can keep your HTML the less likely users using assistive technology will run into problems. Aria is great, especially the basic stuff like aria-label, but where you can avoid using it you should. I've worked on accessibility projects for years, treating aria as a source of truth or something that can be relied on isn't a good idea. We might get there eventually, but we're not there today.
- cqqxo4zV46cp 3y ago
  Someone says “accessibility software is brittle” and your response is based on a “should”? Great. Another developer that sees accessibility as another specs compliance fetishism exercise instead of actually being way to make things easier to use for more people.
  - nsonha 3y ago
    specs compliance fetishism would be semantic web. The reason so much has been written on it is that it's so messy and practically people never get it right. HTML is so overloaded for multiple functions (content, logic, presentation and now accessibility), so is it really a surprise that it sucks at all of these?