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
