Editorial clarification suggested for AXAPI mappings for audio and video elements

[joanmarie]

Under audio and video for AXAPI, it says:

Note: UI controls within the audio element exposed as AXToolbar.

I assume that means the controls (e.g. play and pause buttons) are exposed as descendants of an accessible object with a role of AXToolbar. Or to put it another way, they are exposed on a toolbar. But reading the statement quoted above, it sounds like the play and pause button themselves have role of AXToolbar. Can this be clarified as an editorial change?

[jasonkiss]

Good call. Thanks @joanmarie. I've tried to clarify how the sub-DOM controls are to be exposed in the above commit ab5855f.

How does the new language for the audio and video mappings work for you? I basically borrowed and updated the language from the UIA mappings that were trying to express the same thing. So @boggydigital might want to take a peek, as well.

I also took the opportunity to update the AXSubrole and AXRoleDescription values based on what's implemented in webkit.

Should we be making similar overtures about descendant UI controls for IA2 and ATK? @asurkov?

Note that @cyns asked the more general question just over a year ago, in issue #3, about how we deal with elements that have sub-trees of controls or other other objects. Further discussion on this question should happen over there on issue #3.

[jasonkiss]

Have merged changes. Can revisit for other AAPIs if needed.