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

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 17 Oct 2014 08:24:38 -0500
To: Alexander Surkov <surkov.alexander@gmail.com>
Cc: Jason Kiss <jason@accessibleculture.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, PFWG <w3c-wai-pf@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Message-ID: <OFBAEC57DD.1624A2AC-ON86257D74.00497167-86257D74.0049AAB2@us.ibm.com>

ARIA does not just apply to HTML. It also applies to SVG and MANY elements
formerly limited to HTML are now showing up in SVG. While I agree with you
to a point Alex we need to think beyond just the HTML host language.

Are you proposing that every host language duplicate all HTML features? ...
just asking. I am copying the public pfwg list.

Rich


Rich Schwerdtfeger



From:	Alexander Surkov <surkov.alexander@gmail.com>
To:	Jason Kiss <jason@accessibleculture.org>
Cc:	HTML Accessibility Task Force <public-html-a11y@w3.org>, PFWG
            <w3c-wai-pf@w3.org>
Date:	10/16/2014 08:04 AM
Subject:	Re: @inert and @aria-inert for disambiguating modal states



Hi, Jason.

In general ARIA shouldn't duplicate every single HTML piece otherwise we
get into the word where HTML serves presentational needs while ARIA servers
for semantics. In this particular case it means I prefer to have HTML5
@inert attribute over @aria-inert. You referred to [1] which claims that
@inert was removed because it's not supposed to be used in no context of
HTML5 dialog element. I don't have any contrary instance so that rationale
looks reasonable with me. Getting back to ARIA, it provides role="dialog"
however it doesn't have a way to specify the dialog modality. @aria-inert
could be used for that but that doesn't look like a nice approach, it also
makes ARIA markup farther from HTML. I think I would prefer if
role="dialog" carried some extra attribute for modality stuff.

In short I'm up to @inert attribute if it has use case. I don't think I see
a good reason why ARIA would need @aria-inert.

Thanks.
Alexander.

[1] https://html5.org/r/8536

On Tue, Sep 30, 2014 at 9: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


graycol.gif
(image/gif attachment: graycol.gif)

Received on Friday, 17 October 2014 13:25:11 UTC

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