search

phetsims / scenery

Scenery is an HTML5 scene graph.
MIT License
54 stars 12 forks source link

pdomOrder working in combination with pdomVisible #1033

Open jessegreenberg opened 4 years ago

jessegreenberg commented 4 years ago

We would like to change the way that accessibleOrder works in combination with accessibleVisible. Currently accessibleOrder is implemented in such a way that if node with accessible content has an ancestor that is visible: false or accessibleVisible: false, it will NOT show up in the PDOM even if the pulled into another place in the AccessibleInstance tree. For example, consider Nodes A, B, C:

A accessibleOrder: [ C ]
  B accessibleVisible: false
    C

C with accessible content will NOT show up in the PDOM because it's parent has accessibleVisible false, even though it has been pulled under A with accessibleOrder.

@jonathanolson @zepumph and I met today to discuss. We agreed that this was not a bug, but expected behavior after the design discussed in https://github.com/phetsims/scenery-phet/issues/365. At that time we agreed that Node's with visible: false ancestors should NOT have content in the PDOM and so accessibleVisible: false should behave similarly.

Recently we encountered https://github.com/phetsims/molarity/issues/213 where this behavior was a surprise. We wanted to use accessibleOrder exactly like the above example and expected it to result in having C shown in the PDOM since it was pulled out from under B. See that issue for more information about this case involving ComboBox.

We expected that accessibleOrder would not just change placement in the AccessibleInstance tree, but change accessible visibility of the content because of this placement.

After brainstorming we decided on that a Node should have accessible content displayed if 1) It has a Visual trail with visible: true on every node AND 2) It has an accessible trail with visible: true AND accessibleVisible: true on every node. where

"Visual Trail" is Trail along parent-child chain rooted at a Display "Accessible Trail" is a trail back to a Display where every child points to an accessibleParent (or if none, a parent)

Current design implemented mostly with AccessibleDisplaysInfo.accessibleDisplays array. See there for more information. To begin this work, we would probably do something similar. We could have an array of Displays that satisfies 1), and an array of Displays that satisfies 2). Then content would be shown in the PDOM if the intersection of these arrays have any Displays.

One tricky part of this implementation is that it is possible for a Node to satisfy both 1) and 2) above, but its parents do not. Consider the following:

root
  A visible: false
    D order: [ E ]
  C order: [ D ]
  B accessibleVisible: false
    E <----- satisifies both, even though none of its parents or its accessibleParent satisfy both

E Visual Trail [root, B, E], E Accessible Trail [ root, C, D, E ]

So the current implementation that populates for accessibleDisplays using recursive traversal won't work.

Additional example diagrams from discussion ``` (display ) (display) + simRoot: order [listbox]+-------+ + simRoot: order [ ]+-------+ | + | | + | | | | | | | v | | v | | +-+ () | +-+ () | screen: accessibleVisible: false | screen: accessibleVisible: false | + visible:truee | + visible:truee | + | | + | | | | | | | | | | | | | | v | | v | | listBox+--------------------------------+ listBox+--------------------------------+ (display) ( ) (display) + simRoot: order [listbox]+-------+ | + | | | | v | | +-+ () | screen: accessibleVisible: true | + visible:false | + | | | | | | | | v | | listBox+--------------------------------+ ( ) ```
jessegreenberg commented 4 years ago

We need to decide if this is a worthwhile change. It is a pretty large amount of work and complexity. For ComboBox we are going to proceed without this change (so that we can publish Molarity).

We are going to digest a little and come back to this at the next a11y dev meeting to see if we have strong feelings for proceeding with this. Otherwise we may leave this and continue with current behavior of accessibleOrder and accessibleVisible.

zepumph commented 4 years ago

Over in https://github.com/phetsims/molarity/issues/213 and https://github.com/phetsims/sun/issues/565 @jessegreenberg ended up publishing molarity with the combobox listbox not constraining the virtual cursor inside of it. That felt like the right decision given the cost of this issue. Furthermore, we reached out to the ARIA working group to consult on this problem and they didn't think this needed to be changed.

In the future we may find another case where this inconsistency manifests as a bug.

We don't plan on working on this further right now. Unassigning and unlabelling.