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
>
> [image: Inactive hide details for Alexander Surkov ---10/16/2014 08:04:51
> AM---Hi, Jason. In general ARIA shouldn't duplicate every sin]Alexander
> 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* <https://html5.org/r/8536>
>
> On Tue, Sep 30, 2014 at 9:08 PM, Jason Kiss <*jason@accessibleculture.org*
> <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*
>    <http://www.w3.org/2014/06/23-aria-minutes.html#item01>
>    [2] *https://html5.org/r/8536* <https://html5.org/r/8536>
>    [3] *http://www.w3.org/TR/html5/editing.html#inert-subtrees*
>    <http://www.w3.org/TR/html5/editing.html#inert-subtrees>
>    [4]
>    *http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees*
>    <http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees>
>
>
>