- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 5 Nov 2014 18:03:13 -0600
- To: Dominic Mazzoni <dmazzoni@google.com>
- Cc: Jason Kiss <jason@accessibleculture.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>, PFWG <w3c-wai-pf@w3.org>
- Message-ID: <OF00369BF8.E202E4B0-ON86257D87.00838BD4-86257D88.00004B84@us.ibm.com>
Dominic,
The problem is that when authors create dialogs with a custom dialog
implementation they steel all the keys and the descendant DOM elements
outside the dialog box become inert (the author decides who receives events
and not the browser). In this case the browser does not know enough about
the application to indicate to an assistive technology that these elements
are inert.
We agree that the handling of @inert is best handled by the browser but in
this case it is not able to. By providing aria-inert the author is
conveying this information to ATs.
I personally would prefer to not include aria-inert as I think this is too
much work for the author but I feel I need to play devil's advocate and
defend the use case for the person who entered this request. I have yet to
see a real issue with @inert and ATs.
We both agree that aria-inert should not change browser functionality - at
all ... any more than I think they author should be fully responsible for
the focused state. These things should be managed by the user agent.
Cheers,
Rich
Rich Schwerdtfeger
From: Dominic Mazzoni <dmazzoni@google.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Jason Kiss <jason@accessibleculture.org>, HTML Accessibility
Task Force <public-html-a11y@w3.org>, "W3C WAI Protocols &
Formats" <public-pfwg@w3.org>, Alexander Surkov
<surkov.alexander@gmail.com>, PFWG <w3c-wai-pf@w3.org>
Date: 11/05/2014 02:24 PM
Subject: 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
Inactive hide details for Dominic Mazzoni ---10/17/2014 10:42:40 AM---I
think that misses the broader point, which I think JameDominic 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
> 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 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
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
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 6 November 2014 00:03:46 UTC