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

Dominic, @inert is an indicator of state - like aria states and properties.
It does not have to do the actual function. I would prefer it be managed by
the browser but there was a request for this feature.

That said, we have nothing by way of @inert in SVG.

Personally, I am not in favor of aria supporting an inert attribute but
what it would do is say that these parts of the document do not process
input. To my knowledge, if someone were to create a modal dialog that
person would need to steel the keys and mouse input so that they are not
directed to areas outside the dialog box. In that scenario the browser does
NOT manage the inert state and the information is not conveyed to assistive
technologies.

Incidentally, I would prefer that authors use an HTML5 dialog element.

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Alexander Surkov <surkov.alexander@gmail.com>, 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>
Date:	10/17/2014 10:42 AM
Subject:	Re: @inert and @aria-inert for disambiguating modal states



I think that misses the broader point, which I think James expressed
clearly: changing what's focusable and what events fire is beyond the scope
of ARIA.

On Fri, Oct 17, 2014 at 6:24 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  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

  Inactive hide details for Alexander Surkov ---10/16/2014 08:04:51
  AM---Hi, Jason. In general ARIA shouldn't duplicate every sinAlexander
  Surkov ---10/16/2014 08:04:51 AM---Hi, Jason. In general ARIA shouldn't
  duplicate every single HTML piece otherwise we

  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