On 08/31/2015 09:16 PM, Alexander Surkov wrote:
> So it's just for performance? If you had convenient and fast way to
> obtain object attributes then you wouldn't need a state?
If I had a convenient and fast way to obtain object attributes, I would
still say the correct mapping is via AtkState.
<desktop example>
Consider the attached screenshot from the Evolution desktop mail client.
The window shown is the wizard you get when you indicate you wish to add
a new mail account. On the left side is a container with the following
items:
* Welcome
* Identity (this item is highlighted/selected)
* Receiving Email
* Sending Email
* Account Summary
* Done
If the above items were each keyboard-focusable, the current item would
be identified via ATK_STATE_FOCUSED. And each time the current item
changed, there would be two object:state-changed:focused events: false
for the object giving up focus; true for the object gaining focus.
If instead the parent container holding the above items were
Tab-focusable and the items themselves selectable, the current item
would be identified via ATK_STATE_SELECTED. And each time the current
item changed, there would be two object:state-changed:selected events:
false for the object no longer selected; true for the object becoming
selected.
Turns out neither is the case for this Evolution wizard. But much like
the focus rectangle on focusable items and the selection indicator on
selectable items, that highlight/selection on Identity says to the user
"you are here." There is only one "here." And the location of "here"
changes in direct response to user action, namely pressing the Next or
Back buttons. Thus there is, I would argue, no *conceptual* difference
between the container in this wizard and containers whose children are
focusable or selectable. As such, I think it makes sense for this to
also be exposed via an AtkState type and for ATs to be notified of
changes by object:state-changed events. Given that the items above are
technically neither focusable nor selectable, I think the appropriate
state in this case is ATK_STATE_ACTIVE and the appropriate notifications
two object:state-changed:active events: false for the object no longer
active; true for the object becoming active.
</desktop example>
With this desktop example in mind.... The new aria-current property, as
I understand it, is designed to expose the same sort of behavior shown
in that Evolution wizard, but for web apps. Given that the behavior and
functionality are the same, I think the exposure on my platform should
be the same. The wrinkle introduced by ARIA is the fact that the value
of aria-current is not merely a boolean: page, step, location, date, and
time are all flavors of true. I'm not convinced (yet) that knowing or
presenting those flavors will be all that valuable. But even if they are
valuable, I still think that what is most important is identifying the
one item in a container which is current and being notified each time
the current item changes.
Object attributes are where you expose things for which ATK has no
proper API through which to expose them. ATK does have proper API
through which to expose the "current" state and changes therein. What
ATK lacks with respect to aria-current is proper API through which to
expose those flavors of true (page, step, location, date, and time).
All of the above is why I *want* a state, and why I would continue to
want a state even if I had a convenient and fast way to obtain object
attributes. The non-performant nature of object attributes does turn
that want into something approaching a need, yes.
But let's for a moment pretend getting object attributes IS performant.
If you only expose the "current" state through an object attribute, what
signal would you emit? I'd have to check with Piñeiro, but I don't
believe you can emit a property-change signal on object attributes let
alone on a specific object attribute ("aria-current:step"). And the only
other signal I see that might be appropriate for the
object-attribute-only approach to aria-current is visible-data-changed.
But that signal requires the AT to play "guess what changed." And last
time I checked, implementors (at least desktop toolkits) spew that event
far too often. Orca already has its hands full with event floods whose
event type is typically useful; adding a listener for known spam events
just in case the aria-current state has changed strikes me as a really
bad idea. (At the moment, AT-SPI2 doesn't let you register for events on
a per-app/toolkit basis. So if Firefox is launched and Orca registers
for visible-data-changed, it's stuck with spam events from all other
apps and toolkits until Firefox is terminated. And since everyone leaves
their browser running in the background....)
So even in a world with lightning-fast, unicorn-riding object
attributes, I fail to see how their use would be preferable to using an
AtkState type and emitting state-change signals.
--joanie
> On Mon, Aug 31, 2015 at 5:22 PM, Joanmarie Diggs <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 08/31/2015 05:12 PM, Alexander Surkov wrote:
> > Hi, Joanie. I guess ATK didn't want to have active state just because an
> > item is focusable or selectable rather than deny a focsuable/selctable
> > items being active, otherwise I don't see a point for this; also it has
> > to be in conflict with aria-current. Anyway regardless what ATK has,
> > what is the point of having both object attribute and state for same
> thing?
>
> If aria-current's value were a boolean, then the state would be
> sufficient -- and much more performant than the object attribute.
> However, aria-current has a value through which an author can indicate
> the context in which the element is current. This, of course, cannot be
> exposed via the state. But checking every last element's object
> attributes on the off chance it has aria-current set on it is not ideal.
> The state indicates it's worth getting the object attributes.
>
> --joanie
>
>
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
