have defined case for inert to map to aria-hidden "when an entire Document marked as blocked by a modal dialog subject."

https://github.com/w3c/html/commit/0e640e86e0acbcc40a44e8bb8dcbcd87b75ed631

see related discussion on https://code.google.com/p/chromium/issues/detail?id=264959

http://krijnhoetmer.nl/irc-logs/accessibility/20130925#l-91

(In reply to steve faulkner from comment #1)
> have defined case for inert to map to aria-hidden "when an entire Document
> marked as blocked by a modal dialog subject."
> 
> https://github.com/w3c/html/commit/0e640e86e0acbcc40a44e8bb8dcbcd87b75ed631
> 
> see related discussion on
> https://code.google.com/p/chromium/issues/detail?id=264959
> 
> http://krijnhoetmer.nl/irc-logs/accessibility/20130925#l-91

aria-hidden seems closer than aria-disabled. But since aria-hidden implementation differs from browser to browser then it brings same ambiguity level to inert mapping which is unfortunate.

Actually I wouldn't prune the inert subtree while Chrome developers would do (per your link) so it's again Firefox vs Chromium impl of aria-hidden.

My primary point against prune tree for aria-hidden (and inert) is it's not friendly to screen magnifiers softwares. I'd rather find ways to implement inert close to modal alert() dialog implementation.

(In reply to alexander surkov from comment #2)
> (In reply to steve faulkner from comment #1)
> > have defined case for inert to map to aria-hidden "when an entire Document
> > marked as blocked by a modal dialog subject."
> > 
> > https://github.com/w3c/html/commit/0e640e86e0acbcc40a44e8bb8dcbcd87b75ed631
> > 
> > see related discussion on
> > https://code.google.com/p/chromium/issues/detail?id=264959
> > 
> > http://krijnhoetmer.nl/irc-logs/accessibility/20130925#l-91
> 
> aria-hidden seems closer than aria-disabled. But since aria-hidden
> implementation differs from browser to browser then it brings same ambiguity
> level to inert mapping which is unfortunate.
> 
> Actually I wouldn't prune the inert subtree while Chrome developers would do
> (per your link) so it's again Firefox vs Chromium impl of aria-hidden.
> 
> My primary point against prune tree for aria-hidden (and inert) is it's not
> friendly to screen magnifiers softwares. I'd rather find ways to implement
> inert close to modal alert() dialog implementation.

Hi alex, thats why i was suggesting on IRC we need to define in the API guide as the granularity of the definitions using ARIA are lacking. as to your point about screen mags, whats the downside to pruning the tree when the acc tree is not supposed to be navigable?

(In reply to alexander surkov from comment #2)
> (In reply to steve faulkner from comment #1)
> > have defined case for inert to map to aria-hidden "when an entire Document
> > marked as blocked by a modal dialog subject."
> > 
> > https://github.com/w3c/html/commit/0e640e86e0acbcc40a44e8bb8dcbcd87b75ed631
> > 
> > see related discussion on
> > https://code.google.com/p/chromium/issues/detail?id=264959
> > 
> > http://krijnhoetmer.nl/irc-logs/accessibility/20130925#l-91
> 
> aria-hidden seems closer than aria-disabled. But since aria-hidden
> implementation differs from browser to browser then it brings same ambiguity
> level to inert mapping which is unfortunate.
> 
> Actually I wouldn't prune the inert subtree while Chrome developers would do
> (per your link) so it's again Firefox vs Chromium impl of aria-hidden.
> 
> My primary point against prune tree for aria-hidden (and inert) is it's not
> friendly to screen magnifiers softwares. I'd rather find ways to implement
> inert close to modal alert() dialog implementation.

checking in firefox, javascript modal alert() hides document tree altogether. the modal dialog window is that same dimensions as the viewport

(In reply to steve faulkner from comment #3)

> Hi alex, thats why i was suggesting on IRC we need to define in the API
> guide as the granularity of the definitions using ARIA are lacking. as to
> your point about screen mags, whats the downside to pruning the tree when
> the acc tree is not supposed to be navigable?

when you mouse over to zoom and screen magnifier relies on a11y tree to obtain coordinates/etc then you can't zoom pruned part. Not interactive means not zoomable, probably it's unwanted. Especially it's valid for aria-hidden dupe links on the web page.

(In reply to steve faulkner from comment #4)

> checking in firefox, javascript modal alert() hides document tree
> altogether. the modal dialog window is that same dimensions as the viewport

it seems Firefox puts a transparent window on top. So you can still can access underlying document but not interact with it.

(In reply to alexander surkov from comment #5)
> (In reply to steve faulkner from comment #3)
> 
> > Hi alex, thats why i was suggesting on IRC we need to define in the API
> > guide as the granularity of the definitions using ARIA are lacking. as to
> > your point about screen mags, whats the downside to pruning the tree when
> > the acc tree is not supposed to be navigable?
> 
> when you mouse over to zoom and screen magnifier relies on a11y tree to
> obtain coordinates/etc then you can't zoom pruned part. Not interactive
> means not zoomable, probably it's unwanted. Especially it's valid for
> aria-hidden dupe links on the web page.
> 
> (In reply to steve faulkner from comment #4)
> 
> > checking in firefox, javascript modal alert() hides document tree
> > altogether. the modal dialog window is that same dimensions as the viewport
> 
> it seems Firefox puts a transparent window on top. So you can still can
> access underlying document but not interact with it.

thanks alex, yeah i found the same thing after further testing, so its seems like the transparent window is important for SR's to avoid getting access to underlying 'disabled' content, question is how do we specify this? effectively it seems like the dialog element would have to have dimensions of viewport?

I agree with this approach as a mag. user during magnification won't see the rest of the page. They need assistance to limit the information the need to process.

(In reply to steve faulkner from comment #6)

> thanks alex, yeah i found the same thing after further testing, so its seems
> like the transparent window is important for SR's to avoid getting access to
> underlying 'disabled' content, question is how do we specify this?
> effectively it seems like the dialog element would have to have dimensions
> of viewport?

I'd say transparent window is an implementation detail. In Firefox it's used to prevent the user from accessing to underlying area. A11y API don't necessary need to make the same trick. But all interactive methods like takeFocus() shouldn't work on underlying controls and AT should have a way to know the boundaries of inert area to prevent vc cursor moving out (for example, IE's disabled state). Of course all of this can be reached by cutting the tree what should work in most cases but this approach is not user error-prone and we don't leave a choice to AT in processing the content.

OK so have done some further digging, keeping inert as aria-disabled is an option, but aria-disabled will need to change as it is currently only applies to descendants that are focusable, while inert appliss to all html elements

"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."
http://www.w3.org/TR/wai-aria/states_and_properties#aria-disabled

If it changed to apply to all descendants then AT would have a consistent indication of what is inert. 

The other way around this is to not have inert map to aria-disabled (change to 'no state' or simply remove (as its not an exhaustive list of mappings for html anwyay, just lists stuff that maps to aria),  and provide the mapping in the AAPI guide as it is there anyway. which seems like the sane thing to do:
http://rawgithub.com/w3c/html-api-map/master/index.html#att-inert

note: alex has emailed the IA2 list to ask for feedback on various approacheds:
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2013-September/001832.html

I’d rather use @aria-hidden (or propose a new @aria-inert for 1.1) than overload @aria-disabled. @aria-disabled is pretty much a 1:1 mapping of @disabled, and extendeding it to apply to inert subtrees only makes the accessibility tree more ambiguous.

FWIW, when web teams want to implement ARIA dialogs, we almost always recommend using @aria-hidden on the background contents if order to achieve something more like a real modal state, so I think that mapping is appropriate.

The one place it concerns me is that, when dialog is shown, it can be a defendant node of the inert ancestor. I’m not entirely sure @aria-hidden would work that way. Is it legitimate to expose a child of a hidden parent? Currently any hidden parent hides all descendants, but a change may be necessary to make @aria-hidden work in a CSS-like specificity cascade.

(In reply to James Craig from comment #11)

> The one place it concerns me is that, when dialog is shown, it can be a
> defendant node of the inert ancestor.

s/defendant/descendant/

(In reply to James Craig from comment #11)
> I’d rather use @aria-hidden (or propose a new @aria-inert for 1.1) than
> overload @aria-disabled.

> @aria-disabled is pretty much a 1:1 mapping of
> @disabled, and extendeding it to apply to inert subtrees only makes the
> accessibility tree more ambiguous.
> 
> FWIW, when web teams want to implement ARIA dialogs, we almost always
> recommend using @aria-hidden on the background contents if order to achieve
> something more like a real modal state, so I think that mapping is
> appropriate.
> 
> The one place it concerns me is that, when dialog is shown, it can be a
> defendant node of the inert ancestor. I’m not entirely sure @aria-hidden
> would work that way. Is it legitimate to expose a child of a hidden parent?
> Currently any hidden parent hides all descendants, but a change may be
> necessary to make @aria-hidden work in a CSS-like specificity cascade.

I agree neither aria-disabled nor aria-hidden fits well for inert subtrees. I like aria-inert area.

(In reply to steve faulkner from comment #10)
> note: alex has emailed the IA2 list to ask for feedback on various
> approacheds:
> http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2013-September/
> 001832.html

I emails the same on ATK list and there I've got a good feedback (https://mail.gnome.org/archives/gnome-accessibility-devel/2013-September/msg00003.html). In short SENSITIVE state should work for inert subtrees (when subtree is inert then SENSITIVE state is absent). Note, ATK has ENABLED state for disabled controls.

Also, it was suggested to use ACTIVE state on the dialog making it a separate window (https://mail.gnome.org/archives/gnome-accessibility-devel/2013-September/msg00009.html).

It seems there's no final agreement on it until we have more examples of inert usage (I was able to provide a dialog example only)

Related WebKit bug: http://webkit.org/b/112753

(In reply to alexander surkov from comment #14)

> It seems there's no final agreement on it until we have more examples of
> inert usage (I was able to provide a dialog example only)

Popup menus are another example that have an “inert background” state similar to dialogs. Side panels of carousels are sometimes rendered but inactive, too. We usually use @aria-hidden for that now, but @aria-inert may be a better fit for rendered that is just “inaccessible” in the current applications state or context.

(In reply to James Craig from comment #16)
> (In reply to alexander surkov from comment #14)
> 
> > It seems there's no final agreement on it until we have more examples of
> > inert usage (I was able to provide a dialog example only)
> 
> Popup menus are another example that have an “inert background” state
> similar to dialogs.

If you mean the content under popup menus then I'd say it's rather invisible state content than inert subtree.

> Side panels of carousels are sometimes rendered but
> inactive, too. 

can you please give me an example of this (a link to sceenshot maybe)?

(In reply to James Craig from comment #11)
> I’d rather use @aria-hidden (or propose a new @aria-inert for 1.1) than
> overload @aria-disabled. @aria-disabled is pretty much a 1:1 mapping of
> @disabled, and extendeding it to apply to inert subtrees only makes the
> accessibility tree more ambiguous.
> 
> FWIW, when web teams want to implement ARIA dialogs, we almost always
> recommend using @aria-hidden on the background contents if order to achieve
> something more like a real modal state, so I think that mapping is
> appropriate.
> 
> The one place it concerns me is that, when dialog is shown, it can be a
> defendant node of the inert ancestor. I’m not entirely sure @aria-hidden
> would work that way. Is it legitimate to expose a child of a hidden parent?
> Currently any hidden parent hides all descendants, but a change may be
> necessary to make @aria-hidden work in a CSS-like specificity cascade.

Hi James, mapping inert to aria-hidden (until something better comes along) is my preferred approach as it is an emerging standard way to implement in custom modal dialog scripts and achieves the desired outcome for AT users.

Checked in as WHATWG revision r8209.
Check-in comment: Make inert='' map to aria-hidden rathe than aria-disabled since aria-disabled only really does anything with interactive content.
http://html5.org/tools/web-apps-tracker?from=8208&to=8209

(In reply to alexander surkov from comment #17)
> (In reply to James Craig from comment #16)
> > (In reply to alexander surkov from comment #14)
> > 
> > > It seems there's no final agreement on it until we have more examples of
> > > inert usage (I was able to provide a dialog example only)
> > 
> > Popup menus are another example that have an “inert background” state
> > similar to dialogs.
> 
> If you mean the content under popup menus then I'd say it's rather invisible
> state content than inert subtree.

I don't menu menuitem content in menus that haven't opened yet. I mean the entire content of the rest of the page while a menu is showing. It's not invisible; it's displayed on screen. You just can't interact with it while you're in the modal state of an "open" menu, similar to the modal state of an "open" dialog.

Secondary click on any web page and you'll see what I mean. While the contextual menu is displaying, you can't interact with anything else. Explicitly clicking on something else triggers and implicit "dismiss" of the open menu, but does not trigger a click on the DOM element under the mouse, because it was inert at the time.

> > Side panels of carousels are sometimes rendered but
> > inactive, too. 
> 
> can you please give me an example of this (a link to sceenshot maybe)?

"Cover flow" carousels are one example.
https://www.google.com/search?q=coverflow&&tbm=isch

Added an issue for @aria-inert.

PFWG-ISSUE-623, currently on ARIA 1.1.
https://www.w3.org/WAI/PF/Group/track/issues/623

Thanks James.

(In reply to James Craig from comment #20)
> (In reply to alexander surkov from comment #17)
> > (In reply to James Craig from comment #16)
> > > (In reply to alexander surkov from comment #14)
> > > 
> > > > It seems there's no final agreement on it until we have more examples of
> > > > inert usage (I was able to provide a dialog example only)
> > > 
> > > Popup menus are another example that have an “inert background” state
> > > similar to dialogs.
> > 
> > If you mean the content under popup menus then I'd say it's rather invisible
> > state content than inert subtree.
> 
> I don't menu menuitem content in menus that haven't opened yet. I mean the
> entire content of the rest of the page while a menu is showing. It's not
> invisible; it's displayed on screen. You just can't interact with it while
> you're in the modal state of an "open" menu, similar to the modal state of
> an "open" dialog.
> 
> Secondary click on any web page and you'll see what I mean. While the
> contextual menu is displaying, you can't interact with anything else.
> Explicitly clicking on something else triggers and implicit "dismiss" of the
> open menu, but does not trigger a click on the DOM element under the mouse,
> because it was inert at the time.

not sure if it's right to continue discussion in this bug (probably we should have another one like 'add more examples of inert content'?) but these examples feels quite different from modal dialog example.

Traditionally elements having different z-index weren't mapped to a11y API other than hit testing thing. Would you say that two absolute positioned HTML boxes, one completely covers another one is also example of inert content?

> > > Side panels of carousels are sometimes rendered but
> > > inactive, too. 
> > 
> > can you please give me an example of this (a link to sceenshot maybe)?
> 
> "Cover flow" carousels are one example.
> https://www.google.com/search?q=coverflow&&tbm=isch

I see, thanks. So the example when clicking a side panel doesn't move it to the front, right?

(In reply to contributor from comment #19)
> Checked in as WHATWG revision r8209.
> Check-in comment: Make inert='' map to aria-hidden rathe than aria-disabled
> since aria-disabled only really does anything with interactive content.
> http://html5.org/tools/web-apps-tracker?from=8208&to=8209

I'm curious whether it'd be reasonable to keep the bug open (or mark it wontfix?) until aria-inert thing is resolved since it seems we all are in agreement that aria-hidden is not a best match for inert subtree.

Just reopen when aria-inert exists.

(In reply to alexander surkov from comment #23)
> (In reply to James Craig from comment #20)
> > (In reply to alexander surkov from comment #17)
> > > (In reply to James Craig from comment #16)
> > > > (In reply to alexander surkov from comment #14)
> > > > 
> > > > > It seems there's no final agreement on it until we have more examples of
> > > > > inert usage (I was able to provide a dialog example only)
> > > > 
> > > > Popup menus are another example that have an “inert background” state
> > > > similar to dialogs.
> > > 
> > > If you mean the content under popup menus then I'd say it's rather invisible
> > > state content than inert subtree.
> > 
> > I don't menu menuitem content in menus that haven't opened yet. I mean the
> > entire content of the rest of the page while a menu is showing. It's not
> > invisible; it's displayed on screen. You just can't interact with it while
> > you're in the modal state of an "open" menu, similar to the modal state of
> > an "open" dialog.
> > 
> > Secondary click on any web page and you'll see what I mean. While the
> > contextual menu is displaying, you can't interact with anything else.
> > Explicitly clicking on something else triggers and implicit "dismiss" of the
> > open menu, but does not trigger a click on the DOM element under the mouse,
> > because it was inert at the time.
> 
> not sure if it's right to continue discussion in this bug (probably we
> should have another one like 'add more examples of inert content'?) but
> these examples feels quite different from modal dialog example.
> 
> Traditionally elements having different z-index weren't mapped to a11y API
> other than hit testing thing. Would you say that two absolute positioned
> HTML boxes, one completely covers another one is also example of inert
> content?

I'm only referring to inert content as defined by the @inert attribute or the inert state of a dialog. I think it'd be flaky to infer an inert state form CSS positioning unless the HTML or CSS specs defined some specific pattern to match.

> > > > Side panels of carousels are sometimes rendered but
> > > > inactive, too. 
> > > 
> > > can you please give me an example of this (a link to sceenshot maybe)?
> > 
> > "Cover flow" carousels are one example.
> > https://www.google.com/search?q=coverflow&&tbm=isch
> 
> I see, thanks. So the example when clicking a side panel doesn't move it to
> the front, right?

Implementations usually have invisible "previous" and "next" buttons positioned over the inert side panels, so you're clicking on active buttons rather than inert content.

(In reply to Simon Pieters from comment #25)
> Just reopen when aria-inert exists.

What if never exists? Even if there's no good ARIA analogue for inert subtrees then it doesn't mean that AT API don't have a proper mapping for it. See, for example, ATK discussion: https://mail.gnome.org/archives/gnome-accessibility-devel/2013-September/msg00003.html, aria-hidden wasn't their choice.

PF group decided to forego @aria-inert entirely b/c ARIA can't provide the event silencing and focus management that @inert would have provided.