Determine list of supported platforms for accessibility

[jessegreenberg]

It would be good to have a list of platforms that we must support. This will define what needs to be covered by QA testing, and also help narrow down scope for investigating solutions to bug reports and new features. For instance, in phetsims/balloons-and-static-electricity#205 do we need a solution that works with VoiceOver for Sierra, Yosemite, and El Capitan? Do we need to support old versions of JAWS and NVDA or can we just support latest?

@terracoda and @emily-phet what platforms should we support?

We have a 'testing matrix' that defines what platforms should be tested for our normal sims. It would be great if we had something like this for accessibility.

https://docs.google.com/a/colorado.edu/spreadsheets/d/1vk0QUOOOj_Jr4ePVgwiQ5L7HOsvgor7jkbNYqmCVWnQ/edit?usp=drive_web

[emily-phet]

Here's my unpolished thoughts on this:
We want to support at least some possibilities for access with JAWS, VoiceOver, and NVDA. For each, I would like to try to support the primary browser that it works best with in general (I believe @terracoda has a list somewhere of these), and a second browser that it works next best with.

If there are cases where the addition of a screen reader (e.g., ChromeVox) can be added with minimal effort (at least as far as we can see for now), we can consider adding that to the list. And the same for browsers, if a third browser option for a given screen reader seems like "low hanging fruit", we can consider adding that to the list as well.

@jessegreenberg - can you put together a testing matrix that includes the scenarios I describe above, and check with @terracoda if there are some gaps you're unsure of?

[emily-phet]

@jessegreenberg - for your question regarding what OS/browser versions to support...that's a good question. Let's talk about that in the PhET/IDRC meeting tomorrow, and I'll reach out to some colleagues to get their input for what is most useful, and what is reasonable to do.

[terracoda]

@jessegreenberg, @emily-phet according to Bryan Garaventa, we should likely be testing on the latest systems all around (OS, Browser and Screen Reader). If we find bugs and issues in these systems, we can investigate and see if it is our implementation or perhaps a browser or screen reader issue.

For example, the recent example of JAWS not recognizing the WAI-ARIA switch role (#182) is a bug with JAWS. The switch role is a new ARIA role, part of ARIA 1.1, so it might just take a bit of time for JAWS.

• On latest MacOS (Sierra), latest Safari and latest VoiceOver - currently seems to work well on all tested Sierra systems, but my own.
• On Windows 10 - Latest FireFox and Latest NVDA
• On Windows 10 - Latest Windows browser and Latest JAWS

[terracoda]

@jessegreenberg, we should maybe also keep an eye on the latest screen reader survey results.

I am not sure how relevant these results are for young student users or student users enrolled in Higher Education.

[terracoda]

@jessegreenberg, and though we have other issues to deal with iOS, VoiceOver is most used on iOS. All iOS users do not necessarily use MacOS as their main operating system.

For reference here's the link to Bryan Graventa's article on the subject
How browsers interact with screen readers

[terracoda]

@emily-phet, @jessegreenberg actaully, Garaventa suggests:

the best way to ensure the highest level of accessibility for the highest percentage of screen reader users, is to program complex interactive components using the most widely used screen readers to test this functionality in the Operating Systems where they are most widely used.

At the time of the article this was:

• Windows OS using JAWS and Internet Explorer, and using NVDA in Firefox for laptops and desktops.
• For mobile devices, the most widely used screen reader is Voiceover in iOS devices.

Another few important points at the end of the article:

• Avoid AT specific ARIA hacks
• Ensure keyboard accessibility (regardless of screen readers)
• Only use ARIA with strict adherence to the ARIA specification

I think this is what we are trying to do :-)

[jessegreenberg]

@emily-phet @terracoda this sounds great, thanks. It sounds like the recommendation is latest versions of the optimal OS/Browser/AT combinations. I will start a testing matrix with this in mind.

The survey results from WebAIM looks very helpful, that is great!

[jessegreenberg]

Here is a start, it would be great to review this today.

https://docs.google.com/a/colorado.edu/spreadsheets/d/1eBvtrrLa3rJMznnuzk-pB1WsjOAT16usHTBBm4RVoac/edit?usp=sharing

[jessegreenberg]

The above does not include any iOS devices, and these can't be supported until we finish phetsims/scenery#41.

[jessegreenberg]

We discussed this in an accessibility meeting on 11/22/16.

One recommendation was to test across different versions of JAWS, as students tend to use JAWS versions 15, 16, and 17. JAWS Professional and Home editions can also perform differently. Educational institutions typically provide students with JAWS, closely followed by Window-Eyes.

One recommendation from the IDRC was to use a different model for platform support. Given the nature of AT, perhaps it is more appropriate to adopt a model where we follow ARIA standards as best as we can and leave it up to AT to support HTML-ARIA. If we have a strict list of supported platforms, it could lead to platform specific workarounds, which is costly and bad for maintainability.

[jessegreenberg]

@emily-phet given the discussion yesterday, how would you like to proceed with this issue?

[terracoda]

@jessegreenberg, @emily-phet, the other thing to keep in mind is that the comment about students being provided with the AT (i.e. JAWS and Windows-Eyes) may be specific to the United States, and possibly Canada. Other places may have quite a different model for providing or not providing AT to students.

[emily-phet]

@jessegreenberg @terracoda - I emailed with some colleagues in the accessible technology community, and they also agree with the approach suggested by the IDRC (not specifically supporting only a subset of platforms, rather focusing on standards-based implementation).

Regarding the list of platforms to test on, I think keeping it as simple as possible to start (latest versions of JAWS, VoiceOver, and NVDA and the latest versions their two most commonly associated browsers), still seems appropriate. Once the first few sims are published with accessibility features, we'll collect feedback from users about any particular needs this approach may not be meeting.
Note about JAWS: I think the latest professional version should be the one we test on.

[emily-phet]

@jessegreenberg @terracoda - also wanted to mention that we discussed ways the community may want to support shared knowledge about the compatibility of the accessibility features with various AT. We don't need to act on this just yet, but we may want to consider in the future how we might support this (e.g., working closely with a group of interested screen reader users to put together a document of compatibility [this would be similiar to work we've done with teachers and learning standards], or having a group of "trusted testers" that have access to an interface that allows them to populate a table that lists info on compatibility [more like the "trusted translator" model]. These are just some ideas, I'm sure there are many ways we could do this and that may emerge naturally from users interests/needs.

[jessegreenberg]

OK, thanks @terracoda and @emily-phet. So to summarize, we will adopt the following approach for accessibility feature support:

• Focus on implementing accessibility features in with web standards rather than requiring support for a list of platforms.
• Only use HTML-ARIA roles and attributes that are supported by the latest JAWS with latest IE, latest NVDA with latest Firefox, and latest VO with latest Safari.
• We will continue by collecting feedback from users about where accessibility features are lacking.

I think this summarizes our goal nicely, closing the issue.