Re: [g-a-devel] HTML5 inert subtrees

[Alexander Surkov <surkov alexander gmail com>]

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 <jdiggs 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