On Fri, Sep 27, 2013 at 01:27:19PM -0400, Joanmarie Diggs wrote: > 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? :)
Its been a while and I'm not really eager to go look again, but last time I looked it seemed there was several different and contradictory use cases for aria-hidden. In some of them hiding stuff from the AT would make sense, but in others it would very much be the wrong thing to do. I'm also not clear why this always requires extra checks, if something is hidden then it should effectively not there then it shouldn't have the onscreen state, and you should probably not present stuff that is offscreen wether or not it is effectively hidden or not. On the other hand if it is onscreen then it clearly isn't also "not there". Trev > > > 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 _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
