Yep, STATE_ACTIVE as you describe it might do a trick. Basically if AT are ok that STATE_INACTIVE window contains STATE_ACTIVE dialog then it should be working. Alex.
On Fri, Sep 27, 2013 at 2:45 PM, Joanmarie Diggs <jdi...@igalia.com> wrote: > On 09/27/2013 01:54 PM, Alexander Surkov wrote: > >> 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. > > In light of the provided primary use case then I agree that the 2nd > option is the way to go. > > Feel free to stop reading. ;) But I cannot help but think aloud on this > one.... > > Related aside: In my perfect world, ATs don't have to worry if the > application is a desktop app or a web app, because to the AT the apps > look and act the same. > > Considering that specific use case, I wonder if there are some clever > hierarchical changes and/or other states and roles that should be > applied to convince ATs the user is in a dialog and/or the inert subtree > is (part of) an inactive window. For instance: > > 1. Expose the dialog (even if it's a dialog by means of ARIA) > * With ATK_ROLE_DIALOG > * With ATK_STATE_MODAL (if that applies) > * With ATK_STATE_ACTIVE when it's active > * Emitting window:activate and appropriate object:state-changed > events > * As a child of either the top level user agent window or the ARIA > application > > 2. Update the previously-active window (real and/or web app): > * Removing ATK_STATE_ACTIVE > * Emitting window:deactivate and appropriate object:state-changed > events > > You can still do the enabled and sensitive state changes, especially > since the use case presented above is surely not the only use case. But > if you can "trick" ATs into thinking there is a real dialog and an > inactive app window, the ATs should hopefully do the right thing > regardless of what you do to the inert subtree. > > Take care. > --joanie _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
