Accessibility Assessment for Balloons and Static Electricity 1.2.0-accessible-instance.7

[jessegreenberg]

@terracoda provided an assessment of accessible balloons-and-static-electricity after a student interview. The assessment outlines some technical issues with the accessible content. This is a compilation of the noted issues so that we can track progress and document comments and concerns.

[jessegreenberg]

• Sim does not work with IE9 + JAWS 16. Logo splashed but none of the visuals were rendered.

Remaining issues are for Chrome 47, Windows 7, and JAWS 16

• JAWS intercepted arrow keys for dragging the balloon, and spacebar for releasing
• Keys eventually worked after pressing 'Insert+3' to force JAWS to ignore the following keypress. Beginner and intermediate JAWS users may not know to do this.
• Sometimes arrow keys change the focus highlight color, sometimes they don't.
• JAWS reads out page structure as 5 regions, 1 Application, 6 headings, and no links.
• Screen reader should be able to pause after screen summary.
• Chrome incorrectly 'counts' the number of input elements in a fieldset
• 'Partially checked' is read out for radio buttons on first read through
• 'Left paren' and 'right paren' read in reset balloon button description
• Balloon labels need to reference color, 'Yellow Balloon' and 'Green Balloon'
• JAWS seems to intercept keys even on a form element.
• JAWS intercepted 'W' after pressing 'J' to jump to wall.
• Visual focus does not move when users navigate with arrow keys to focusable items.
• Navigation order was incorrect between charge radios and reset button
• The navigation through the sim should loop from last element to first, skipping the address bar.

[jessegreenberg]

Sim does not work with IE9 + JAWS 16. Logo splashed but none of the visuals were rendered.

Sim loads and runs correctly with NVDA + IE11. I will try test to make sure that IE9 runs the sim.

[jessegreenberg]

Sim seems to run correctly in IE9 + NVDA, but I notice two things:

1. Load time is exceptionally long, I observe about 15 seconds to load
2. IE9 does not support the 'hidden' attribute. Not supported until IE11. According to http://www.html5accessibility.com/tests/hidden.html, IE9 (and many others!) do not support 'aria-hidden' either.

[jessegreenberg]

JAWS reads out page structure as 5 regions, 1 Application, 6 headings, and no links.

@terracoda pointed out that this could be confusing to users or screen readers. With no links, they might not understand to 'tab navigate' through the page.

Hopefully users will understand how to use forms that do not contain links.

[jessegreenberg]

The navigation through the sim should loop from last element to first, skipping the address bar.

This would mean overriding the default browser behavior. This could be confusing or unconventional for users. If this is implemented, we will have to design another way for the user to reach the navigation bar.

[jessegreenberg]

Navigation order was incorrect between charge radios and reset button

I am unclear if this ocurred with 'tab' navigation or if the user used additional keys to encounter this behavior.

[jessegreenberg]

Balloon labels need to reference color, 'Yellow Balloon' and 'Green Balloon'

Done.

[jessegreenberg]

'Left paren' and 'right paren' read in reset balloon button description

Done.

[terracoda]

@jessegreenberg "I am unclear if this ocurred with 'tab' navigation or if the user used additional keys to encounter this behavior."
The user was pressing Shift Tab. He was going backwards. I think he went from Reset All, to Third Charge Radio, to Reset Balloons, to First Charge Radio. I'll double check the recording, again :-)

I checked video. This is correct.
He went in reverse order from Reset All, to Third Charge Radio, to Reset Balloons, to First Charge Radio.

[jessegreenberg]

Chrome incorrectly 'counts' the number of input elements in a fieldset

This seems to be a Chrome specific accessibility issue at the moment. Chrome 'counts' the legend and accessible description, adding these elements to the reported number of fieldset elements. For instance, NVDA + Chrome reads the following when navigating to the first input element:

<fieldset id="radio-button-group-14-35-417-492-484-474" role="radiogroup" aria-describedby="radio-group-description-14-35-417-492-484-474">
    <legend id="legend-14-35-417-492-484-474-494">‪Balloon Controls‬</legend>
    <input id="radio-button-14-35-417-492-484-474-468" type="radio" role="radio" name="18" aria-label="‪Remove green balloon‬" aria-checked="true">
    <input id="radio-button-14-35-417-492-484-474-471" type="radio" role="radio" name="18" aria-label="‪Add green balloon‬" aria-checked="false">
    <p id="radio-group-description-14-35-417-492-484-474">‪Toggle to conduct experiments with two balloons or just one.‬</p>
</fieldset>

Remove green balloon, radio button, checked, two of four

Occasionally in Chrome, the number of elements in the fieldset is not mentioned. Unable to track a pattern so far.

[jessegreenberg]

@terracoda, thanks for clarifying! That makes sense. I will try to recreate the issue.

[jessegreenberg]

'Partially checked' is read out for radio buttons on first read through

Looks like we need to add checked="checked" to the default radio button selection so that default choice will never read 'half-chekced' or 'partially-checked'. aria-checked doesn't do this on its own. See http://stackoverflow.com/questions/5592345/how-to-select-a-radio-button-by-default. This will need to be done in common code.

[terracoda]

@jessegreenberg "Screen reader pauses after screen summary"
To clarify: I meant to say "WITHOUT pausing". The screen reader does not pause at all after the Scene Summary. So, instead of interacting after the Navigation/Interaction cue, the user just kept listening. Personally, I think listening to the entire PDOM in one go is too much and not a good way to start off.

It seems screen readers and browsers may vary on this, so I am wondering if there is a way to stop things at the end of the Scene Summary and have the user choose what to do from there.

[jessegreenberg]

@terracoda, OK sounds good. I haven't found a way to do that yet, but we can take a look. I updated the checklist.

[terracoda]

@jessegreenberg, I would use checked on its own in HTML5 instead of checked="checked". Both are allowed in HTML5, but checked="checked" is XHTML syntax, I think.
checked, on its own is cleaner, in my opinion. Of course, you still need aria-checked="true" as well.

[terracoda]

Chrome incorrectly 'counts' the number of input elements in a fieldset

@jessegreenberg I think it may be safe to remove the <fieldset> and just use an <h3> in place of the <legend>.

[terracoda]

@jessegreenberg I quickly changed my static balloons-pdom in case that is helpful.
https://github.com/terracoda/experimental-play/blob/master/balloons-pdom.html

[jessegreenberg]

would use checked on its own in HTML5 instead of checked="checked".

Sounds good. I added 'checked' to the checked radio button, in addition to 'aria-checked' for the selected radio button. Tested well with NVDA + Chrome, IE, and Firefox.

[jessegreenberg]

He went in reverse order from Reset All, to Third Charge Radio, to Reset Balloons, to First Charge Radio.

Thank you for claryfing @terracoda! I was able to reproduce this with NVDA + Chrome. Commit phetsims/sun@bf63323 fixed this issue as well. Without the 'checked' attribute, there was no priority for the focus, so the highlight went to the closest radio button depending on direction of navigation. The focus now correctly goes to the checked radio of the group.

[jessegreenberg]

Visual focus does not move when users navigate with arrow keys to focusable items.

This works for buttons and the balloon, but not the radio button groups. Likely an issue for the RadioButtonGroup accessible peers.

Should non focusable items also receive focus when the virtual cursor is navigating content? For instance, the sweater has no input control, but would it be helpful for the focus highlight to surround the sweater when the user is exploring its descriptions?

[terracoda]

@jessegreenberg

Should non focusable items also receive focus when the virtual cursor is navigating content? For
instance, the sweater has no input control, but would it be helpful for the focus highlight to surround
the sweater when the user is exploring its descriptions?

This is a great question. It's worth discussing. Virtual cursor focus would have to be a visually different than real cursor focus, if we wanted to do this. I actually brought this up a long time ago, when I suggested that the Sim title should have some visual indication on page load, but the discussion didn't progress. I certainly find knowing where I am in a long text document helpful. Shall we run it by other folks?

[jobara]

@jessegreenberg and @terracoda, I was reading your above comments about adding a focus highlight when using the virtual cursor to navigate the sim. I'm not 100% sure what you are talking about, but I think you mean the situation when a user is exploring a sim using a screen readers virtual/browse mode; where the user can explore a page without actually interacting with it and not having to rely on the pages built in focusable elements for navigation. If that's the case I'm not sure how possible it will be to track the virtual focus. This is something that the AT knows about and is likely not passed along to the browser. In the absence of focus/hover events it likely won't be possible to trigger the styling. Here is a simple article that talks about the various modes and how in virtual/browse mode the screen readers is actually working with a buffered version of the document ( http://tink.uk/understanding-screen-reader-interaction-modes/ ). An AT might have an option to track it's virtual cursor itself. I think VoiceOver does this. Although in the sim this may be in the wrong location if the parallel DOM elements are not inline ( I haven't experimented with this myself ). Hope that helps.

[jessegreenberg]

@jobara, thank you for this explanation and information! It saved us lots of time. Your understanding was exactly correct. When I tried to change the SweaterNode so that it was represented by the description paragraph, it did not receive the focus event from interaction with the virtual cursor. As you said, will have no way to track AT virtual focus since it is not passed to the browser.

Thanks for passing along this documentation, I will look forward to going through it. Understanding these interaction modes will be very helpful.

[jessegreenberg]

Screen reader should be able to pause after screen summary.

I am also unsure if this is possible to force. It seems like it is up to the user to pause reading of the content after page load. Going through some documentation, I found http://webaim.org/techniques/screenreader/#how, specifically:

Screen reader users can pause if they didn't understand a word, and go back to listen to it; they can even have the screen reader read words letter by letter. When reading words letter by letter, JAWS distinguishes between upper case and lower case letters by shouting/emphasizing the upper case letters.

This is the only reference I have found, and I can't find any information about stopping the read with html or another API.

[jobara]

@jessegreenberg i believe that is correct. Also, there are users who like to orient themselves first by listening to the entire document being read out.

[terracoda]

@jobara and @jessegreenberg Great discussion. I am very familiar with both of these articles, and I've shared the Léonie Watson's article before, here on github somewhere. Yes, it is correct that users can pause reading and go back and forth and they do. In fact, there are multiple ways to stop the screen reader from reading. I learned in my first interview that some users are very patient listeners, more so than I expected. The fact that the participant was so patient, made me wonder if it would be useful to have some kind of pause right after the scene summary. Let's leave control with the user, a great accessibility principle, and see what happens in our next interviews.

[jessegreenberg]

@terracoda, I remember you posted that resource now. I didn't get a chance to go through it at that time, sorry about that! From the resource, I found this section very interesting:

NVDA will automatically enter/exit focus mode when the tab key is used to move focus on/off the form field, but not if the cursor keys are used. JAWS will automatically enter/exit forms mode whichever method is used to move focus to the field, although as of JAWS16 its possible to configure JAWS to ignore forms mode when navigating through content using the cursor keys. Both screen readers can be used to switch modes manually.

We have encountered this behavior and assumed that something was broken. Interesting to understand that this is NVDA behavior.

I would be very interested to know how many users know how and when to switch modes automatically. For now, one of our biggest challenge is to find aria roles to seamlessly transition between the two modes.

[jessegreenberg]

Related to

Visual focus does not move when users navigate with arrow keys to focusable items.

From Léonie Watson's article, I don't think this is an issue to fix.

It is necessary to forms/focus mode in order to use the cursor keys to cycle through radio buttons in a group. Being unaware of this can sometimes lead to the mistaken belief that the radio group is somehow flawed.

The virtual cursor alone will not interact with the radio button group correctly, and the browser will not know that virtual focus is over a radio button.

[terracoda]

Wonderful! @jessegreenberg thank you for highlighting the key points of this article that point exactly to the "issues". I think, I understand more clearly how screen reader navigation behaviour is different. In ChromeVox, the virtual cursor highlighting is built-in when it is navigating PDOM. The PDOM is off-screen, and not invisibly placed on top of the actual widgets. So, this is the kind of thing I was imagining, but this is a visual-bias.

As long at the labels are clear from a "blind" perspective, the user should know what to do to activate the control whether they got there with the arrow key or whether they got there with the tab key.

The tab key on a radio group allows the user to by-pass the group. Arrow keys are needed to arrow down into the group. This is the same way tabbed menus work, allowing for more efficient navigation and natural skipping of groups.

I have a new/old request. Can we change the Balloon Radios (there are only 2) into a toggle button. I think a toggle button make more sense for these switch-like interactions. There are many of these across simulations. Can we discuss this. It seems fewer radios the better :-)

[terracoda]

Also, I'd like to re-share a link to a "course" on The Accessibility Tree by Bryan Garavanta. I find this course difficult to read, but we should find some useful information in here, like the following:

The DOM itself has no direct access to the Accessibility Tree, nor is it possible to access the Accessibility Tree using JavaScript at this time.

The order of precedence is as follows:
1. The browser builds a DOM using HTML markup from the server.
2. The browser builds an Accessibility Tree using the DOM.
3. Assistive Technologies interface with the Accessibility Tree to customize functionality for the user.
4. The DOM changes as users interact with dynamic content.
5. The browser responds to events caused by these DOM changes and updates the Accessibility Tree accordingly.
6. Assistive Technologies recognize that the Accessibility Tree has changed when related events are fired, and convey these changes to the user.

This is why one control on a particular browser may be represented differently in the Accessibility Tree on another browser, even though both browsers are running on the same Operating System; using the same code.

[terracoda]

@jessegreenberg regarding:

JAWS intercepted arrow keys for dragging the balloon, and spacebar for releasing

Both NVDA and JAWS have inelegant commands to "pass key through" to the application:

• Jaws: Insert+3
• NVDA: Insert+F2

And in JAWS 16 or higher, there is a setting a user can turn on to permanently set application keys to override JAWS shortcuts. The steps are explained in the following article How to Bypass Navigation Quick Keys. This article also describes how web author's can use data-at-shortcutkeys to override screen reader shortcuts. Of course, this is only a hack for JAWS as explained by Léonie Watson in her blog post, Time to Revisit Access Keys. It seems there is no standards-based solution for overriding screen reader shortcuts.

I think we should try the JAWS data-at-shortcutkeys technique, on the Play Area section tag? It would be nice to see how it works with JAWS at least. It might look like this:

<section data-at-shortcutkeys = { ‘?’: ‘Key to open command shortcuts'},‘jw’: ‘Keys to jump to Wall’, ‘jn’: ‘Keys to jump to Near Wall'}, etecetera}>

I do not know how to represent an Arrow Key in the dictionary pair above.
Some people posted that these work arounds are better than a developer using "role=application".

[terracoda]

@jessegreenberg, @jobara and @emily-phet As per the the discussion on Accessibility APIs and the frustrations we are having with discrepancies and disparities across screen readers, this article by Bryan Garavanta, How Browsers Interact with Screen Readers and Where ARIA Fits in the Mix is also very informative. It explains the different Accessibility APIs and the biases of screen readers for particular browsers. I think I shared this article before (sorry for the duplication). We can use the article to inform a more narrow, but informed and rigorous testing protocol. JAWS is optimized for IE, NVDA works best with Firefox. VoiceOver works best on iOS. According to Garavanta,

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.

[jessegreenberg]

@terracoda, that is a great article, thank you for posting it. It contains great information on why browsers have varying levels of accessibility with each screen reader. Hopefully complex interactive components will eventually be accessible for all screen readers and browsers eventually. But for now this provides a more narrow scope for testing.

[jessegreenberg]

I do not know how to represent an Arrow Key in the dictionary pair above.

We will have to see how JAWS presents this information, if at all. I expect that the key value pairs will be read so hopefully we can describe the arrow keys in any way we wish. But perhaps it literally maps the key to be passed in? That would require key codes for things like the arrows, but I haven't found an example of that yet. I am going to test all of this now.

[jessegreenberg]

Regarding

Chrome incorrectly 'counts' the number of input elements in a fieldset

This is fixed by removing the 'radiogroup' role. NVDA + Firefox still correctly lists the number of input elements. Chrome just does not provide that information.

[terracoda]

@jessegreenberg I just had a meeting with David Best. It was very enlightening. We used skype to talk and then we connected with a tool called TeamViewer. He connected me to his computer. I could watch what he was doing on his computer and hear and see how he used JAWS. I asked him about some of the technical problems we have been having: disparity, role application, screen reader user levels (what users may configure). He agreed with Garaventa's assessment. We won't be able to make sims to accessible for every possible configuration of browser and screen reader. Go for the widest and use ARIA techniques correctly.

[jessegreenberg]

JAWS intercepted 'W' after pressing 'J' to jump to wall.

JAWS intercepted arrow keys for dragging the balloon, and spacebar for releasing

See #111.

[jessegreenberg]

JAWS seems to intercept keys even on a form element.

I observed this as well. data-at-shortcutkeys could be used to fix this for the keyboard help menu. Perhaps applying this to accessible peer of the screenViewContainer will allow ? to be passed through. Will test in #111.

[jessegreenberg]

@terracoda, that sounds like a great meeting. Looking forward to discussing this further with you at accessibility meeting.

[jessegreenberg]

New dev version deployed: http://www.colorado.edu/physics/phet/dev/html/balloons-and-static-electricity/1.2.0-accessible-instance.8/balloons-and-static-electricity_en.html?accessibility

[jessegreenberg]

Sometimes arrow keys change the focus highlight color, sometimes they don't.

This issue is related to our ongoing investigation of the application role and how the screen reader intercepts key key events. For browsers and readers that support the letter (WASD) keys, this hasn't been an issue.

JAWS reads out page structure as 5 regions, 1 Application, 6 headings, and no links.

This is an accurate structure description of the parallel DOM. If this is confusing to users, we will need to change the DOM structure in some way.

[jessegreenberg]

Since we are now up to accessible version 11 and new review items are listed under sim issues, closing this issue.