Add support for setting/changing the focus order for tab traversal

[phetsims]

We should add support for setting/changing the focus order for tab traversal. Right now the order is equivalent to the order added to the scenery.Scene, which is not often accurate. The simplest thing to do first may be to give nodes the ability to set the tabindex for their peers directly. Later we should investigate support for a higher-level support that makes it easy to set tab groups, (such as being able to tab through all elements in a control panel instead of jumping around).

[samreid]

From http://webaim.org/techniques/keyboard/tabindex

Drawbacks to tabindex
The main problem with tabindex is that it can create an illogical tab order, even though its very purpose is to ensure that the tab order is logical. For example, even if it might make sense to the developer to have the user tab halfway down the page to a specific link rather than to the main navigation, the user may get confused. It is best not to surprise the user with unexpected behaviors. Adding tabindex to hypertext links can be especially confusing for Opera users, due to the way in which keyboard accessibility works in Opera. Screen reader users are especially susceptible to getting confused at illogical tab orders. For one thing, an altered tab order creates a situation in which the normal reading order does not match the tab order. Screen reader users may become disoriented.
The other reason that tabindex can be a drawback is that developers may be tempted to use it as a way to make up for sloppy or illogical reading order. The best way to fix tab order and reading order is to alter the order of the content in the markup itself, rather than try to hide the problem by using tabindex.
Can tabindex be used legitimately to enhance accessibility? Yes, but because those instances are rare, it is probably best to pay more attention to the actual reading order, and forget about tabindex entirely.

[samreid]

A note from the above commit, I am defaulting all peers to tabindex=1 because tabindex=0 for any of the components was interfering with setting nonzero tabindex for any of the components.

[jonathanolson]

Changeset looks good. I will still prefer the higher-level nested tab-handling support when we can make it. Tabindex isn't as useful in documents (since document order is visual top-to-bottom, instead of the back-to-front that is more prevalent with Scenery)

[ariel-phet]

assigning to @jessegreenberg for issue hygiene, what is the status here? is this issue still relevant?

[jessegreenberg]

This issue can be closed. We have support for setting/changing the focus order for tab traversal with scenery/Node.setAccessibleOrder().

Later we should investigate support for a higher-level support that makes it easy to set tab groups, (such as being able to tab through all elements in a control panel instead of jumping around).

Since we adopted the Parallel DOM approach we essentially get this behavior for free with form elements such as radio button groups. 'Tab Group' behavior is defined by the browser/HTML. tabindex should generally be avoided since interactive elements receive focus implicitly.

We have also learned that reordering of the accessibility tree should also be avoided since the user tends to orient based on other elements in the document.