Re: [w3ctag/design-reviews] CSS inert (Issue #1055)

flackr left a comment (w3ctag/design-reviews#1055)

Having only the in view items be in the tab order is the recommended design by the ARIA Authoring Practice Guidelines, https://www.w3.org/WAI/ARIA/apg/patterns/carousel/.

> For instance, the screen reader experience can be confusing and disorienting if slides that are not visible on screen are incorrectly hidden, e.g., displayed off-screen.

The ARIA APG [buttons example](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-1-prev-next/) and [tabs example](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-2-tablist/) do this by having the not yet reached items be `display: none`. The Web accessibility initiative [example](https://www.w3.org/WAI/tutorials/carousels/working-example/) sets `aria-hidden=true` on the offscreen items.

Just as with those accessibility examples, we are encouraging developers creating a slides style experience to make offscreen items inert and use `::scroll-marker` and/or `::scroll-button` pseudo-elements as slide controls to access that content. Making all of the content (or even just the next item) available in the tab order creates an accessibility anti-pattern where a user needs to tab through all of the items before they can get to content or controls which follow it.

> In general, if we are viewing this as a specialized scroll container, if you look at a regular iframe or overflow: auto; visibility: hidden elements, the things that are not in view are not made inert in any way, they just aren't shown. Accessibility tools know how to handle that.

`visibility: hidden` does remove items from the accessibility tree, however toggling this is likely to result in flickering and doesn't support use cases where you want to peek into the next item. If you don't hide the content, it provides a suboptimal experience for these use cases, which is why the accessibility guidelines actually recommend making offscreen content hidden in some way.

> If this work is providing new scrolling affordances in line with ordinary scrollable content, does the [accessibility advice](https://www.w3.org/WAI/tutorials/carousels/working-example/) you refer to still apply?

This property is useful for non-scrolling cases as well. Since it is inherited this enables a long desired goal of being able to author component modal dialogs which are more challenging to create with the `inert` HTML attribute as you cannot undo it within the subtree. E.g.

```html
<style>
#my-component:has(.modal) {
  interactivity: inert;
  & .modal {
    interactivity: auto;
  }
}
</style>
<div id=my-component>
  <button>Controls</button>
  <div class=modal>
    <p>You must choose X before you can continue</p>
    <button>Option 1</button>
    <button>Option 2</button>
  </div>
</div>
```

For generic scrolling experiences where the user does not have specific scroll navigation controls, I would not recommend they inert offscreen content. However, even if they did, many of the assistive tech I've experimented with has mechanisms for scrolling.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1055#issuecomment-2685143603
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1055/2685143603@github.com>