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 <jdi...@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 _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
