mfairchild365
commented
3 years ago Thank you @mgifford. I usually try to open issues against AT or browsers whenever I find an issue, but sometimes I just don't get around to it. I should do a better job of that. If you happen to know of existing issues, or want to open your own issues, please post the URLs here.
Whenever I do open or find such an issue, I link to it from the relevant feature page. See the headers attribute feature as an example. I need to open or find more issues for that feature too, but at least it has one linked issue.
For the most part, I try not to assign direct blame or responsibility as part of this site. Thoughts in no particular order:
- It's not always clear who is responsible for fixing a support bug.
- WCAG has a normative accessibility supported conformance requirement. It basically says that that if a feature is relied upon to meet a given SC, that feature must be supported by AT. WCAG makes this very unclear by purposefully not defining exactly which AT need to be supported or at what level the support needs to be at.
- I try to look at this from the perspective of an end user. If something isn't working, end users are not likely to think 'oh, thats an issue with my screen reader or browser and not the site that I'm using. I'm fine with it not working.'
- My opinion: site authors will spend hours or even days making work-arounds to shore up even small visual or functional gaps in features. If they are willing to do that for visual users, why not do it for screen reader users? (I understand there are a lot of caveats here and it isn't always practical)
- Part of aria-at scope is working closer with AT/browser developer to come to consensus on what exactly 'support' means for a given feature. That direct relationship isn't something I've pushed for as part of this project.
- I think the question of whether or not a developer should address the support gap needs to be decided on a case-by-case basis. There are a lot of factors at play here. For example:
- It might be possible to change the design slightly so that the feature isn't relied upon to meet any specific WCAG SC.
- It might be possible to use a pre-written polyfill to fix the issue.
- The context in which the feature is used on a site might make the issue more or less severe.
- It might be possible to use a different feature to accomplish the same task in a different way that yields more robust support without affecting the design.
- It might be reasonable to use the feature as is and wait for better support if there are no sufficient alternatives.
- If the site is used in a closed environment, such as a corporate network, AT/browsers might be restricted and issues with other AT/browsers might not be relevant.
- In short, the goal of this site isn't to say 'use this', 'don't use this', or 'use a hack here'. Instead, it's here to help folks make informed decisions and reduce the amount of manual research that needs to happen to make good decisions.
Side note: Sorry for leaving a long winded reply.
mgifford
Just as an example if you look here https://a11ysupport.io/tests/tech__html__html_figure__test_3#test-html
Is the problem figcaption & that it isn't well supported enough for for authors to use, or is it that
Narrator, NVDA, TalkBack & VoiceOver need to improve their game? I think it's a matter of is it a WCAG issue or UAAG issue https://www.w3.org/WAI/standards-guidelines/uaag/
I like to fix things at the source.
David MacDonald has a good list of where to report this: http://www.davidmacd.com/blog/bug-tracker-list.html
I just worry about creating hacks because one or two combinations doesn't work, when ultimately the problem may not be something that a web author can control.