GNOME.org
 

Re: [g-a-devel] HTML5 inert subtrees

Hi, Joanie.

A primary use case I can think of is a dialog. When it appears on the
screen then everything but dialog content turns into inert subtree. So
basically it's grayed-out content but still visible for the user. I
don't have other use cases, probably Steve Faulkner knows something.

So basically the list of options can be reduced to these two items:
1) prune subtree
2) do some combination of ENABLED and SENSITIVE states.

and 2nd option seems like much more flexible option.

Concerning aria-hidden in Firefox, I'd really keep this off the thread
(https://bugzilla.mozilla.org/show_bug.cgi?id=780888 is a right place
for it). But in general I agree with Jamie Teh point
(https://bugzilla.mozilla.org/show_bug.cgi?id=780888#c24) that
aria-hidden should be redesigned.

Thank you.
Alex.


On Fri, Sep 27, 2013 at 1:27 PM, Joanmarie Diggs <jdiggs igalia com> wrote:

Hey Alex, all.

On 09/27/2013 12:03 PM, Alexander Surkov wrote:

Hi.

HTML5 introduces inert subtrees [1] which are supposed to make a
portion of the document inactive (not interactive for the user):

"When a node or one of its ancestors is inert, then the user agent
must act as if the element was absent for the purposes of targeting
user interaction events, may ignore the node for the purposes of text
search user interfaces (commonly known as "find in page"), and may
prevent the user from selecting text in that node."


Before choosing the approach I think we need to be clear on the use case
of an inert subtree. And I'm not 100% clear on that.

If the use case is that it's like a "greyed out" object that can be seen
by sighted users but not interacted with, then:

1. User agents should expose it to ATs
2. User agents should indicate that it cannot be interacted with as
   suggested here:


There is number of approaches discussed at w3c bugzilla [2]:

1. Map it to lack ATK_STATE_SENSITIVE (aria-disabled analogue applied
to any element)


As for this:


I don't have data if this state is recognized by screen readers. In
Firefox it seems ENABLED and SENSITIVE states accompany each other if
the control doesn't have disabled state. So I'm not sure under what
circumstances ENABLED and SENSITIVE states are applied but probably
some combination of them would be a best match for inert subtrees.


At least for real widgets, Orca pays attention to this. My guess is that
for non-widgets it doesn't, but I can take a look and, if need be fix that.


2. Map it to aria-hidden.


That, to me, would be the right way to go IF the use case is: For all
intents and purposes, this subtree is not present: User can't see it and
should not even know it exists.

From the description and bugzilla comments, this does NOT seem to be the
use case. So I wouldn't go this route.

As a related aside:


aria-hidden implementation varies from browser to browser: Chrome
removes it from accessible tree,


Which I think makes a heck of a lot of sense. If for all intents and
purposes it is not there and an AT should not expose it *at all*, why
expose it to an AT? It's at best irrelevant because that AT should not
expose it. You're making more work for the AT because for every object
in the tree, the AT must do an additional check on the off chance that
an object exposed to it should not be exposed to the user. And you are
introducing the potential for bugs because an AT might not be checking
for that attribute.


Firefox exposes "hidden" object attribute.


Any chance I can convince you to abandon that approach and instead to
stop exposing to ATs those things which ATs should not expose to end
users? :)


3. Remove from accessible tree approach (Chrome aria-hidden impl)



4. Expose "hidden" object attribute on root (or every item from
subtree) of inert subtree (Firefox aria-hidden impl)


These options, again, do not seem to be the correct approach *for inert
subtrees* IF an inert subtree is like a "greyed out" object that can be
seen by sighted users but not interacted with.


While it should work in most cases but it's not author error prone
approach and it doesn't 100% go with inert subtree description since
inert subtree may allow text selection (refer to "User agents should
allow the user to override the restrictions on search and text
selection, however.")


In the case of browsers where ATs can rely upon native caret navigation
(e.g. Epiphany/WebKitGtk), if inert subtree text can be selected within
that browser, accessible text selection events should be emitted. That
of course won't work if you remove it from the tree.


5. Invent something new.


Whether or not existing API addresses this well depends on the actual
use case.

Hope this helps!
--joanie
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]