Adding a channel property for addressing the live region politeness problem and the multisynthesizer problem

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

Adding a channel property for addressing the live region politeness problem and the multisynthesizer problem

Charles Chen-2
One solution that will address both the live region priority problem and
the multisynthesizer problem is to simply add a new property called
channel. channel="general" (default) or channel="notify". Messages can
be put into either channel. Within the channel, everything behaves as
before. That is, polites wait until the user idles, assertives will
cancel out polites and be spoken as soon as possible, and rudes will
interrupt and cancel out anything so that they are spoken immediately.
However, messages from one channel cannot cancel or interrupt messages
from another channel. How the messages are actually presented to the
user depends on the AT that the user has running.

If the user is on a screen reader with only one synthesizer and there
are messages in both channels, then:
1. The channel with the highest priority message gets picked for
processing. So if the "general" channel has an assertive and the
"notify" channel only has polites, the "general" channel will be processed.

2. If both channels have the same priority for their highest priority
message, then the "notify" channel will go first. So if both channels
only have polites, then the "notify" channel will be processed first.


If the user is on a screen reader with two or more synthesizers, then:
each channel has its own synthesizer and both channels get processed
simultaneously.


If the user is on a screen reader that also has braille output and has
chosen to use both outputs, then:
one channel will be sent on the audio and the other channel will be sent
on the braille. Which goes where is a user setting (but my guess is that
users will want "notify" on braille and "general" on audio).


This solves the problem for chat since messages directed at the user
since those can be set to channel="notify" and be spoken before the
general chat messages without clearing any of them out. This solution
also lays the foundation for multisynthesizer output and encourages
developers to explicitly  give defaults for what should be on the same
channel. Finally, for users who are on both speech and braille output,
since the users have final say via the AT of how the ARIA live region
properties should behave, they have the flexibility of putting messages
for different regions into different channels. I can imagine a user
wanting to hear the news headlines on the audio channel and having the
braille display show updates to the stock prices.

This solution has already been implemented in a prototype version of
Fire Vox and in Reef Chat. Those who want to try it out can get the
prototype version of Fire Vox by installing the following 3 files:
http://clc4tts.clcworld.net/preview/clc-4-tts_v3.0_release.xpi
http://clc4tts.clcworld.net/preview/clc-utils_v3.9b.xpi
http://clc4tts.clcworld.net/preview/clc_firevox_v5.3b.xpi

and then going to Reef Chat at
http://reefchat.overscore.com

Sina Bahram, Gijs Kruitbosch, and Peter Thiessen have already considered
this idea and like it. Also, Reef Chat running with the Fire Vox
prototype was shown at W4A and at Access U last week, and this behavior
was well received.

Any thoughts?

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

Re: Adding a channel property for addressing the live region politeness problem and the multisynthesizer problem

Charles Chen-2
Also, I should add that since the default is chat="general", web
developers who don't have applications that could benefit from multiple
synthesizers/complex priority systems can just pretend that this
property never existed and do everything as before. So it doesn't
complicate things for the simple cases.

-Charles

> One solution that will address both the live region priority problem and
> the multisynthesizer problem is to simply add a new property called
> channel. channel="general" (default) or channel="notify". Messages can
> be put into either channel. Within the channel, everything behaves as
> before. That is, polites wait until the user idles, assertives will
> cancel out polites and be spoken as soon as possible, and rudes will
> interrupt and cancel out anything so that they are spoken immediately.
> However, messages from one channel cannot cancel or interrupt messages
> from another channel. How the messages are actually presented to the
> user depends on the AT that the user has running.
>
> If the user is on a screen reader with only one synthesizer and there
> are messages in both channels, then:
> 1. The channel with the highest priority message gets picked for
> processing. So if the "general" channel has an assertive and the
> "notify" channel only has polites, the "general" channel will be processed.
>
> 2. If both channels have the same priority for their highest priority
> message, then the "notify" channel will go first. So if both channels
> only have polites, then the "notify" channel will be processed first.
>
>
> If the user is on a screen reader with two or more synthesizers, then:
> each channel has its own synthesizer and both channels get processed
> simultaneously.
>
>
> If the user is on a screen reader that also has braille output and has
> chosen to use both outputs, then:
> one channel will be sent on the audio and the other channel will be sent
> on the braille. Which goes where is a user setting (but my guess is that
> users will want "notify" on braille and "general" on audio).
>
>
> This solves the problem for chat since messages directed at the user
> since those can be set to channel="notify" and be spoken before the
> general chat messages without clearing any of them out. This solution
> also lays the foundation for multisynthesizer output and encourages
> developers to explicitly  give defaults for what should be on the same
> channel. Finally, for users who are on both speech and braille output,
> since the users have final say via the AT of how the ARIA live region
> properties should behave, they have the flexibility of putting messages
> for different regions into different channels. I can imagine a user
> wanting to hear the news headlines on the audio channel and having the
> braille display show updates to the stock prices.
>
> This solution has already been implemented in a prototype version of
> Fire Vox and in Reef Chat. Those who want to try it out can get the
> prototype version of Fire Vox by installing the following 3 files:
> http://clc4tts.clcworld.net/preview/clc-4-tts_v3.0_release.xpi
> http://clc4tts.clcworld.net/preview/clc-utils_v3.9b.xpi
> http://clc4tts.clcworld.net/preview/clc_firevox_v5.3b.xpi
>
> and then going to Reef Chat at
> http://reefchat.overscore.com
>
> Sina Bahram, Gijs Kruitbosch, and Peter Thiessen have already considered
> this idea and like it. Also, Reef Chat running with the Fire Vox
> prototype was shown at W4A and at Access U last week, and this behavior
> was well received.
>
> Any thoughts?
>
> -Charles
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Adding a channel property for addressing the live region politeness problem and the multisynthesizer problem

Tom Brunet
In reply to this post by Charles Chen-2
I read this solution a little differently.  To me, this solution is
jumping from four channels to eight channels.  So, you now have 28
priority combinations instead of 6.  It spreads the issues thinner, but
all of the previously existing issues are still there - and it adds
complexity.

The primary issue that bothers me is that most of the examples given so
far assume a single content author, who orchestrates and coordinates the
channels and priorities.  If I know what all of the messages will be,
it's fairly easy to organize them into pools of what interrupts what,
and so on.

However, the internet is becoming more of a mashup world, where content
is aggregated from a lot of different sources (e.g. google maps).  I
really have no idea how other authors are going to make use of the
different priority levels, and can make no guarantees about whether or
not I will be interupted (unless I'm rude).

So, I'm still of the opinion that a message need more control over their
own fate, rather than allowing messages to decide how they trample on
others.

That said, I'm a big fan of multi-plexing.  I'm kind of curious if
there's a way to think about multi-plexing in terms that components
other than ATs can use?

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

Re: Adding a channel property for addressing the live region politeness problem and the multisynthesizer problem

Charles Chen-2
In reply to this post by Charles Chen-2

Proposal for "channel" property

Property name:
channel

Values:
general | notify

Description:
This property specifies which channel should be used to present the
updates for its associated live region.

The default value is "general".

The mapping of hardware channels (speech synthesizer, braille, etc.) to
the general and notify channels is implementation/configuration dependent.

If multiple hardware channels are available, the AT should allow users
to map the general and notify channels as they wish.

If there is only one hardware channel available, the AT should render
both channels on the same channel. The notify channel is higher priority
than the general channel for live regions of the same politeness; if the
events from the two channels are of differing politeness levels, the
channel with the higher priority event should have higher priority than
the other channel. Note that events from one channel cannot interrupt or
clear out events on another channel.


Example 1:

The user is on an AT which only supports a single hardware channel.

Given:
<div id="liveRegionA" live="polite" channel="general"> </div>
<div id="liveRegionB" live="polite" channel="notify"> </div>

Both live regions get updates that are "polite" simultaneously.
liveRegionB should be spoken first since it is on the notify channel.


Example 2:

The user is on an AT which only supports a single hardware channel.

Given:
<div id="liveRegionA" live="assertive" channel="general"> </div>
<div id="liveRegionB" live="polite" channel="notify"> </div>

Both live regions get updates simultaneously.
liveRegionA should be spoken first since it is on the general channel.

-Charles
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility