phetsims / a11y-research Goto Github PK

There are some pretty good a11y testing tools out there, it would be nice to try running them with our sims. Testing could flag issues well before we go through user tesitng and save a significant amount of time. Here are a few notable ones:

https://achecker.ca/checker/index.php

• Created by the IDRC!
• Checks single HTML pages for conformance to accessibility standards.

http://wave.webaim.org/

• Created by Web AIM
• Is a visual tool that puts icons on the visual page
• Checks single page HTML pages, and has an API
• @terracoda has only ever used the single page

http://www.deque.com/products/axe/

• aXe: A free, open source, accessibility testing tool that runs right in the browser.
• https://github.com/dequelabs/axe-webdriverjs: Has an API for automated testing of accessibility features through Selenium.

https://tenon.io/

• Lead by a developer from the Paciello group
• @terracoda said this tool catches the most in her experience
• Has API for automated testing and continuous integration
• Very highly regarded
• Offers consulting and support
• Not a free service, but has a free trial

@jessegreenberg, I added WAVE to the list above.

It would be nice if we could style sun/joist/scenery-phet buttons when the user is pressing the keyboard key. The button should look 'depressed' when 'enter' or 'space' bar is down, and look 'flat' when the key is up.

Most user agents do not give the browser 'keyup' and 'keydown' events during interaction with a button, but intercept them and submit a single 'click' event. In this case we cannot style the button.

We should determine where this is true, and what events are actually passed to the browser. It might be the case that we can style the buttons during keyboard interaction without a screen reader.

This would be more difficult if the user agent provides the button with a 'keydown' and 'click' event, but never a 'keyup' event or something like that. (Once pressed, the button would always look pressed)

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

In Dec 5 meeting with @emily-phet and @jessegreenberg we brainstormed and discussed how we will make the PhET Menu accessible.
Goals:

1. Path of least resistance to an accessible solution
2. What we would like it to be

Relevant discussion document:

• https://docs.google.com/document/d/12jd7xKEt8P_EUwTrbhLuvIKkZEDaqdFgyQ-EXeLgGkE/edit#

Relevant Sample Code:

• https://github.com/terracoda/phet-templates/blob/master/a11y-menu-template.html

This was found in phetsims/john-travoltage#224. Is this a bug with JAWS or the way we are using the attribute?

When the aria-pressed attribute is removed from the element, this is no longer an issue for JAWS. We should create a simple test case to see if JAWS does this outside of the sim.

Using JAWS, elements which are created dynamically in a dialog are read even if they are marked as hidden. This is a JAWS bug and VFO should be notified.

Example JSFiddle with the bug:
https://jsfiddle.net/8q933y29/6/

@mattpen can you please grant a11y the standard set of GitHub labels?

With a simulation about to be published, we should think about Teacher tips or other documentation for these features.

phetsims/john-travoltage#251 illustrated why this would be helpful. In that case, there is a particular user setting for Safari that needs to be enabled for keyboard navigation to work.

@emily-phet who should begin looking into this or preparing content?

The PDOM view is a copy of the PDOM which is rendered alongside the simulation (which is in an iframe) so that the accessible content can be seen. This is useful for feature demonstrations and debugging. There are some improvements that could be made to this view.

Improvement suggestions were first put together in phetsims/balloons-and-static-electricity#190. That issue documents some stylistic changes that would make different portions of content easily distinguishable. It would also be nice to somehow show the inline ARIA attributes, which by default are not rendered by the browser. As we look at this more carefully, there are likely other improvements that could be made.

@emily-phet could you please comment on the priority of these improvements?

VoiceOver (VO) has many settings. I have posted a subset here. Adjusting the settings can drastically affect what live region content is spoken aloud and how much VO information is spoken aloud.

At some point I adjusted my settings to the point where I silenced "interactive alerts" (descriptions in live regions), rendering the sim unusable for testing on my machine. Today, I was carefully adjusting my settings again, and some how I turned "interactive alerts" back on again.

In this issue, I hope to investigate VO settings more deeply.

I am posting screen shots of my settings. I will add comments as I understand them better. @jessegreenberg, @emily-phet, @jobara, @jhung, you may want to compare your settings, or share how you have adjusted them?

General settings were left at default.

Verbosity settings has 4 categories: Speech, Braille, Text, Announcements and Hints
Speech at Medium seems to work well. High is the default. If I knew Braille, it likely makes sense to use the same setting for Braille. The default is high. I'm not including a screenshot for Braille.

There are many Text settings. I don't understand them all. I reduced repetition, punctuation and added some pitch settings.

Announcements

Hints - I reduced hint delay

Navigation settings. I think I left these at the default settings.

Web - Navigation setting must have Live Regions enabled.

@ariel-phet @kathy-phet
As part of the collaboration with Georgia Tech, we will be sending a survey out to the teachers regarding their use of PhET sims, and potential barriers or challenges they have with regard to sim use.

We would like to finalize this survey by April 18th, send out to a small number of people, refine, and send out to the PhET email list of teachers (and social media, etc.) on April 24th.

The idea is to send out a more general initial survey, and collect emails of those who would be specifically interested in follow-up surveys. Later we will ask more specific questions about technical access and use by students with disabilities to those who "opt in" to getting a follow-up survey.

Please take a look at our latest draft, and edit/comment as you see fit. If you could give your feedback by Friday, April 14th, that would be ideal.

If we provide VO with a number of alerts (say every 500 ms) then VO will interrupt itself when the next alert is set as the text content for the live element. Seems to be the case for all priority levels for ARIA alerts.

Discovered in phetsims/tasks#875, this repo should probably have a license. I'm not too familiar with it, so not sure what's appropriate.

Zoom is not easily accessible for remote interviews. Zoom claims to be committed to accessibility (https://zoom.us/accessibility) and should be notified why they are inaccessible for our needs.

Should they investigate our report, we might have a way to conduct remote interviews without relying on PhET-iO, which has proven to be challenging (see #2 (comment))

@emily-phet @terracoda could you please write in this issue what the problems are with Zoom that make it inaccessible? We can then submit a report to them.

From phetsims/balloons-and-static-electricity#205 we showed that JAWS does not allow for press and hold behavior with the arrow keys due to the way the AT injects 'fake' keyup events when the the user presses and holds an arrow key. Here is an example of the events when I press and hold the right arrow key without JAWS:

And with JAWS:

We should submit a bug report to Freedom Scientific about this issue.

@kathy-phet and @emily-phet and @zepumph are going to meet at the end of the month to talk more about long term employment, and I think it would be good for this to happen before our meeting so I have a better idea about what to expect from accessibility. @jessegreenberg when would be good? I was thinking sometime next week. Tuesday and Wednesday work well for me. Tagging @ariel-phet so he is in the know.

It would be good to have a central document, similar to 'how-to-instrument-a-simulation-for-phet-io.md` (but perhaps less verbose) about the steps needed to outfit a sim. This process will take time to refine and iterate, so it's good to get started now. @jessegreenberg and I are starting from the beginning with build-an-atom, so this seems like a great place to start.

From phetsims/balloons-and-static-electricity#164 and phetsims/john-travoltage#118.

When a some physical keyboards are used with Apple devices, the keyup event is fired with keycode = 0 incorrectly = 0. For complex keyboard interactions (pressing and holding behavior and tracking multiple key presses at once) keyup is required.

In addition, some standard HTML elements cannot be used with a physical keyboards on apple devices. <input type=range> does not work.

The errant behavior can be observed here: https://jsfiddle.net/25ejnztt/1/

A bug report should be submitted to Apple concerning this issue.

https://developer.apple.com/bug-reporting/

In github issue phetsims/scenery-phet#291, @jbphet had a concern about the wording of the Reset All alert, and suggested we change it from:

• "Sim screen restarted. Everything reset." to
• "Simulation screen has been reset."

At the PhET/IDRC Meeting (March 14) there was some agreement that this was a good change, but upon closer review @emily-phet and @terracoda would prefer not to change it.

This issue is to clarify pros and cons of the two versions, and to determine the best wording for the Reset All alert.

@emily-phet and @melbanyard met yesterday to discuss the related interaction between the home screen and the bottom navigation bar in multi-screen sims. We need to think about the home screen, multi-screen sims, and the bottom navigation bar together to see how to optimize the interaction for multiple screen sims.

I mocked up two not so clean html pages representing the Home screen and the Atom screen for Build an Atom. The Atom screen is using the the aria toolbar role for the bottom bar and not a the region role as discussed earlier.

Using Build and Atom as an Example:

• Home Screen
• Atom Screen

Unfortunately, the sample toolbar.js did not work for me out of the box, and the toolbar.css is not loading. I will need help to get a real sample toolbar interaction implemented.

You have to tab through the buttons in the examples. There is no special tab index management working.

This issue is related to issue #25.

Using a template for an example

• Home Screen Template
• Screen One Template

This repo might be a good place to document the current behavior of aria attributes and roles. This issue is the first.

Testing the behavior of aria-disabled, which behaves like:

Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.

For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.

The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

(https://www.w3.org/TR/wai-aria/states_and_properties#aria-disabled)

Remaining to-do list:

Development:

• Final Round of User Feedback
• Ensure PhET menu is accessible
• Code review (JO?)
• QA testing (Steele)

Sim Design:

• KeyboardHelp Button & Popup

Website Updates:

• Accessibilty Icons
• Accessibilty Filtering Options
• Sim page - Accessibilty dropdown - features & use info
• Help Center a11y features info

For accessibility, the PhET Menu should behave like a Dropdown menu. This is different than a Dialog in that there is no close button, it does not restrict navigation, and the menu will close once the user leaves the menu.

Here is an example:
https://staff.washington.edu/tft/tests/menus/simplyaccessible/index.html

In that example, the drop down menu is represented as:

<div role="navigation" aria-label="Main menu">
	<ul class="nav" role="menubar" aria-hidden="false">
		<li role="menuitem" aria-haspopup="true">
			<a href="">About</a>
			<ul data-test="true" aria-hidden="false" role="menu" class="show-menu">
				<li role="menuitem"><a href="" tabindex="0">News</a></li>
				<li role="menuitem"><a href="" tabindex="0">Governance</a></li>
				<li role="menuitem"><a href="" tabindex="0">Diversity</a></li>
				<li role="menuitem"><a href="" tabindex="0">ContactUs</a></li>
			</ul>
		</li>
		<li role="menuitem" aria-haspopup="true">
			<a href="">Academics</a>
			<ul data-test="true" aria-hidden="true" role="menu">
				<li role="menuitem"><a href="" tabindex="-1">Degree Programs</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Faculty</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Distance Learning</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Libraries</a></li>
			</ul>
		</li>
		<li role="menuitem" aria-haspopup="true">
			<a href="">Admissions</a>
			<ul data-test="true" aria-hidden="true" role="menu">
				<li role="menuitem"><a href="" tabindex="-1">Undergraduate</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Tuition</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Financial Aid</a></li>
			</ul>
		</li>
		<li role="menuitem" aria-haspopup="true">
			<a href="">Visitors</a>
			<ul data-test="true" aria-hidden="true" role="menu" class="">
				<li role="menuitem"><a href="" tabindex="-1">Events</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Campus Map</a></li>
				<li role="menuitem"><a href="" tabindex="-1">Parking</a></li>
			</ul>
		</li>
	</ul>	
</div>

It should be tested with screen readers. There are a few comments on the example page that suggest there could be a few issues like

The arrow keys work great without a screen reader, but if JAWS is running it seems to intercept keystrokes and not release them to JavaScript.

The original menu (Option 6) doesn't work as well as I would expect it to with screen readers.

Need a way to record audio (a must) and screen (not required, but ideal) during remote interviews - with minimal effort on the user's part.
In this Team Viewer video ("Online Meetings") it shows how to start a presentation, and add a user. If following this example, it is easy for the user to also share their screen, this looks like the closest use case to our needs. Need to double check that we're clear on:

1. What user needs to do to access meeting
2. That user can take over presenting
3. That doing this is accessible

Note: We would only consider this option with a user that approved screen recording, and that was able to relatively quickly set up Team Viewer on their end. If this isn't possible in about 5 minutes or less, we'll use a different (no screen recording) option.

From #13, @terracoda added some information about the semantics for PhET's navigation bar. Here is the content, copied from that issue:

I updated a sample html template for the sim’s bottom bar.
I used a footer element instead of a tool or menu bar. This might be more reliable and provide a nice landmark.

I've used some nav elements with aria-labels, so it sounds pretty good in Voice Over, but it’s still quite rough. The PhET Menu buttons are not being read out yet (when expanded), and are not navigable with arrow keys (when expanded), so I think I have done something wrong there. I've adapted some tips from Pickering's Inclusive Design Patterns.

Also, I am not 100% sure if sim screen navigation should go inside or outside this footer. This decision does not have to happen immediately, but soon.

The sample template is in my own repo at this link:
https://github.com/terracoda/phet-templates/blob/master/a11y-menu-template.html

@jesse, also, is this the active issue for this topic, or is issue #12, the proper place?

Note: Pickering has an nice pattern for using SVG on the button icon. I haven't included that as we likely do not need it in the hidden PDOM. It might be useful for other situations, though.

Note: I moved my HTML mock-ups to the A11y-Research repo. New links are:

• Bottom bar - two options
• PhET Menu Nested

A very basic PDOM for Ohm's Law is available here: ohms-law-pdom.html

Adding succinct version:
ohms-law-pdom-succinct.html

This example is completely static. The highlighted bits of content represent dynamic parameters in the sim.

This issue is to discuss ideas or improvements to this initial structure.

One question in particular is how best to represent the equation and the circuit.

@emily-phet, @jessegreenberg, @zepumph , and more can comment. Need to find everyone's handles.

We may need to discuss in more detail how to best communicate the visual difference between the focused and grabbed states during keyboard interaction.

Though this issue is directly relevant to Balloons and Static Electricity I'm putting this issue here as the discussion and decisions will help us with other sims which have focused and grabbed states.

Related design issues:

• Use of color to identify balloons visually and non-visually in phetsims/balloons-and-static-electricity#225 in comment phetsims/balloons-and-static-electricity#225 (comment)
• Add visual cue for Grab Balloon button: phetsims/balloons-and-static-electricity#206
• Reminder issue: Visual interaction Hints to Grab & Drag Balloon: phetsims/balloons-and-static-electricity#256

When incrementing a slider with value-text through the "VO + spacebar" keys, sometimes the old aria-value text is read out. See the following JSFiddle example to reproduce the bug.

https://jsfiddle.net/1j1y3s8p/15/

The following issue has a bunch of documentation on attempting to isolate the cause, but we have determined that this is a VoiceOver bug with the "increment" feature.

The Balloons and Static Electricity sim has thee different views for charges:

1. Show all charges (default)
2. Show no charges
3. Sow charge differences

We have described the first view (all charges) using relative amounts (none, a few, several, many). Beginning to explore design questions for describing the other 2 views in this google sheet. I will post questions for discussion in this issue.

Note that views 2 and 3 may be most relevant for teachers.

This bit me hard today - still not sure what is going on here. phetsims/john-travoltage#221 was the original issue.

When the "Keyboard Help Dialog" is opened with the keyboard, the "Keyboard Help Button" is removed from the focus order in Edge.

The parent of the button is the footer and it gets hidden correctly when the dialog opens. But when we try to set focus to the keyboard help button again, Edge won't focus it, and the button remains out of navigation order. Neither the button nor any of its ancestors is hidden or aria-hidden or has tabindex=-1.

It is almost like Edge isn't adding the button back into the DOM after removing the hidden attribute from the parent element. Explicitly setting hidden to false on the child elements fixes the problem.

If we can reproduce in a test case we should submit a bug report to Edge.

@jonathanolson, @jessegreenberg and I have been discussing the semantics of the the Sim's bottom bar in a few issues, but mainly in this one #25.

For accessibility, the hierarchical nature of HTML provides a reliable and robust way to create relationships between certain elements, and it does so quite easily.

For fuller code examples see example in #25 (comment), and #25 (comment)

Basically, we would like to be able to nest the list that PhET Menu button controls inside the bottom bar closer to the actual button:

<!-- Design pattern adapted from Pickering's menu button.-->
<nav aria-label="Sim tools and links">
  <button aria-expanded="false">PhET Menu</button>
  <ul hidden>
    <li>list of menu items</li>
  </ul>
</nav><!-- end PheT Menu Nav -->

In Scenery, we can't easily put the button and the hidden menu inside the nav element inside the parent bottom bar container.

ARIA features such as aria-controls are meant to create relationships between elements when there is not clear relationship in the DOM (PDOM in our case) in cases exactly like this; however, it is not yet well supported by AT. See the 2016 article, aria-controls is poop.

@emily-phet suggested I ask you about how difficult or easy it might be to build some more nesting capability into Scenery?

It would be nice to have your thoughts. No rush on this issue at the moment.

Do you have any thoughts on this?

Here's a possible interaction pattern playing with particles in My Atom's regions. The three regions and the particle buckets are marked up as 4 listboxes (see current Parallel Dom for the HTML being discussed in issue #43).

The user would use available action buttons for taking actions on selected listbox items (e.g., grab, select positions in regions, move within a region, and delete).

We could customize to simplify, using some of the strategies already mentioned, however,
I'd like to see how it works with a purely native approach.

Should I copy what I have from the design document section Idea 2 Interaction Pattern? Or just link to the design document?

@zepumph , @jessegreenberg , @emily-phet let me know what you think about these interaction patterns.

We ran into this in phetsims/build-an-atom#150, but we are sure to run into this again.

If a user action triggers programmatic setting of focus, to a new element, it can cause listeners attached to the blurred/focused elements to be triggered incorrectly.

For instance, say you have the following:

nodeA.addAccessibleInputListener( {
  click: function() {
    // do some stuff
   nodeB.focus();
} );

nodeB.addAccessibleInputListener( {
  keydown: function() {
    // do some other stuff
    nodeA.focus();
} );

When nodeB gets the keydown event, nodeA is focused. Since the key is still down, nodeA receives the click event immediately, and the callback will be unintentionally fired again.

Our workaround for now is to add a timeout that prevents nodeA from being focused until the key is fully up, something like

        setTimeout( function() { nodeA.focus(); }, 100 );

Is there a general way to handle this issue that doesn't involve a timeout?

I've committed a draft Parallel DOM for Build an Atom.

Is there a way to host it on github, so people can see the rendered page and not just the code?

Code is here:
https://github.com/phetsims/a11y-research/blob/master/html-sketches/build-an-atom/baa-pdom.html

Main features in this BAA PDOM

• aria listboxes marked up with HTML headings and lists with the role="listbox".
• accordions for the "Details About My Atom" marked up with the HTML details element.

@zepumph, @jessegreenberg, @emily-phet comments welcome.

EDIT from MK:

Hey look what I found! It renders it through github.

http://htmlpreview.github.io/?https://github.com/phetsims/a11y-research/blob/master/html-sketches/build-an-atom/baa-pdom.html

@terracoda I am noticing that in BASE, VO is reading the play area, then the scene summary, then the control panel, but the DOM looks like

Do you know if this is a VoiceOver setting that is reading things in the region out of order? Or is something else going on?

From meeting on 6/9/17, this repository will collect bug reports to be sent to browsers/AT. For organization, labels would be helpful to see issues related to this.

We already have labels:
dev:a11y
dev:sonification
design:a11y
type:bug

scenery repository has labels
scenery:to-submit-browser-bug
scenery:browser-bug

For third party a11y bugs, what about something like
a11y-research:platform-bug

platform-bug term includes both screen reader and browser. And having only one label for all bugs makes searching easier since that label can be searched or clicked on to see the list of all platform bugs.

Thoughts @emily-phet @terracoda @zepumph?

Related to #7 as we might want to have an accessibility feature checklist as we prepare to deploy accessible john-travoltage. @emily-phet started a draft checklist here:

https://docs.google.com/document/d/1jYx3wxNRxHHpMigxSFVvCRVFdB5-E-3_xbj9UI9uvWE/edit

From phetsims/scenery#299, @samreid found another checklist from http://w3c.github.io/aria-in-html/#custom-control-accessible-development-checklist:

• focusable Can you get to the control via the keyboard? Refer to Providing Keyboard Focus
• operable Can you use the control with the keyboard? Refer to Keyboard Navigation
• expected operation Can you use the standard keys for the control type to operate it. Refer to ARIA Widget Design Patterns
• clear indication of focus Can you easily see it when the control has focus? Refer to Visible Focus (WCAG2)
• label The control has a text label that is exposed as an accessible name in accessibility APIs
• role The control has an appropriate role exposed in accessibility APIs
  states and properties The control has any UI states and properties that it has exposed in accessibility APIs
• color contrast The control label/description/icon is perceivable/usable for low vision users (Use a color contrast checker.)
• high contrast mode The control is perceivable/usable when High Contrast Mode is enabled (e.g. Windows HC mode)

Found in phetsims/john-travoltage#243. Observed in a simple test case:
https://jsfiddle.net/9nkq8sL6/6/

When focus enters a Dialog in IE11 + JAWS, JAWS will read a certain amount of content and then stop, and read the form element in the Dialog that currently has focus. Content is still accessible for the virtual cursor.

In phetsims/john-travoltage#243, we believe this to be an IE11 bug.

@jessegreenberg @terracoda Not sure if this is being tracked elsewhere. If not, can you all put any links to examples you have here, for discussion?

See phetsims/john-travoltage#237. It will also interrupt any alerts that we are trying announce. A bug report should be submitted to Apple.

In phetsims/john-travoltage#210 we found that the aria-atomic attribute doesn't work as expected in some cases in Safari. We should create a simple test example using the attribute and submit a bug report if it sin't working in that case. Otherwise, we should understand why it isn't working in a PhET sim.

Unicode values are read inconsistently when used with aria-valuetext.
JSFiddle that isolates this problem: https://jsfiddle.net/s8m2spxc/3/

This was investigated and found in phetsims/john-travoltage#238

Part of the problem is that different VoiceOver voices read things differently.

Testing with voice "Karen" -

When focus lands on the first slider (using '\u2212' - "Minus Sign"), "Karen" reads the "Minus sign". When changing the value on that slider, the minus sign is never read.

When focus lands on the second slider (using '\u002D' - "hyphen-minus"), "Karen" does not read "Minus Sign", but when the value changes, the minus sign is read.

Testing with voice "Alex"

We have the exact same behavior as above, but when changing the value with '\u2212' - "Minus Sign" in the aria-valuetext, the unicode value "Minus Sign" is read.

Using the default voice works fine but any other voice doesn't read unicode "Minus Sign" when used in aria-valuetext.

Based on Dec 5 meeting with @emily-phet and @jessegreenberg regarding the accessibility of the Sim Navbar, it was suggested that several items be made into buttons and be relabeled with clearer text. We basically have a list of buttons (items that do things) and links (items that go places).

Current Menu Sample

• Options... (Opens options dialog with checkboxes)
• PhET Website... (Link)
• Report a Problem... (Link)
• Screenshot (Takes a screenshot)
• Full Screen (Goes into full screen mode)
• About… (Opens dialog with details about this Sim)

Draft Order, Labels, and Text to Discuss

• Options (Opens options dialog with checkboxes) [Button]
  • View options for this sim.
• Take a Screenshot [Button]
  • Take and save a screenshot of the sim.
• Full Screen [Button]
  • Use the sim in full screen mode.
• About this Sim [Button]
  • Design details about this sim.
• Report a Problem [Link]
  • Please let us know if you find a problem.
• PhET Website [Link]

Questions

• What do people think of the labels and help text above?
• Do we need help text?
• Do we need headings to label the menubar, and or the PhET Menu?

In the scene summary for a few sims I have seen a bullet that looks like

If you need to, check out the <a>keyboard shortcuts</a> for this sim.

The keyboard help dialog is typically opened with a button that just toggles its visibility. Is this shortcut necessary? If so can it be a button? If a link, is it OK if there is no destination?

From #1 we decided to investigate recording html5 audio from the microphone and combining that with some way to record the simulation:

• scenery input events would require addition of support for recording and playing back parallel dom events
• or we could phet-io instrument the simulation and record states, then write a script that does playback based on states.

I volunteered to help on this, noting that my time is somewhat tied up for the near future. It was suggested that @jessegreenberg help out as possible.

It looks like a good place to start investigation with the audio will be https://webaudiodemos.appspot.com/AudioRecorder/index.html

I'm marking this as high-priority to put it on my todo-list, and because @emily-phet said it would be helpful if it was available soon.

Found in phetsims/john-travoltage#242 by @phet-steele. His write up is great, so I am moving the documentation here:
Use this as an example case with the below steps: https://jsfiddle.net/1j1y3s8p/

First problem:

• Start with the slider at -7

  • Pay attention to the speed of the slider during this step. Hold the right arrow key down until halfway, then release. When holding, you will see the slider tick along relatively slowly.
  • After release, the slider will rapidly move right.

• Second problem:

  • Make sure you are now at the max of the slider (also this works at min), hold the right arrow key down for a short time (or left key if you are at min, try 3 seconds). Too long and you may crash JAWS.
  • After releasing from hold, press the left arrow key once. There will be a decent delay until the slider actually decrements to -6.

@terracoda @emily-phet, Last week @jobara and I found and tested an attribute called accesskey that might let us provide global hot keys to activate links and buttons:

http://www.w3schools.com/tags/att_global_accesskey.asp

The idea is that with a modifier key, you can activate a form element (like the Keyboard Help button) with a hot key no matter where focus is in the document.

@jobara and I tested this and it worked well on all AT/platforms.

The catch is that the modifier keys are slightly different for each browser, which might make it tough to document in the Keyboard Help Dialog. (see the table in http://www.w3schools.com/tags/att_global_accesskey.asp).

Is this something you would like to use?

@taliesin - I'm just wrapping up a book chapter this week. Please let me know when you'll be progressing the manuscript for CSUN, so we can coordinate. Looks like it's T-20 days to the due date!
Note - please send any outline/draft/specific details by email. I just wanted to open an issue about this for progress tracking.

Issue to discuss ARIA 1.1 additions and changes that might be helpful for us:

For example,

New properties aria-roledescription, aria-keyshortcuts, aria-placeholder, aria-current , aria-modal.

I am especially interested in aria-roledescription. I am thinking we can use this property to replace the screen reader utterance, "Application" with something more meaningful like, "Yellow Balloon Grabbed," as the user activates the application role upon pressing the "Grab Yellow Balloon Button".

There's a handy Change Log for ongoing changes to the new specification.

In Build an Atom there are 3 details panels that are collapsible. I'd like to explore what structures provide the best semantics, e.g., definition list, or un-ordered list, or something else.