Re: ARIA Test Cases 86 and 87 are invalid

On Fri, Sep 20, 2013 at 11:22 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> Hi Alex,
>
> Thanks!  The table is beginning to make more sense.
>
>
>>   A note: STATECHANGE event should be fired on unfocused
>> (unselected) item and newly focused (selected) item both.
>
>
> Actually, the table goes on to say:  " ... arrange events so state change
> does not occur on focused item, to avoid extra selection change
> announcements".  That clause appears only under the MSAA and ATK/AT-SPI
> columns.   UIA says the opposite --  focus change "... should be fired but
> individual selection event may not happen to avoid redundancy".

Imo selection events in MSAA is a big mess, Firefox eventing is
duplicating. ATK is cleaner: they expect one "selection_changed" on
the container and state change events for each item changed its
selected state.

>> Also not
>> sure whether the spec should define an event order.
>
>
> Good point.  A common feature of event handling is that the order the events
> arrive is typically undefined, and one cannot write one's handlers in a way
> that depends on event order.  But, I don't know if ATs work that way when
> listening for AAPI events.

Usually events order doesn't make a difference but sometimes it does
since AT relies on it. In this case I don't think order makes a
difference but I would say it makes sense to fire state change events
on items and then selection events since selection events are sort of
collective events (for example, single selection event is couple of
deselection and selection events).

> Thanks again.
>
>
> --
> ;;;;joseph.
>
>
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>              - J. D. Klaun -
>

Received on Friday, 20 September 2013 15:35:35 UTC