As an Accessibility Evangelist I work with various clients & most of the time it show happens that a particular widget or code that is suggested might not work as expected in a Screen Reader & Browser Combination. There is no guarantee that what works with NVDA+Firefox, JAWS+Chrome & VoiceOver+Safari will work as expected on mobile.
More often than not I see businesses spent time testing using a particular Screen reader & Browser Combination & if something don’t work as expected they think it is a bug with the code. If the code is written according to HTML & WAI-ARIA specifications then we don’t have do any hacks to make it work with wide variety of assistive technologies. It might be just that particular Browser or assistive technology has not evolved enough to give the right output for the end user. This kind of bugs are not accessibility failures.
Identifying the user-agent bugs comes with experience. When we are sure that a particular accessibility bug is not in the code & bug is within browser or assistive technology then we need to raise these bugs with appropriate channels. We can also check if any of these bugs have been raised by other community members & what is being done about the bug.
The following table provides you with information on where you can raise accessibility bugs for browsers & assistive technologies.
|Bug Tracker||URL||Details/Bug Reporting Guidelines||Bug Type|
|NVDA Issues||https://github.com/nvaccess/nvda||Screen Reader|
|Apple Bug Reporter||https://feedbackassistant.apple.com/||Screen Reader Assistive Technology Native iOS/OS X|
|Webkit Bugzilla including Safari||https://bugs.webkit.org/||https://bugs.webkit.org/page.cgi?id=bug-writing.html||Browser|
|Open Radar||http://www.openradar.me||Open radar is a way make your bug reports with Apple public as their tracker is not searchable. This does require you to file both with apple and with open radar (to let the world know).||Screen Reader Assistive Technology Native iOS/OS X|
|Chromium Bug Tracker||https://code.google.com/p/chromium/issues/list||http://www.chromium.org/for-testers/bug-reporting-guidlines-for-the-mac-linux-builds||Browser|
|TalkBack||https://www.google.com/accessibility/get-in-touch.html||Google accepts accessibility feedback at Google Accessibility Feedback||Screen Reader|
|VoiceOver||Apple welcomes comments and inquiries about the accessibility of their products. Please [email protected]. This is the email to use/recommended for best results regarding bugs and issues with VO specifically.||Screen Reader|
|GNOME (Orca) Bugzilla||https://bugzilla.gnome.org/enter_bug.cgi?product=orca||Screen Reader|
|Dragon Naturally Speaking||Tech Support||Assistive Technology|
|ZoomText||Ai Squared Support||Assistive Technology|
|WAI-ARIA Specs||W3C ARIA GitHub Repository||Specs|
|Microsoft Edge||Microsoft Edge Issue Tracker||Browser|
The table presented above is taken from A11Y Ideas & tthis was a paper presented at CSUN 2016. Here is the original table Whose Line Is It Anyway?
Please use the comments section to alert us with more information or any information that needs changing.