Proposal for WAI-ARIA live=politeness level

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for WAI-ARIA live=politeness level

Charles Chen-2
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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

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

Charles Chen wrote:

> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Aaron Leventhal-3
In reply to this post by Charles Chen-2
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


Charles Chen wrote:

> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Aaron Leventhal-3
In reply to this post by Tom Brunet
Hah, we had the same idea at the same time :)

- Aaron

Tom Brunet wrote:

> 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
>
> Charles Chen wrote:
>> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
 > 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


Aaron Leventhal wrote:

> 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
>
>
> Charles Chen wrote:
>> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Gijs Kruitbosch ("Hannibal")
In reply to this post by Aaron Leventhal-3
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. :(

Aaron Leventhal wrote:

> Hah, we had the same idea at the same time :)
>
> - Aaron
>
> Tom Brunet wrote:
>> 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
>>
>> Charles Chen wrote:
>>> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Charles Chen-2
In reply to this post by Aaron Leventhal-3
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

>  > 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
>
>
> Aaron Leventhal wrote:
>
>> 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
>>
>>
>> Charles Chen wrote:
>>
>>> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: Proposal for WAI-ARIA live=politeness level

Sina Bahram
In reply to this post by Aaron Leventhal-3
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Leventhal
Sent: Monday, April 30, 2007 11:25 AM
To: [hidden email]
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


Charles Chen wrote:

> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: Proposal for WAI-ARIA live=politeness level

Sina Bahram
In reply to this post by Tom Brunet
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Tom Brunet
Sent: Monday, April 30, 2007 11:22 AM
To: [hidden email]
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

Charles Chen wrote:

> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: Proposal for WAI-ARIA live=politeness level

Sina Bahram
In reply to this post by Aaron Leventhal-3
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Leventhal
Sent: Monday, April 30, 2007 12:05 PM
To: [hidden email]
Cc: Charles Chen; Sina Bahram; Gijs Kruitbosch
Subject: Re: Proposal for WAI-ARIA live=politeness level

 > 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


Aaron Leventhal wrote:
> 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
>
>
> Charles Chen wrote:
>> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for WAI-ARIA live=politeness level

Tom Brunet
In reply to this post by Gijs Kruitbosch ("Hannibal")
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

> 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.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility