Closed jessegreenberg closed 8 years ago
Struggles with 'aria-live' well summarized here:
You should also indicate which screen readers you intend to support. JAWS, NVDA, VoiceOver, ChromeVox, etc. Each of these behave differently from one another, and differently individual across browsers.
Test of aria-live in many browsers can be found here: http://terrillthompson.com/tests/aria/live-scores.html
Results from that test: JAWS 15.0 works perfectly in both Internet Explorer 11 and Firefox 36. NVDA 2015.1 works perfectly in Firefox. VoiceOver in iOS8 (Safari) works perfectly. ChromeVox 43.x in Chrome 41.x works perfectly.
From the Paciello group:
All three of the browsers commonly used by screen reader users (Firefox, Internet Explorer and Safari) expose ARIA live regions through their accessibility APIs.
No mention of Crhome.
Testers from the W3C running through aria-live: http://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=107
Safari, Firefox, and IE tested. Not even a mention of Chrome.
@jessegreenberg In my first interview, we used Windows 7, Jaws 16 and Chrome 47. We got currently implemented dynamic descriptions (Instance 7).
While testing #116, I noticed that the order of aria-live
events is different for various screen reader and browser combinations. In some browsers, the aria-live events did not fire at all. In others, the order of polite
updates were reversed.
http://whatsock.com/tsg/Coding%20Arena/Drag%20and%20Drop/demo.htm has an example of a live alert. There are currently two live alerts in BASE for when the balloon and wall are added to the screen view. These live regions work well with Firefox, but are unpredictable in other platforms
If they are changed to changed to follow the above example, I think behavior should be more consistent.
There should also be a single live alert region for the screen view. It is not necessary to have more than one.
@jessegreenberg The alerts that we added to announce the adding and removing of the Green Balloon and the Wall, worked really well in subsequent interviews. Similar alerts for the reset buttons might work nicely, too. And even eventually for the Charge Radio Buttons. Using these alerts seems to assure the user that their request/interaction was successful and that the controls work as the user expects them too. The alert connects the user's action directly with a change in the content, which is something we are trying to achieve. It may also have the added benefit of being able to reduce associated descriptions containing "help text", which may be useful in some cases.
Sounds great @terracoda, as we discussed in 3/29/16 meeting, additional alerts for other interactions seem quite useful.
@jessegreenberg I am just posting this article from Steve Faulkner, JAWS Support for ARIA – updated October 2012. I may have posted it before.
I am curious about aria-flowto
& aria-flowfrom
states:
"When the author defines these relationships on elements in a Web page, JAWS will announce that the element has a “flows from” or “flows to” relationship. The user can move to “flows to” elements using the EQUALS Navigation Quick Key and to “flows from” using the SHIFT+EQUALS Navigation Quick Key."
The description made me think of the JUMP-to locations?
I am also curious about aria-controls
:
"JAWS will announce that an element has the “controls” relationship to another element on the page. The user can move to the controlled element using INSERT+ALT+M."
I am wondering if we could use this to connect the user directly to the Green Balloon after adding it. Or directly to the Balloon on reset?
In interviews, participants were not always sure how to go find the Balloon after they added it.
Just putting the thoughts here. I found them in my bibliography notes :-)
I wonder if this state would be useful for the control panel items?
See #151, this might help with these issues. The prototype screen reader (#145) also registers observers so that aria-live works as we would expect.
From #103, we are now starting to add 'aria-live' regions to balloons-and-static-electricity.
Dynamic descriptions have been the most difficult aspect of PhET a11y. This issue will document some issues and challenges as they arise.