Proposal for WAI-ARIA live=politeness level

[Charles Chen]

Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.

We have come to the conclusion that there needs to be one more level of
politeness to live and also clarification on how the existing politeness
levels behave.

Our proposal is to have the following:

live = Off, Polite, Assertive, Notify, Rude

Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything

Off, Polite, Assertive, and Rude are still as they are currently defined
in WAI-ARIA (and as they behave in Fire Vox).

Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.

Thoughts?

-Charles

[Aaron Leventhal]

My first thought was that it's useful, but that it's not as linear, and makes
the meaning of politeness less intuitive a bit harder to remember. It's not
natural unless we can explain it quickly.

Is any simplification possible? Should we consider splitting into more than one
attribute, for example add a boolean clear attribute? The clear attribute would
default to true for rude, and false for everything else. Just a thought.

Here's my summary of what was proposed, in table form, which makes it easier to
understand but still not totally intuitive for me:

Politeness Interrupts? Clears? Queue position
Off n/a n/a n/a
Polite No interrupt No clear Queue after polite
Assertive No interrupt Clear polite Queue after assertive
Notify No interrupt No clear Queue after notify
Rude Interrupt Clear all First in queue

- Aaron

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level of
politeness to live and also clarification on how the existing politeness
levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently defined
in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Aaron Leventhal]

Post by Aaron Leventhal
Rude Interrupt Clear all First in queue

This should probably say "Queue after rude". If there are multiple rude messages
they should probably all be spoken, right?

That would make it consistent and easier to remember.

- Aaron

Post by Aaron Leventhal
My first thought was that it's useful, but that it's not as linear, and
makes the meaning of politeness less intuitive a bit harder to remember.
It's not natural unless we can explain it quickly.
Is any simplification possible? Should we consider splitting into more
than one attribute, for example add a boolean clear attribute? The clear
attribute would default to true for rude, and false for everything else.
Just a thought.
Here's my summary of what was proposed, in table form, which makes it
Politeness Interrupts? Clears? Queue position
Off n/a n/a n/a
Polite No interrupt No clear Queue after polite
Assertive No interrupt Clear polite Queue after assertive
Notify No interrupt No clear Queue after notify
Rude Interrupt Clear all First in queue
- Aaron

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Charles Chen]

No, rude must be first in queue. If that were the case, rude would not
interrupt all messages. Once the string is passed to the speech engine,
there is no way to really know what is being spoken unless the AT
developers manually track all messages; I can track that on my end, but
I'm concerned about how much acceptance this would gain elsewhere.

Additionally, there is a practical need to have a type of message which
will interrupt anything (even its own type), especially given the
problems with causality. There needs to be something that interrupts
everything else immediately in the case of a menu system (if you cycle
through the options in a menu, even if the last option was not finished
speaking, it will be interrupted when you cycle to the next message).

-Charles

Post by Aaron Leventhal

Post by Aaron Leventhal
Rude Interrupt Clear all First in queue

This should probably say "Queue after rude". If there are multiple rude
messages they should probably all be spoken, right?
That would make it consistent and easier to remember.
- Aaron

Post by Aaron Leventhal
My first thought was that it's useful, but that it's not as linear,
and makes the meaning of politeness less intuitive a bit harder to
remember. It's not natural unless we can explain it quickly.
Is any simplification possible? Should we consider splitting into more
than one attribute, for example add a boolean clear attribute? The
clear attribute would default to true for rude, and false for
everything else. Just a thought.
Here's my summary of what was proposed, in table form, which makes it
Politeness Interrupts? Clears? Queue position
Off n/a n/a n/a
Polite No interrupt No clear Queue after polite
Assertive No interrupt Clear polite Queue after assertive
Notify No interrupt No clear Queue after notify
Rude Interrupt Clear all First in queue
- Aaron

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and
how to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Sina Bahram]

The problem with this approach is that there, again, is information loss.

"your connection pinged out"

"closing chat ..."

Those have got to be queued ... I want to know both of those pieces of
information. I have to know both of those pieces of information.

Take care,
Sina

-----Original Message-----
From: dev-accessibility-***@lists.mozilla.org
[mailto:dev-accessibility-***@lists.mozilla.org] On Behalf Of Aaron
Leventhal
Sent: Monday, April 30, 2007 12:05 PM
To: dev-***@lists.mozilla.org
Cc: Charles Chen; Sina Bahram; Gijs Kruitbosch
Subject: Re: Proposal for WAI-ARIA live=politeness level

Post by Aaron Leventhal
Rude Interrupt Clear all First in queue

This should probably say "Queue after rude". If there are multiple rude
messages they should probably all be spoken, right?

That would make it consistent and easier to remember.

- Aaron

Post by Aaron Leventhal
My first thought was that it's useful, but that it's not as linear,
and makes the meaning of politeness less intuitive a bit harder to

remember.

Post by Aaron Leventhal
It's not natural unless we can explain it quickly.
Is any simplification possible? Should we consider splitting into more
than one attribute, for example add a boolean clear attribute? The
clear attribute would default to true for rude, and false for everything

else.

Post by Aaron Leventhal
Just a thought.
Here's my summary of what was proposed, in table form, which makes it
Politeness Interrupts? Clears? Queue position
Off n/a n/a n/a
Polite No interrupt No clear Queue after polite
Assertive No interrupt Clear polite Queue after assertive
Notify No interrupt No clear Queue after notify
Rude Interrupt Clear all First in queue
- Aaron

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and
how to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind
Assertive Notify = does not interrupt, jumps in front of Polite and
Assertive messages without clearing, queues behind Notify Rude =
interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Sina Bahram]

We would love it if we could do it as two booleans for clears and queues.

But barring that possibility, something like notify has to exist. There is
no option currently when it comes to providing the behavior of notifying the
user of an event down stream, temporally speaking, when the AT is currently
speaking something else. If we clear the rest of the messages, such as rude
does, there is a large amount of semantic information that gets lost. If we
queue up too long, then the message becomes useless.

Again, the following example


Tim: hello
Bob: hi Tim, how's it going?
Tim: alright, but I had one busy weekend ... Needed to finish moving into
the new place
*** Aaron has just signed in ***


I want to be able to hear:

Tim: hello
Bob: hi Tim, how's it going?
*** Aaron has just signed in ***
Tim: alright, but I had one busy weekend ... Needed to finish moving into
the new place

If not even interrupting half of the sentence from Bob to announce this
fact.

Is that more clear?

Take care,
Sina

-----Original Message-----
From: dev-accessibility-***@lists.mozilla.org
[mailto:dev-accessibility-***@lists.mozilla.org] On Behalf Of Aaron
Leventhal
Sent: Monday, April 30, 2007 11:25 AM
To: dev-***@lists.mozilla.org
Cc: Sina Bahram; Gijs Kruitbosch
Subject: Re: Proposal for WAI-ARIA live=politeness level

My first thought was that it's useful, but that it's not as linear, and
makes the meaning of politeness less intuitive a bit harder to remember.
It's not natural unless we can explain it quickly.

Is any simplification possible? Should we consider splitting into more than
one attribute, for example add a boolean clear attribute? The clear
attribute would default to true for rude, and false for everything else.
Just a thought.

Here's my summary of what was proposed, in table form, which makes it easier
to understand but still not totally intuitive for me:

Politeness Interrupts? Clears? Queue position
Off n/a n/a n/a
Polite No interrupt No clear Queue after polite
Assertive No interrupt Clear polite Queue after assertive
Notify No interrupt No clear Queue after notify
Rude Interrupt Clear all First in queue

- Aaron

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify Rude = interrupts
everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Tom Brunet]

I think I mentioned this earlier, but if not - what bothers me with
these schemes is the only messages that can declare themselves as unable
to be cleared are rude messages. As soon as one rude message exists,
all important messages have to be rude.

Just to throw another scheme out to think about - I think you can
accomplish much of this and more by adding a variable that indicates if
a message is clearable. The two variables could be:
livepriority = verylow, low, medium, high, veryhigh
liveclear = true (default), false

Or maybe you want more control over clearing, so liveclear could be a
priority level at which or higher that message would be bumped. This
would default to one level above the livepriority level.

As for ordering/interrupt decisions, I might leave those decisions to
the user/AT. Someone with cognitive disabilities might not want
messages to be re-ordered. Or perhaps the user decides that re-ordering
works for them on one website, but not another.

Most of the reason I throw this one out there is just to present
something of contrast. The current proposal has some complicated
semantics behind the different priority levels. Although the readers of
this forum might take the time to understand the semantics, we have a
hard time convincing web authors to stick to the semantics of HTML
elements. I still see lists coded as tables, and blockquotes used for
indenting, etc.

Just some food for thought,
Tom

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level of
politeness to live and also clarification on how the existing politeness
levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently defined
in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Aaron Leventhal]

Hah, we had the same idea at the same time :)

- Aaron

Post by Tom Brunet
I think I mentioned this earlier, but if not - what bothers me with
these schemes is the only messages that can declare themselves as unable
to be cleared are rude messages. As soon as one rude message exists,
all important messages have to be rude.
Just to throw another scheme out to think about - I think you can
accomplish much of this and more by adding a variable that indicates if
livepriority = verylow, low, medium, high, veryhigh
liveclear = true (default), false
Or maybe you want more control over clearing, so liveclear could be a
priority level at which or higher that message would be bumped. This
would default to one level above the livepriority level.
As for ordering/interrupt decisions, I might leave those decisions to
the user/AT. Someone with cognitive disabilities might not want
messages to be re-ordered. Or perhaps the user decides that re-ordering
works for them on one website, but not another.
Most of the reason I throw this one out there is just to present
something of contrast. The current proposal has some complicated
semantics behind the different priority levels. Although the readers of
this forum might take the time to understand the semantics, we have a
hard time convincing web authors to stick to the semantics of HTML
elements. I still see lists coded as tables, and blockquotes used for
indenting, etc.
Just some food for thought,
Tom

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Gijs Kruitbosch]

Actually, the subtle difference between the two ideas is that Tom
suggested that messages should specify whether they're *clearable*,
while you suggested they should specify which they're clearing (or
whether they're clearing anything). I much favour the latter approach,
given I think it would be confusing to figure out when I'm sending a
message, whether or not I'd want it to be cleared by anything
afterwards, whereas for an error message, it would be a lot clearer that
I'd want it to be more important than anything else.

~ Gijs

PS: as for the naming of all these levels, I've already said in the
conference call I don't think the current naming (even without notify)
makes a lot of sense, but in the end I don't really give a ... what it's
called, as long as I can use it to do what the user wants. Without the
possibility of having something more important than polite that doesn't
wipe the floor with earlier messages, that's hard/impossible, as
discussed extensively on this list. If anyone has a more consistent
proposal for all five things, I'd love to hear about it. I know I don't. :(

Post by Aaron Leventhal
Hah, we had the same idea at the same time :)
- Aaron

Post by Tom Brunet
I think I mentioned this earlier, but if not - what bothers me with
these schemes is the only messages that can declare themselves as
unable to be cleared are rude messages. As soon as one rude message
exists, all important messages have to be rude.
Just to throw another scheme out to think about - I think you can
accomplish much of this and more by adding a variable that indicates
livepriority = verylow, low, medium, high, veryhigh
liveclear = true (default), false
Or maybe you want more control over clearing, so liveclear could be a
priority level at which or higher that message would be bumped. This
would default to one level above the livepriority level.
As for ordering/interrupt decisions, I might leave those decisions to
the user/AT. Someone with cognitive disabilities might not want
messages to be re-ordered. Or perhaps the user decides that
re-ordering works for them on one website, but not another.
Most of the reason I throw this one out there is just to present
something of contrast. The current proposal has some complicated
semantics behind the different priority levels. Although the readers
of this forum might take the time to understand the semantics, we have
a hard time convincing web authors to stick to the semantics of HTML
elements. I still see lists coded as tables, and blockquotes used for
indenting, etc.
Just some food for thought,
Tom

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and
how to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify
Rude = interrupts everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles

[Tom Brunet]

Well, everyone thinks they're more important than everyone else :P I
think it's more an issue of who owns the information loss - me or
someone else.

Here's a scenario to illustrate. Maybe I have a battery indicator that
notifies me every 5% below 20% of my battery life. I want to be polite
and not interrupt the user, but I do want to be sure that they are aware
of this information. Immediately after the battery indication message
is sent, a program crashes, and wants to interrupt the user immediately.
The error dialog only knows how important it is, but has no
information about how important the other messages on the queue are.

If the decision belongs to the error dialog, it has an external
dependency on the battery dialog to also be rude in order to prevent
important information loss. However, if the decision belongs to the
battery indicator, there is no dependency.

Tom

Post by Gijs Kruitbosch
given I think it would be confusing to figure out when I'm sending a
message, whether or not I'd want it to be cleared by anything
afterwards, whereas for an error message, it would be a lot clearer that
I'd want it to be more important than anything else.

[Sina Bahram]

I can't agree more, but it was thought that web authors might not like a
three integer type system like so

(3, 2, 1)

Where 3 maps to something like assertive, 2 means that you should only queue
up behind 2's, and the 1 means that you should clear out all 2's.

In other words:

(priority, queue, clear)

Where all three of those are priority levels.

Furthermore, in discussing this further, we realized that no AT would
implement this because they do not keep track of what they are "currently
speaking" so wouldn't know to queue things up or do anything with them.

I'm writing some technologies currently that will be using a modified model
of this system to offer multichannel and multipositional sound with full
priority, queuing, and clearing support; however, Charles pointed out
correctly on the phone that no AT would invest the kind of time/money it
would take to support such a system.

One last note about the above ... It of course can be extended to have
certain enumerations mapped to it for convenience, so that authors don't
have to write out three integers every time.

Take care,
Sina

-----Original Message-----
From: dev-accessibility-***@lists.mozilla.org
[mailto:dev-accessibility-***@lists.mozilla.org] On Behalf Of Tom Brunet
Sent: Monday, April 30, 2007 11:22 AM
To: dev-***@lists.mozilla.org
Subject: Re: Proposal for WAI-ARIA live=politeness level

I think I mentioned this earlier, but if not - what bothers me with these
schemes is the only messages that can declare themselves as unable to be
cleared are rude messages. As soon as one rude message exists, all
important messages have to be rude.

Just to throw another scheme out to think about - I think you can accomplish
much of this and more by adding a variable that indicates if a message is
clearable. The two variables could be:
livepriority = verylow, low, medium, high, veryhigh liveclear = true
(default), false

Or maybe you want more control over clearing, so liveclear could be a
priority level at which or higher that message would be bumped. This would
default to one level above the livepriority level.

As for ordering/interrupt decisions, I might leave those decisions to the
user/AT. Someone with cognitive disabilities might not want messages to be
re-ordered. Or perhaps the user decides that re-ordering works for them on
one website, but not another.

Most of the reason I throw this one out there is just to present something
of contrast. The current proposal has some complicated semantics behind the
different priority levels. Although the readers of this forum might take
the time to understand the semantics, we have a hard time convincing web
authors to stick to the semantics of HTML elements. I still see lists coded
as tables, and blockquotes used for indenting, etc.

Just some food for thought,
Tom

Post by Charles Chen
Sina, Gijs, and myself have spent the past 2 and a half hours in a
conference call discussing how to deal with the chat scenario and how
to make it generalizable.
We have come to the conclusion that there needs to be one more level
of politeness to live and also clarification on how the existing
politeness levels behave.
live = Off, Polite, Assertive, Notify, Rude
Off = Off
Polite = does not interrupt, does not clear, queues behind Polite
Assertive = does not interrupt, clears Polite, queues behind Assertive
Notify = does not interrupt, jumps in front of Polite and Assertive
messages without clearing, queues behind Notify Rude = interrupts
everything, clears everything
Off, Polite, Assertive, and Rude are still as they are currently
defined in WAI-ARIA (and as they behave in Fire Vox).
Notify is the new level - it serves to address the issue of messages
that should come to the user ASAP, but without clearing out the queue.
Thoughts?
-Charles