Inert subtree section is missing requirement that it should NOT be exposed to accessibility

[cookiecrook]

The inert subtrees portion of the spec says:

When a node is inert:

• Hit-testing must act as if the 'pointer-events' CSS property were set to 'none'.
• Text selection functionality must act as if the 'user-select' CSS property were set to 'none'.
• If it is editable, the node behaves as if it were non-editable.
• The user agent may ignore the node for the purposes of find-in-page.

…but it does not acknowledge that inert subtrees should be hidden from accessibility APIs and assistive technology. To my knowledge, this understanding is shared by the accessibility teams of every major vendor, so I was surprised to not see it explicitly mentioned in the spec. If there is disagreement on this point, I'm unaware of it.

The inert explainer introduction makes it clear that:

If an Element is inert, it is completely non-interactive: it isn't targeted for any user interaction events, and it is removed from the focus order, and it is not exposed to assistive technology.

If there is no disagreement, this shared understanding should be codified with another bullet such as:

• The user agent must not expose the node to accessibility APIs or assistive technology.

[nt1m]

The reason I did not add this requirement is because I was told this belonged to the ARIA spec, not HTML, but yeah, I think adding it makes sense.

If there is no disagreement

I believe Chrome also makes inert behave like aria-hidden. @Loirooriol Can you confirm?

Not sure about Firefox. cc @emilio

[cookiecrook]

@robdodson @alice @scottaohara

[cookiecrook]

I was told this belonged to the ARIA spec

Not in the ARIA Spec to my knowledge, but maybe the person telling you that was referring to the HTML-AAM doc where more detail could be included.

[Loirooriol]

I believe Chrome also makes inert behave like aria-hidden.

That seems to be more or less the case. Inert elements are ignored and invisible like aria-hidden.
Note that the contents of an inert iframe are considered to be inert for a11y purposes, even if they can still be e.g. focused programmatically since they aren't really inert (#7605).

[jcsteh]

…but it does not acknowledge that inert subtrees should be hidden from accessibility APIs and assistive technology. To my knowledge, this understanding is shared by the accessibility teams of every major vendor,

I have some pretty major concerns about this. See w3c/html-aam#295 (comment).

[jcsteh]

Note that the contents of an inert iframe are considered to be inert for a11y purposes, even if they can still be e.g. focused programmatically since they aren't really inert (#7605).

That seems potentially bad. If something in the iframe was focused programmatically, focus would either go to limbo or to the nearest ancestor in the a11y tree. Either way, an AT user is unable to interact while other users can (at least with the keyboard). If I understand correctly, a mouse or touch user can't really interact, though, so maybe this is just an obscure edge case we don't need to worry about too much. Regardless, the a11y behaviour in this case should probably be specified.

[Loirooriol]

Either way, an AT user is unable to interact while other users can (at least with the keyboard)

Note that sequential navigation will not move focus into an inert iframe #7605 (comment). So this only matters if the focus goes there programmatically. But yeah, once the focus goes there, sequential navigation works inside the inert iframe.

If I understand correctly, a mouse or touch user can't really interact

Yes, pointer-events: none prevents it, we have interoperability, just needs to be specified in w3c/csswg-drafts#7069

focus would either go to limbo or to the nearest ancestor in the a11y tree.

I'm not an a11y expert. Contents of an inert frame shouldn't be considered to be inert for webexposed features due to #7605. I was initially planning to not consider them inert in any case. But considering them inert only for a11y purposes was suggested by @aleventhal.

[cookiecrook]

…if something in the frame was focused programmatically,

I agree that should be resolved. If focus is assigned to inert contents, maybe the inertness should be invalidated for all.

[cookiecrook]

But back to the edit suggestion, perhaps @jcsteh objects to the “not exposed” language. If so, we could switch to ~“hidden or disabled.”

• The user agent must ensure the inert content is hidden or disabled in accessibility APIs.

This way, Gecko can expose inert as disabled, so AT has a way to get at it if focused, and some clauses in ARIA describe what to do when hidden content achieves focus through any means.

[jcsteh]

The challenge with "hidden or disabled" is that different browsers will probably do different things, and thus AT doesn't get a consistent experience.

To summarise, my two concerns are:

1. Hidden is only appropriate if it is clear that inert should only be used for cases where content is visually hidden or visually obscured in such a way that it is not intended to be understood. Otherwise, an AT user misses out on info that is perceivable visually. If we agree on this (there are use cases in the explainer that do not agree), this appropriate usage should be made clear in the spec.
2. I worry that some magnification AT might depend on the a11y tree. Partially obscured content is still visible, so magnifiers may want to magnify it. But if it's removed from the a11y tree, that is going to be a problem. However, we don't know if this is a real problem or not without consulting magnification AT vendors.

[cookiecrook]

Magnifiers are always able to magnify any visible content, even if it’s the edge of an inert carousel view behind the active view. Some features may not work, like speaking the label for partially obscured inert content, but I would argue that’s correct behavior for a valid use of inert.

I agree that the spec should be explicit about how inert is expected to be used, how authors should avoid misuse, and how engines could recover from detectable authoring errors.

However, even with the potential edge cases you’ve mentioned, using inert as specified would finally allow accessibility-conscious and accessibility-naïve web authors to implement modal states in a reasonably accessible manner. Currently, doing so is trivial on native platforms, but nearly impossible on the Web.

Everyone acknowledges tools can be misused, but the potential misuse of inert will be much, much, much less likely than the techniques currently and frequently used to “fake” modal views. Web authors are now forced to use complex combinations of keyboard traps, aria-hidden, focus prevention outside the modal, and other techniques that are almost never implemented correctly. Inert is objectively better than the alternatives already being used.

Perhaps you could suggest some language you think would reduce your concerns?

[jcsteh]

Perhaps you could suggest some language you think would suffice.

Taken from Alice's suggestion in w3c/html-aam#295 (comment) with some minor changes:

An inert subtree shouldn't contain any content which is critical to understanding the page. Content in an inert subtree will not be perceivable by all users, and won't be interactive, so content shouldn't be inert unless it is also visually obscured in some way. For individual controls, the disabled attribute is probably more appropriate. As an example of visually obscuring inert content, content which is made inert by a modal dialog element will typically be either completely obscured by the dialog, or partially obscured by the dialog's backdrop.

I'd argue this should be normative because this will be the mapping for APIs. This is not a "maybe"; it's a "definite" (as per spec) that some users absolutely will not perceive the content.

Magnifiers are always be able to magnify any visible content, even if it’s the edge of an inert carousel view behind the active view. Some features may not work, like speaking the label for partially obscured inert content, but I would argue that’s correct behavior for a valid use of inert.

That seems reasonable.

However, even with the potential edge cases you’ve mentioned, using inert as specified would finally allow accessibility-conscious and accessibility-naïve web authors to implement modal states in a reasonably accessible manner.

For sure. However, as currently specified, uses of inert other than visually hidden/obscured content are considered valid as per the spec, and such usage would be harmful for AT users.

[scottaohara]

agree on these points, and in lieu of a much longer response i had written but have not yet posted, i have a number of suggestions I will post sometime tomorrow where the spec's mention the inert state and inert attribute could be updated to make it more clear the ramifications/use cases.

I understand the implications of authors not using this attribute correctly, but I'm very concerned with also making appropriate use of the attribute insufficient to the attribute's intent. Authors can presently use a combination of aria-hidden=true, disabled, tabindex=-1 and CSS properties to emulate what inert will do for them by default - but not nearly as well and thus creating their own accessibility issues that inert should otherwise help solve for.

[scottaohara]

Taken from Alice's suggestion in w3c/html-aam#295 (comment) with some minor changes:

i have a similar / updated version that i was going to post tomorrow. Also highly agree that this is not just a note, but there is normative guidance here and there are opportunities for further author guidance to reinforce and provide conformance checker examples

[cookiecrook]

I also agree with including Alice’s text (w/ Jamie and Scott’s edits) as normative guidance, and pair it with the behavior bullet in the original issue description.

[scottaohara]

OK, here are the additional thoughts I had on this (unfortunately I cannot attend the HTML triage meeting where this issue will be discussed, so thanks/apologies for the long response here):

Regarding an iframe within an inert subtree, I would expect that to be inaccessible to everyone, and not just for a11y purposes. Unless I'm missing something. While I understand that the sub-document nor its content would necessarily be marked as inert, I would expect that it would not be possible for someone to interact with this content, nor have the iframe or content of the sub-document receive focus.

---

Regarding inert in general - I have some thoughts on some updates to the spec and further author guidance to help mitigate against potential author misuse. (I would think that even further author guidance could be added to MDN - as @nt1m and I discussed offline)

Per the 6.3 inert subtrees, I would submit that user agents 'should' ignore the node for the purposes of find-in-page. Being in the inert subtree, someone shouldn't be able to access that content, so I'm not sure what the use case would be to include it in the found results, but not allow access to it.

Regarding the note that says

Inert nodes generally cannot be focused. Inert nodes that are commands will also get disabled.

Is mentioning 'disabled' correct here? Controls that are disabled should not participate in form submission - but a multi-step form where different parts of the form become inert when they are not presently in view (so that they can transition into view when necessary to interact with), those inert controls should not be 'disabled' because their values should take part in the form submission.

I think this should probably be revised to not mention that the controls are disabled, but rather they are to be treated as if they were hidden, and presently non-interactive to all users.

Regarding 6.3.2 The inert attribute, I agree with @jcsteh and @alice that there are aspects of this 'note' which should be normative guidance. As I mentioned in my earlier comment, I revised it a bit further from Alice's original suggested draft and what Jamie's updated suggested above.

An inert subtree should not contain any content or controls which are critical to understanding or using aspects of the page which are not in the inert state. Content in an inert subtree will not be perceivable by all users, and won't be interactive, so content should not be inert unless it is also visually obscured in some way.

The following are bits that could remain notes/examples to expand on the above:

As an example of visually obscuring inert content, content which is made inert by a modal dialog element will typically be either completely obscured by the dialog, or partially obscured by the dialog's backdrop.

For individual controls which are as not presently actionable, the disabled attribute, rather than the inert attribute would be more appropriate.

I think that further author guidance could be provided here to stress that inert is best used for instances where UI is fully, or almost entirely obscured or visually hidden. Further emphasizing guidance that inert is not appropriate to use on individual controls could be provided and even become conformance guidance.

E.g., the following is a very basic example of something authors must not do, as this would allow someone using AT to access everything but the link

<p>
  Some text goes here <a href=... inert>and this link text is important</a> to understand the full sentence.
</p>

Where if that paragraph were visually obscured in some way (an added style attribute is provided to emphasize this), the following would potentially be the appropriate way to mark it up, as now all the content would be hidden and a visual style to indicate its (current) inactive state is provided:

<p inert style="opacity: .5;">
  Some text goes here <a href=...>and this link text is important</a> to understand the full sentence.
</p>

Additionally, per #7808 (comment), if there is guidance that could be written to indicate that <body inert> is likely a very bad idea unless a dialog (or potentially some other top-layer popup is presently active). Arguably if a document is found to be marked as completely inert, and there is no content that is available outside of an inert subtree (or in the top layer), then the inert state should be ignored.

Edit: briefly mentioned with @nt1m that, not necessarily part of this issue, but spec'ing the concept of inert=false to allow content within an inert subtree to be available is probably a good idea to consider. Similar to visibility: visible being used to re-expose content within a visibility: hidden parent.

Thanks!

[Loirooriol]

nor have the iframe or content of the sub-document receive focus

How do you solve the cross-site leak?

concept of inert=false to allow content within an inert subtree to be available is probably a good idea to consider

@othermaciej disagreed in WICG/inert#69 (comment)

[scottaohara]

How do you solve the cross-site leak?

I personally do not know, nor do I think that's necessarily for me to solve. However, there are accessibility concerns with allowing for such content to receive focus. Is this author guidance, or something that browsers could help prevent, without cross-site leaking?

re: the disagreement about inert=false. I am not reading that comment as a specific disagreement to the potential allowance for such a feature? But if it is, then I would suggest that as time has elapsed, maybe personal opinions can be reconsidered when presented with valid use cases where it could be helpful. But, as mentioned in my previous comment " not necessarily part of this issue", but something I didn't want to get lost.

[zcorpan]

Would it be correct to map inert to aria-hidden=true?

[Loirooriol]

Is this author guidance, or something that browsers could help prevent, without cross-site leaking?

I don't think so, since things can become inert without the author explicitly doing it, e.g. opening a modal dialog. And preventing focusability, text selection, etc. in a way that the nested document can't detect that seems hard/impossible.

Would it be correct to map inert to aria-hidden=true?

It does other things like pointer-events: none, user-select: none, no focusability, ...

[zcorpan]

@Loirooriol indeed. I was thinking only for the purpose of the mapping to accessibility APIs. I believe aria-hidden=true is excluded from the accessibility tree, and so is is not reachable with AT. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/10283

[scottaohara]

@zcorpan had been mentioning that over in w3c/html-aam#295 (comment). some additional mappings to reference the non-focusable nature. but yeh. hidden to the a11y api

[domenic]

We discussed this at the triage meeting #7919, with the conclusion that we should take the following actions:

• HTML-AAM should define mappings for inert="", just like it already does for many other attributes. It looks like this is being done in Addition: inert attribute mappings w3c/html-aam#410 .
• We should have a more general discussion about cross-linking from HTML to HTML-AAM's attribute mappings, to improve discoverability. I just opened Add linkage between attributes and HTML-AAM #8055 for this.
• We should expand the spec's normative authoring guidance for inert="", and/or any documentation like MDN, to be as helpful as possible. It looks like @scottaohara is taking the lead there in Inert subtree section is missing requirement that it should NOT be exposed to accessibility #7796 (comment) .

So I think the original purpose of this thread has moved to w3c/html-aam#410. We can keep this issue open to track the authoring guidance item, or if people want we could create a new issue to discuss that. Either way, @scottaohara, can we count on you to take point on that effort? (Of course with the understanding that we're all busy and there's no time limit here; I just want to make sure nothing is falling through the cracks.)

[scottaohara]

@domenic yes, apologies, I have been meaning to get to this and create a pull request to make some edits to the content of 6.3, and add some specific author guidance based on my previous comment in this thread.

[clshortfuse]

Exclusion from tab order also isn't expressed as a requirement.

I filed an issue about how similar inert is to hidden containments (see above), and maybe bringing them both together in some way can solve this issue and a possible performance concern currently in all browsers (HTMLDialogElement.showDialog() is prohibitively too slow IMO)