"inert" attribute


#21

Also:

Disabling the entire UI while in an inconsistent state, such as showing a throbber/loading bar during unexpectedly slow loading.

Wouldn’t that be a modal / blockingElement? And:

A slide show or “cover flow” style carousel may have non-active items partially visible, as a preview - they may be transformed or partially obscured to indicate that they are non-interactive.

Wouldn’t the “active item” here be a blockingElement of said non-active elements (ie. this also sounds like a modal)?


#22

Hm I’m not sure about that. A few examples:

An offscreen responsive side-nav. You may not want AT announcing this as it’s not very useful. Another use case is cross-fading elements with interactive content, for example, cross fading two tweets where each might contain anchors. If you have a carousel of tweets it’s not very useful to step through all 10 of them and say “disabled” over and over. However in a form, “disabled, button” can be useful to hear.


#23

I think it’s really only the “form content” example which is potentially controversial there.

Re modal:

  • Yes, a throbber would work well as a “blocking element” if it was the whole page that needed to be made inert; however, you can imagine leaving the toolbars/chrome available while the main content loads
  • No, I don’t think the “cover flow” example is really a blocking element, since conceptually the active element isn’t “blocking” the other elements, and it certainly isn’t blocking the whole document (as it would be if using a blockingElement type interface

#24

I think a lot of folks use disabled on form controls for the built-in styling as well. Not seeing that effect when you apply inert may give them pause or discourage them from misusing it.


#25

I don’t think disabled form elements fit in the same category as a potentially inert element. Form elements, make sense for users to know about because there may be some reason a form element is disabled and can eventually be “un-disabled” by a user interaction for instance. Hence, why form elements should be detected and announced by AT.

inert elements, on the other hand, are elements that would never be helpful for a user to know they exist in the DOM. I would go as far to say that AT shouldn’t even detect inerted elements because, theoretically, they should be in another “sandbox” (for lack of a better term) from the non-inerted elements in the DOM tree.

I favor an API that treats inert differently from disabled elements and hidden elements. I agree that the hidden attribute has too many weird implementation details, so I wouldn’t encourage extending/modifying it for this approach at this point.


#26

I’d fully support this attribute, sorely needed to avoid the classic “set aria-hidden=true, and then iterate over all focusable elements and set tabindex=-1” hassle.

One aspect that will need to be spec’d (likely elsewhere in the HTML spec?) is what happens if focus (and accessibility focus/caret) is currently in an element which is then set to be inert. Assume it would be lost/reset to the start of the document (unless authors explicitly manage the focus themselves after setting inert, of course).


#27

Great question. I think the existing focus fixup rules actually answer this (emphasis mine):

When the designated focused area of a control group is removed from that control group in some way (e.g., it stops being a focusable area, it is removed from the DOM, it becomes expressly inert, etc), and the control group is still not empty: designate the first non-inert focused area in that control group to be the new focused area of the control group, if any; if they are all inert, then designate the first focused area in that control group to be the new focused area of the control group regardless of inertness. If such a removal instead results in the control group being empty, then there is simply no longer a focused area of the control group.

i.e. focus is reset to the start of the document, unless authors manage focus.


#28

oh, perfect. i vaguely remembered there had been some recent work on focus…great to see the inert part is already covered (may be worth cross-referencing this from the explainer?)


#29

Cross-referencing which part, exactly? (Or, care to make a PR on the explainer?)


#30

This sounds reasonable to me for many of the stated reasons (in both the explainer and your thoughts here), and so I’m cautiously supportive. Caveat: I’m saying this without thinking deeply about the implementation and so am unaware of gotchas… Note Firefox hasn’t implemented the dialog element yet…


#31

disabled repurposing problems:

  • Forms are hard already. Do we want to make the existing (and mostly-clear) disabled usage harder to understand by changing the way it works?
  • If we change the way it works, could we end up breaking existing applications using it on invalid elements just to style without another class? (While not semantically correct, I have seen this from time-to-time.)
  • Something may be inert but not disabled necessarily. i.e. You have an inert section in a form, the values should still be submitted with the form just like readonly, but disabled items don’t get sent.

hidden repurposing problems

  • Causes display:none; to apply. Which can’t be animated and causes repaint on toggling.
  • Something could be inert but not hidden from display.

We do need this

The web platform should have this provided by browser vendors. Whether it be called inert, inaccessible (personally don’t like purely due to length), or whatever we do need this to make building certain user experience patterns much less of a problem to get accessibility right. Accessibility is hard, and this attribute is a beautifully short and easy way to developers to tackle a very monotonous task if they were do to it on their own (which most won’t.)


#32

By way of whatwg/html#1972 WHATWG’s focus fixup rule one got a bit more explicit and a few browser bugs were filed. It’s worth noting that while focus is returned to <body>, the sequential focus navigation starting point normally seems to remain on the element, so that tab focus navigation isn’t completely screwed. (I’m not aware of a way for the polyfill to imitate that behavior, though)


#33

Note that implementing inert as a concept is a component of implementing <dialog>, so it is strictly less work to implement the inert attribute. Plus, if you did choose to implement <dialog>, you would already be halfway there if you already implemented inert.


#34

+1


#35

Why not look at this from the perspective of other attributes like autocomplete and follow that premise. If the focus is on helping assistive scenarios mute user agent interaction with a node, autocomplete is a possible sample of how that is done. What’s the feature attempting to be disabled? All interaction? Search with the find box? Tab to element? Seems like assistive-interaction. Inert makes me think motionless which has no meaning in this context. The elements might still be animated.


#36

inert elements aren’t sandboxed from the rest of the DOM in any way, though. The only difference would be how they’re handled for interaction (including the way they’re skipped in assistive presentation).

Again, inert sounds like it’s going to cause a lot of confusion with “inert” content as it applies in the context of <template>.


#37

And it’s expected to differ in how content authors will visually style them, which will be required due to the content otherwise not being visually distinguished as part of the recommended UA default style sheet?

That’s another thing I don’t like about this proposal: without the application of specially-crafted external, added stylesheets, it still affects interaction behavior, but does not indicate this in any way (in other words, its natural behavior breaks user expectations, violently). hidden, on the other hand, will degrade gracefully: the content that is treated like it’s hidden (but could be extended into being visually incorporated, in some decorative, style-specific way) will simply be actually hidden.


#38

One way I could see a property like this being useful and semantically different from hidden would be if the attribute doesn’t hide its content from AT, but instead mandates that it should be presented differently, ie. the content is only described without being read as an open prompt.

The use case this would enable, while not really impeding other use cases, would have for this would be for the content of a <figure> exhibiting a static demonstration of normally-interactive content (ie. a specially-crafted form input). The content of the form is still a salient part of the page’s content, but it’s meant to be frozen in place without interactivity (perhaps frozen would be a better name for the attribute?)


#39

Perhaps it should be called “inaccessible” or “noninteractive”.


#40

Correct.

I definitely hear this concern. I don’t think it’s a show-stopper - we live with <a href> and <link> coexisting after all - but others may. However, having given this quite a bit of thought, I haven’t managed to come up with an alternative which is both concise and captures the concept as well as inert - plus, it is the existing term used in the spec.

In contrast with <template>, “inert” here would part of the API surface, so its name matters more. I think if possible we should avoid compromising just to avoid a conceptual name collision.

Not having any styling implications is a feature, not a bug. This means that people won’t need to jump through hoops to undo the default styling to apply the presentation they desire. The use cases in the explainer doc demonstrate that there are a broad range of possible visual presentations which may accompany this attribute, which have nothing in common with one another.