ACTION-1541: Investigate and propose mappings for aria-modal property for axapi.

Propose AXAPI: ModalAttribute for window objects.

Sent email to James:
https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0077.html

Related WebKit bug:
https://bugs.webkit.org/show_bug.cgi?id=138566

Another related webkit bug states, "Should be accessibilityViewIsModal on iOS. Waiting to hear back about AX API implementation." [1]

Holding pattern?

[1] https://bugs.webkit.org/show_bug.cgi?id=146013#c0

Current webkit bugzilla is "in progress". Will keep monitoring it and hope it's done by the 1.1 release.

Currently "resolved/fixed" in webkit bugzilla:
138566

Found this on the Apple Developer Site:
https://developer.apple.com/library/mac/documentation/AppKit/Reference/NSAccessibility_Protocol_Reference/index.html#//apple_ref/occ/intfp/NSAccessibility/accessibilityModal

But, nothing there to say what a tester should see in the Accessiblity Inspector

I completed action-2038. Pasting the comment from that action so it's in one place (and the dots are to force indentation because tracker is stripping/ignoring whitespace chars).

=========================

Using the OS X accessibility explorer to examine the accessibility trees with the modal dialog showing versus not, I'm not seeing any difference regarding inclusion of the background content in the tree. And VoiceOver still lets me read it.

HOWEVER, I modified the Layout Test in question to dump the accessibility tree when the modal dialog was showing. Results:

AXRole: AXWebArea AXValue:
....AXRole: AXGroup AXValue:
........AXRole: AXHeading AXValue: 3
............AXRole: AXGroup AXValue:
................AXRole: AXButton AXValue:
................AXRole: AXButton AXValue:

Then I did the same for when the modal dialog was dismissed. Results:

AXRole: AXWebArea AXValue:
....AXRole: AXGroup AXValue:
........AXRole: AXStaticText AXValue: Other page content with
........AXRole: AXLink AXValue:
............AXRole: AXStaticText AXValue: a dummy focusable element
....AXRole: AXGroup AXValue:
........AXRole: AXButton AXValue:
....AXRole: AXGroup AXValue:

So at least as far as WebKit/Safari is concerned, when the modal dialog is showing, the background content is pruned from the tree; when the modal dialog is not showing, the background content is present in the tree.

So my original theory seems to be correct. What *might* (??) be the case is that some of the support will need to be implemented in the accessibility clients. But that would be a question for Apple.

Having reviewed this, I find that I want a simple answer (if there is one): what should go into the AXAPI mapping for aria-modal?
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalTrue
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalFalse

Repeating my last note with a suggsetion:
Having reviewed this, I find that I want a simple answer (if there is one): what should go into the AXAPI mapping for aria-modal?

Something along the lines of:
"
When aria-modal='true', the modal content is asserted, and the rest of the AXAPI accessibility tree that represents the non-modal content (the "background") is pruned from the tree, but put back when the modal content is removed.
"
?

https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalTrue
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalFalse

Changes made:
https://github.com/w3c/aria/commit/ac6d96fd5b25ddb0ee05a25e39a0dd68abbc3f68

Rawgit:
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalTrue
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaModalFalse

Events:
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#event-aria-modal

Reviewed and approved at AAPI meeting 12-Apr-2016; closing.