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

On Wed, Nov 5, 2014 at 11:17 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> 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.
>
Yes, but it's not just a state indicator - it changes the behavior of the
browser by changing which elements can receive events.

I have no objections to inert, I think it's great and I'd like to see it
supported. My objection is only to making it part of ARIA and calling it
aria-inert - I don't think it fits because no other ARIA attribute changes
the behavior like that.


>
> 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
>
> [image: Inactive hide details for Dominic Mazzoni ---10/17/2014 10:42:40
> AM---I think that misses the broader point, which I think Jame]Dominic
> Mazzoni ---10/17/2014 10:42:40 AM---I think that misses the broader point,
> which I think James expressed clearly: changing what's focusa
>
> 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* <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*
>    <surkov.alexander@gmail.com>>
>    To: Jason Kiss <*jason@accessibleculture.org*
>    <jason@accessibleculture.org>>
>    Cc: HTML Accessibility Task Force <*public-html-a11y@w3.org*
>    <public-html-a11y@w3.org>>, PFWG <*w3c-wai-pf@w3.org*
>    <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>
>
>
>