… I was surprised at how little people were aware of this bug. I wondered if people were really testing their work with Safari and VoiceOver. Perhaps nobody thinks this is as big a deal as I thought?
The biggest surprise though was the negative feedback over my solution. I got a lot of feedback from various people that felt that I should not be attempting to fix anything that was caused by what was essentially a VoiceOver/ Safari bug. I really did not think 1 line of CSS could cause so much noise! I was also surprised because, I am not nearly the first person to suggest code to fix a browser/ assistive technology defect.
Most comments were around the typical instruction of “Use standard web dev and file a defect!” The funny thing about that is that I WAS using standard web dev (a simple unordered list) and defects had already been filed for years. So the question is, when you have done everything “right” in your attempt to do the right thing and it still doesn’t work, at what point do you give up and when do you push on and try to make it right?
And that question is only for the accessibility community, because it’s already common for the rest of the web dev community to do so.
I can understand if you don’t agree with the “problem” or my solution, it works for what I need and that’s all the matters. What was confusing was how different the attitude was towards addressing issues with assistive technologies. I grew up in the field of front-end engineering during a time when fixing browser inconsistencies and flaws was a big part of the job. jQuery built a cult by normalizing DOM and JS, CSS Resets were a required asset as much as HTML5-shim was, and Modernizr was used to detect more unsupported features to polyfill. Today we use transpilers and post-processors to support future code in today’s browsers, and web components to style elements which normally are not stylable (which IMO is not a good reason).
…
What to do?
We always say that a big reason to do accessibility is because “it’s the right thing to do” so how do you do the “right” thing? As with everything else, it depends. I am not going to cop out and leave it right there though. I can tell you what I do/ think.
Definitely start with standards. HTML, for the most part, has been accessible since the beginning of time. Don’t fool yourself thinking you can recreate everything and be as inclusive as possible. It doesn’t matter which hot framework/ library du jour you are using. Don’t automatically assume that ARIA will bail you out.
If after testing, you find something not working the way you think it should, you should check to see if a defect has already been filed first before opening your own. You might end up finding the solution you need. If you find an already-open ticket, make sure to add any relevant information. If you don’t find a ticket, go ahead and open one making sure to include any information needed to reproduce the issue and your expected results. Here is a list of places to research/ file defects:
- JAWS – VFO Github
- NVDA – NVDA Github
- VoiceOver – Email accessibility@apple.com
- ChromeVox – Google Chrome bug tracker (ChromeVox) (Component: UI>Accessibility>ChromeVox)
- IE/ Edge – MS EdgeHTML issue tracker
- Safari – Webkit Bugzilla
- Firefox – Mozilla Bugzilla (Comp: Disability Access)
- Chrome – Google Chrome bug tracker (Component: Blink>Accessibility)
With those 2 steps out of the way, you have been a good citizen to the broader accessibility community. Now it’s time to figure out what YOUR response is going to be.
Curated by (Lifekludger)
Read full article at Source: Should developers work around assistive technology bugs? – Unfettered Thoughts
life tools 