Replies: 4 comments 6 replies
-
|
axe-core's accessibility supported documentation includes both our current support set for WCAG 2 and our reasoning behind choosing that set. It is heavily informed by WebAIM's Screen Reader User Surveys (but we should be careful to note that there is bias in its respondent demographics). As of axe-core 4.10.2, we use:
We'll probably update the list whenever we end up doing an axe-core v5; we'd definitely drop IE11, and we'd consider adding Voice Access. |
Beta Was this translation helpful? Give feedback.
-
|
I assume each of those means "latest" unless the version is specified? And like my training slides, the OS X probably needs updating to MacOS 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Do we know if there is any testing on and support for Orca on Linux-based machines? If yes, I would like to see that added that in just to have that segment of users covered. |
Beta Was this translation helpful? Give feedback.
-
|
HI @colabottles, what we're trying to establish is the basis/reasoning that we include particular technologies. In terms of Orca, what would the basis be? I don't think it would be popularity (no slight intended, it's just that Linux in general is not a dominant desktop OS, so the screenreader simply cannot be as used as Win/Mac). I guess we could decide to include an option for each type of AT which is open source, or (cost) free and runs on a free OS. However, I think we then have a "tree falling in a woods with no-one to hear" issue, where it seems a bit pointless unless there is some level of popularity. This would be a net-negative if that AT did not support something that more popular ATs did support, because we then wouldn't be able to include methods/techinques for that thing. |
Beta Was this translation helpful? Give feedback.
-
|
@alastc I base this off of my many talks with developers in the Linux space wanting to learn and learn more about accessibility, that was my original thought but with some statistics (as few as I could find that were not repetitive) that maybe the numbers could back up a little of what I was speaking to: 8.3% of respondents according to the WebAIM Screen Reader User Survey (Narrator has an exponentially large percentage) so I feel that is basis for inclusion. While Windows takes up the majority of users in the survey, I think the Linux platform should be included either here or at some point. The developer community in the Linux space that I know of, been a part of, and have met at conferences has been a lot more than I would have expected. I would want to include that space at some point, it would not have to be immediate in my opinion. I know the numbers are low. I compare it to the "we develop in Chrome" while Firefox, Safari users are left in the lurch with "this is optimized for Chromium-based browsers. Please download ..." kind of dialog I have stumbled across. and I agree, popularity is low. Which I don't feel is a slight, just fact. If the decision is that including the Linux platform and Orca isn't warranted, I am not tied to "this MUST be included", I was just thinking about consideration.
This was the one thing I have thought about thinking about this since I asked the question and this is something I definitely agree with and would want to avoid. |
Beta Was this translation helpful? Give feedback.
-
|
If we're going to be testing with VoiceOver, then I'd assume that we would also be testing with Voice Control, which ships with multiple Apple operating systems. |
Beta Was this translation helpful? Give feedback.
-
|
Also worth considering how this set will be kept updated/extended. Don't want to end up casting a particular list of UA/ATs in amber for all eternity, while reality diverges |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I'd like to see us establish a policy/process for "at what cadence will we reevaluate the list and what criteria will we use for doing that evaluation" and document that in the same spot that we want to document "how did we arrive at this list" anyway. |
Beta Was this translation helpful? Give feedback.
-
|
This is all intended to be in the informative space, so agree with that. We could setup a yearly review, or rely on people to raise issues when things change. I'm inclined to go for the latter as we have plenty of people around who are incentivized to keep this kind of testing approach up to date. |
Beta Was this translation helpful? Give feedback.
-
|
Most of discussion within AGWG related to screen readers will be based on the screen readers which have English version such as NVDA, JAWS, VoiceOver, TalkBack and so on. However we should keep it in our minds that there can be other screen reader(s) which doesn't have the English version in order to make WCAG 3 international guidelines. For example, there is a Japanese screen reader (PC-Talker) which has been very popular among screen reader users in Japan. The functionalities differ from the others. This can happen in any other countries/languages. It means "Sufficient Techniques" listed in "Understanding WCAG" can be insufficient for some screen readers, in other words, for some languages/regions. Here are examples of what we've been doing in Japan under the concept of "Accessibility-supported ways of using technologies) defined in WCAG 2. These efforts were required and essential because the Japanese national standard adopted WCAG 2. We had to confirm if each sufficient technique is accessibility-supported for Japanese web content.
FYI: WAIC (Web Accessibility Infrastructure Committee in Japan) is also the JIS draft development organization (JIS X 8341-3:2016, national standard for web content accessibility). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
From the WCAG3 explainer:
So at the foundational level of conformance the methods / techniques we provide should be reasonably reliable.
That means we need an "accessibility support set" for foundational level requirements/methods/techniques/tests. Even though we might not call it that in the spec, if authors rely on our techniques, we need to know that they are supported by a reasonable range of assistive technology.
This is status-quo (the same as) WCAG 2, except that in WCAG 2 the baseline set of technology support wasn't explicitly defined, and there was no mechanism to define your own set.
In order for people/organizations/regions to define their own set, we need to define what they are varying from (the default set).
We should consider that:
Question
The question for this discussion is: What should our default "accessibility support set" be?
As an example, in the UK the Government Digital Service maintains a page which outlines which AT to test with for UK Gov orgs. They have defined their set.
That set is UK based, although the stats are partly from the US. Does anyone have publicly available versions of this type of information? It would be especially useful if it is from another region.
As a simple draft to generate discussion, and acknowledging my western & English-speaking bias, what if we used the most popular paid-for and free versions of each major type of AT?
I'd like to include some AT for cognitive/learning disabilities, but they seem to be spread thin, it's hard to work out what would be considered popular. (Please correct this if you know of anything that would make a good default.)
Beta Was this translation helpful? Give feedback.
All reactions