W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2014

@inert and @aria-inert for disambiguating modal states

From: Jason Kiss <jason@accessibleculture.org>
Date: Wed, 1 Oct 2014 14:08:36 +1300
Message-ID: <CACFCJLRX6abpDcMwjpPwE70Dv8SGMe=_Po7ud1h54LvvAM+DXw@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Cc: PFWG <w3c-wai-pf@w3.org>
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 Wednesday, 1 October 2014 01:09:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:44 UTC