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
