Re: @inert and @aria-inert for disambiguating modal states

I don’t think @aria-inert can exist. It’s not just about the API mapping.

In order for @aria-inert to be useful, it would have to do what @inert was intended to do: prevent events from firing, prevent focus, etc. That’s outside the scope of what ARIA was intended to do, and adding it would break the reliability of the Web.

Instead of adding @aria-inert, the HTML Accessibility TF should push for @inert to be added back in to HTML.



> On Sep 30, 2014, at 6:08 PM, Jason Kiss <jason@accessibleculture.org> wrote:
> 
> The PFWG is seeking feedback from the HTML Accessibility Task Force on
> the appropriate accessibility API mapping for an @aria-inert attribute
> for inert subtrees, and to reconsider the potential of the HTML
> "inert" attribute.
> 
> The PFWG recently discussed a possible ARIA property, "aria-inert", to
> help disambiguate modal states, for example to programmatically
> establish that the underlying content "behind" a modal dialog is inert
> and cannot be interacted with, even if it is visible [1].
> 
> The group was considering how such an attribute would map to
> accessibility APIs, and it was noted that HTML used to include an
> "inert" attribute, but it was removed [2]. It's noted that there
> remains a section on "inert subtrees" in both the HTML5 PR [3] and the
> HTML5.1 nightly [4].
> 
> The general consensus in the group is that HTML's @inert was somewhere
> in between @aria-disabled and @aria-hidden. Mapping to @aria-disabled
> is not appropriate because @aria-disabled applies to the current
> element and focusable descendant elements only, not all descendant
> elements. Mapping to @aria-hidden, which, depending on the browser
> implementation, effectively removes the content from the accessibility
> tree, supports a semi-modal behavior of dialogs and menus, but is not
> quite correct because the underlying content "behind" the dialog or
> menu is actually rendered and visible, and this may have implications
> for some assistive technology like screen magnifiers.
> 
> Other use cases for @inert or @aria-inert include carousels where you
> interact with one pane at a time but you can still see these other
> panes even though they're not active. Even if those inactive panes
> were marked up using @aria-hidden, there would still need to be a way
> to handle the focusability. Pop-up menus present another use case
> where sometimes the background might be inert, depending on the
> platform.
> 
> Without @inert, and were @aria-inert to exist, it could have
> backwards-compatibility so that elements with both aria-hidden="true"
> and aria-inert="true" would be exposed as "inert, but not actually
> hidden." An author could use both to ensure the modal state worked in
> browsers that supported @aria-inert, and older browsers that only
> supported @aria-hidden.
> 
> Members of the PFWG will chime in if I've misrepresented any aspect of
> their discussion on this question.
> 
> Jason
> 
> [1] http://www.w3.org/2014/06/23-aria-minutes.html#item01
> [2] https://html5.org/r/8536
> [3] http://www.w3.org/TR/html5/editing.html#inert-subtrees
> [4] http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees
>

Received on Thursday, 16 October 2014 15:06:26 UTC