WAI ARIA Live Regions report

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

WAI ARIA Live Regions report

Charles Chen-2
I have posted my report on using the WAI ARIA live regions markup at
http://accessibleajax.clcworld.net/report.html

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

Re: WAI ARIA Live Regions report

Charles Chen-2
The report has now been converted to wiki format and is at:
http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions

> I have posted my report on using the WAI ARIA live regions markup at
> http://accessibleajax.clcworld.net/report.html
>
> -Charles
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

Aaron Leventhal-3
In reply to this post by Charles Chen-2
This is great! Thanks Charles!

Everyone please note -- it's already been moved to
the wiki:
http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions

We really crave feedback on this. Thanks.

- Aaron


Charles Chen wrote:
> I have posted my report on using the WAI ARIA live regions markup at
> http://accessibleajax.clcworld.net/report.html
>
> -Charles
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

David Bolter
I hope to find some space to review this.  I wonder if this is worth a
conf call?

D
Aaron Leventhal wrote:

> This is great! Thanks Charles!
>
> Everyone please note -- it's already been moved to the wiki:
> http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions
>
> We really crave feedback on this. Thanks.
>
> - Aaron
>
>
> Charles Chen wrote:
>> I have posted my report on using the WAI ARIA live regions markup at
>> http://accessibleajax.clcworld.net/report.html
>>
>> -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: WAI ARIA Live Regions report

Aaron Leventhal-3
Anyone who's interested in a conference call on live regions, for
Wednesday or Friday next week please email me separately with your
availability.

In the meantime, I'd like to get a lot of the feedback captured, so
please reply to the list.

- Aaron


David Bolter wrote:

> I hope to find some space to review this.  I wonder if this is worth a
> conf call?
>
> D
> Aaron Leventhal wrote:
>> This is great! Thanks Charles!
>>
>> Everyone please note -- it's already been moved to the wiki:
>> http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions
>>
>> We really crave feedback on this. Thanks.
>>
>> - Aaron
>>
>>
>> Charles Chen wrote:
>>> I have posted my report on using the WAI ARIA live regions markup at
>>> http://accessibleajax.clcworld.net/report.html
>>>
>>> -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: WAI ARIA Live Regions report

David Bolter
In reply to this post by Aaron Leventhal-3
Charles, All,

A quick first pass.

First let me say this was really easy to read and quite thorough IMHO.

I wonder about the labelledby and agree that AT might want to offer an
active query by user for the labels.  One thing that wasn't clear to me
is that if atomic=true how are the labels and descriptions treated?
http://accessibleajax.clcworld.net/simple/labelledby.htm

I definitely agree with the causality problem (issue 1) regarding
controls=.  I would add a reason: that we really need *immediate*
(rude?) feedback for user actions if we are to follow years of usability
findings (sorry no reference handy).

I'm worry a little with issue 2.  I think the decision of what events to
ignore might be best left up to the AT?  (We did this with GOK via an
internal event queue).

I'm ok with batching (issue 3).  I think that it can be a necessary
performance requirement.

I'd like to chat about issue 4.  I wonder if it adds too much
complexity.  It is a neat idea.

You have my vote on issue 5.  Supplying defaults would be hugely
important IMHO.  We need to follow KISS as much as possible.

Issue 6 I'm not sure about. It is a bit like batching I suppose but
giving a wrapper-event name to the batch operation?

Issue 7, styling changes are definitely worth broadcasting I agree.

Wow you've thought of some really interesting issues. I think this has
decent coverage. I hope to be able to bring more experience to bear on
these issues in the coming months.  BTW I decided not to edit the wiki.  
Let me know if you'd like me to.

cheers,
David

Aaron Leventhal wrote:

> This is great! Thanks Charles!
>
> Everyone please note -- it's already been moved to the wiki:
> http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions
>
> We really crave feedback on this. Thanks.
>
> - Aaron
>
>
> Charles Chen wrote:
>> I have posted my report on using the WAI ARIA live regions markup at
>> http://accessibleajax.clcworld.net/report.html
>>
>> -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: WAI ARIA Live Regions report

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
> I wonder about the labelledby and agree that AT might want to offer an
> active query by user for the labels.  One thing that wasn't clear to me
> is that if atomic=true how are the labels and descriptions treated?
> http://accessibleajax.clcworld.net/simple/labelledby.htm
The labels and descriptions are part of anything
that gets read. Similarly, associated col/row
headers would be read only with any cell in a
table. This is similar to when the doc contents
are read not because of live updates.

> I definitely agree with the causality problem (issue 1) regarding
> controls=.  I would add a reason: that we really need *immediate*
> (rude?) feedback for user actions if we are to follow years of usability
> findings (sorry no reference handy).
Yes, probably a good idea, as long as hitting the
next key quiets it, just as it does when tabbing
around.

> I'm worry a little with issue 2.  I think the decision of what events to
> ignore might be best left up to the AT?  (We did this with GOK via an
> internal event queue).
Most of the time waitmin isn't used. The default
value is simply 0.
But, for some real world things, only the author
might know the approximate regularity/randomness
with which updates might occur. I think we need to
prove our point with some use cases. In general,
anything where several updates might often happen
a few seconds apart or less, and other times more,
could benefit from this.
I suppose, the AT could watch real world regions
and "learn" about them over time. It could use
that info to try to automatically set this value
for itself, and then we wouldn't need an
author-defined property. Then again, it would take
time for the AT to learn, and the user's first
experience on the page would suffer.

> I'm ok with batching (issue 3).  I think that it can be a necessary
> performance requirement.
Cool, and not just for performance, but for
correctness and avoidance of repetition
(especially for atomic regions with several
changes). The region simply may not be finished.

> I'd like to chat about issue 4.  I wonder if it adds too much
> complexity.  It is a neat idea.
Yes, it's complex but I think it's true that for
some things like stock prices and scores, only the
current value is important, and for other things
such as messages from another person, each
intermediate item is important. The AT can't know
that by guessing.

> You have my vote on issue 5.  Supplying defaults would be hugely
> important IMHO.  We need to follow KISS as much as possible.
I think that alert, status and log might be all we
need. If anyone has other very common live use
case roles, let us know.

> Issue 6 I'm not sure about. It is a bit like batching I suppose but
> giving a wrapper-event name to the batch operation?
I'm not sure about it either, as browser implementor.

> Issue 7, styling changes are definitely worth broadcasting I agree.
Unfortunately we probably would have wait a long
time for a new version of the DOM to do that in a
standards-based way. For MSAA/ATK we use their
events, but DOM based things are out of luck. For
now, Fire Vox may have to listen to accessibility
events from Firefox's nsIObserver mechanism.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

Gez Lemon
In reply to this post by Aaron Leventhal-3
HI all,

On Feb 16, 4:37 pm, Aaron Leventhal <[hidden email]>
wrote:
> We really crave feedback on this. Thanks.

Firstly, I would like to echo that this is a great report; thanks,
Charles.

In the definition of controls [1], it states:

"When a change to one of these regions occurs because of a user action
on the control, then the change should be announced immediately to let
users know that their action did have an effect."

I understood the controls property to mean that if one of the regions
that is controlled by the current UI element had a live property value
that equated to more verbose than "off", then the announcement of an
update would be confirmation that the action was successful; if all of
the regions controlled by the current element were set to off, then
this would be a cue for the current UI element to provide feedback
that some regions had been updated, but not explicitly announce the
updates. This relates to the Casulaity issue [2], in that it doesn't
really matter what caused an updated in a live region - the fact that
it has changed is reason enough to announce the change within the
parameters of the live property.

In the current status section [3], under labelledby, it mentions that
it should be stressed that ARIA properties have precedence over HTML
elements, and goes on to mention that an HTML label element that is
not specified in the labelledby IDREFS value would not be considered a
label for the region. I agree that it should be clear in the ARIA
specification that ARIA properties have precedence over HTML elements,
but I'm not sure that label is a good example. An HTML label provides
context for input, whereas the ARIA labelledby property provides
context for the output (the updated region). Maybe there are cases
where an output region could be a control for input, but I can't think
of one.

I think all of the issues [2] raised by the report make good
discussion points. They mostly suggest that the developer has the
greater control, but AT might provide options to override them. At the
very least, I would expect AT to provide an option to clear any queues
of messages, regardless of waitmin or busy properties.

Slightly off-topic, but something I would like to see emphasised in
the AIA documentation and considered in this report; whilst developers
are likely to understand the importance of updates from their
viewpoint, ultimately, it's the user who should dictate how verbose
updates should be. It would be good to see an example of an
application that includes AJAX live regions, but had a preferences
section whereby the user dictates how verbose updated regions are,
using the developers values as the default.


[1] http://developer.mozilla.org/en/docs/
AJAX:WAI_ARIA_Live_Regions#controls.3D.5BIDLIST.5D
[2] http://developer.mozilla.org/en/docs/
AJAX:WAI_ARIA_Live_Regions#Issues
[3] http://developer.mozilla.org/en/docs/
AJAX:WAI_ARIA_Live_Regions#Current_Status


Best regards,

Gez

--
_____________________________
Supplement your vitamins
http://juicystudio.com

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

Re: WAI ARIA Live Regions report

Aaron Leventhal-3
Hi Gez,

Excellent feedback.

Thanks for bringing up the dichotomy of author and
user control, which are really complimentary.

Many users will not use settings to change the
verbosity of live regions. Therefore, the
developer needs to be given the capability to
provide the most optimal default behavior
possible, while keeping the markup as intuitive
and usable as possible. That said, the developer
does not really have greater control than the
user. The user ultimately has the final say over
what happens, through interaction modes (e.g.
quiet/smart/verbose) and persistent per-region
settings .

For now, the priority is to get final decisions on
the live region markup. One the markup is stable,
we're planning experiment more in-depth to find
not only the optimal use of that markup, but also
define a user interface, along with settings, that
give power to the user without overwhelming them
with options.

- Aaron

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

Re: WAI ARIA Live Regions report

Charles Chen-2
In reply to this post by Aaron Leventhal-3

> I wonder about the labelledby and agree that AT might want to offer an
> active query by user for the labels.  One thing that wasn't clear to me
> is that if atomic=true how are the labels and descriptions treated?
> http://accessibleajax.clcworld.net/simple/labelledby.htm

I don't think atomic=true should have any effect on it. I think it
should be handled the same way that standard labels and descriptions are
handled, i.e. labels should be announced each time and descriptions only
on query.

> I definitely agree with the causality problem (issue 1) regarding
> controls=.  I would add a reason: that we really need *immediate*
> (rude?) feedback for user actions if we are to follow years of usability
> findings (sorry no reference handy).

Yep, agreed.

> I'm worry a little with issue 2.  I think the decision of what events to
> ignore might be best left up to the AT?  (We did this with GOK via an
> internal event queue).

Aaron's comment pretty much sums up my thoughts on this one.

When you say the decision was left to the AT, do you mean that GOK
automatically figures this out? Or is it something that the user
configures?

Because if you are only talking about user configuration, then that will
still work. User configuration will be able to override any of these
defaults set by the web developer.

If you meant that GOK automatically figures it out, would you mind
elaborating on that? Thanks.

> I'd like to chat about issue 4.  I wonder if it adds too much
> complexity.  It is a neat idea.

Well, after this latest latest Fire Vox release, we at least know it's
implementable.


> Issue 6 I'm not sure about. It is a bit like batching I suppose but
> giving a wrapper-event name to the batch operation?

Sort of. But the basic problem is that the DOM mutation events are very
low level and do not give as much information as they could. Fire Vox is
compensating for it by building an internal event queue - however, this
is rather inefficient since Fire Vox is basically piecing together
information that is already to Firefox. It would be much more efficient
(not to mention alot easier) if that information were simply made available.


> Wow you've thought of some really interesting issues. I think this has
> decent coverage. I hope to be able to bring more experience to bear on
> these issues in the coming months.  BTW I decided not to edit the wiki.  
> Let me know if you'd like me to.

In the open source spirit of things, please feel free to make the wiki
entry better. Thanks.

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

Re: WAI ARIA Live Regions report

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

> I understood the controls property to mean that if one of the regions
> that is controlled by the current UI element had a live property value
> that equated to more verbose than "off", then the announcement of an
> update would be confirmation that the action was successful; if all of
> the regions controlled by the current element were set to off, then
> this would be a cue for the current UI element to provide feedback
> that some regions had been updated, but not explicitly announce the
> updates. This relates to the Casulaity issue [2], in that it doesn't
> really matter what caused an updated in a live region - the fact that
> it has changed is reason enough to announce the change within the
> parameters of the live property.
But what if a region is controlled by both the user and by world events?
When the user has done something, then the feedback should be immediate;
but if the world has done something, then that region should be polite.


> In the current status section [3], under labelledby, it mentions that
> it should be stressed that ARIA properties have precedence over HTML
> elements, and goes on to mention that an HTML label element that is
> not specified in the labelledby IDREFS value would not be considered a
> label for the region. I agree that it should be clear in the ARIA
> specification that ARIA properties have precedence over HTML elements,
> but I'm not sure that label is a good example. An HTML label provides
> context for input, whereas the ARIA labelledby property provides
> context for the output (the updated region). Maybe there are cases
> where an output region could be a control for input, but I can't think
> of one.
I was thinking of a form where the meaning (and labels) for the later
blanks might change in response to what the user input earlier. So in
that case, the output region might be a control for another input region.

> Slightly off-topic, but something I would like to see emphasised in
> the AIA documentation and considered in this report; whilst developers
> are likely to understand the importance of updates from their
> viewpoint, ultimately, it's the user who should dictate how verbose
> updates should be. It would be good to see an example of an
> application that includes AJAX live regions, but had a preferences
> section whereby the user dictates how verbose updated regions are,
> using the developers values as the default.

When you say application, do you mean an AJAX application itself? Or AT
support for changing the defaults? Because I think that allowing
overrides over the verbosity would probably be an AT issue...
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

Gez Lemon
Hi Charles,

On Feb 19, 5:19 am, Charles Chen <[hidden email]> wrote:

> > Slightly off-topic, but something I would like to see emphasised in
> > the AIA documentation and considered in this report; whilst developers
> > are likely to understand the importance of updates from their
> > viewpoint, ultimately, it's the user who should dictate how verbose
> > updates should be. It would be good to see an example of an
> > application that includes AJAX live regions, but had a preferences
> > section whereby the user dictates how verbose updated regions are,
> > using the developers values as the default.
>
> When you say application, do you mean an AJAX application itself? Or AT
> support for changing the defaults? Because I think that allowing
> overrides over the verbosity would probably be an AT issue...

I meant the AJAX application itself, which makes it off-topic - sorry.
I think it would be good to see examples where the author's settings
for the live property are used by default, but preference sections are
provided in the application itself that allow users to customise these
values to suit their own preferences.

Best regards,

Gez


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

Re: WAI ARIA Live Regions report

David hilbert Poehlman
In reply to this post by Aaron Leventhal-3
Hi Arron and all,

There is indeed aa huge difference here between the world and the  
author as we have found with aaccess key.  It's been the custtom,  
longstanding practice and judgementt based on a lot of user feedback  
and experrriment in the AT world I think that users need to controll  
as much of the presentation as possible.  Would it be possible to  
pass enough information to AT to allow AT to present the rendering  
options to the user at the outset?  I'm thinking of something like  
what browsers do with security notifications, "viewing this page will  
provide you with constantly updating information, how would you liike  
it handled? announce all, announce infrequently, announce none".  The  
security example simply informs the userr that the page about to be  
viewed will contain both secure and insecure items or that your  
information is abbout to be sent over an insecure channel and allows  
to user to decide whether/if to continue.

Confronted with this, users will make a choice even if it is to  
accept the judgment of the renderer.

Thanks!

On Feb 18, 2007, at 11:48 PM, Aaron Leventhal wrote:

Hi Gez,

Excellent feedback.

Thanks for bringing up the dichotomy of author and user control,  
which are really complimentary.

Many users will not use settings to change the verbosity of live  
regions. Therefore, the developer needs to be given the capability to  
provide the most optimal default behavior possible, while keeping the  
markup as intuitive and usable as possible. That said, the developer  
does not really have greater control than the user. The user  
ultimately has the final say over what happens, through interaction  
modes (e.g. quiet/smart/verbose) and persistent per-region settings .

For now, the priority is to get final decisions on the live region  
markup. One the markup is stable, we're planning experiment more in-
depth to find not only the optimal use of that markup, but also  
define a user interface, along with settings, that give power to the  
user without overwhelming them with options.

- Aaron

_______________________________________________
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: WAI ARIA Live Regions report

Jon Gunderson
In reply to this post by Charles Chen-2
This the live regions verbosity issue seems like a style sheet model, with author providing preferred settings, but the user can override author settings with their own style sheet.

Except in this case the user style sheet is not part of the document, but is currently thought of as the assistive technology (i.e. screen reader)?

Jon


---- Original message ----

>Date: Sun, 18 Feb 2007 23:48:52 -0500
>From: Aaron Leventhal <[hidden email]>  
>Subject: Re: WAI ARIA Live Regions report  
>To: [hidden email]
>
>Hi Gez,
>
>Excellent feedback.
>
>Thanks for bringing up the dichotomy of author and
>user control, which are really complimentary.
>
>Many users will not use settings to change the
>verbosity of live regions. Therefore, the
>developer needs to be given the capability to
>provide the most optimal default behavior
>possible, while keeping the markup as intuitive
>and usable as possible. That said, the developer
>does not really have greater control than the
>user. The user ultimately has the final say over
>what happens, through interaction modes (e.g.
>quiet/smart/verbose) and persistent per-region
>settings .
>
>For now, the priority is to get final decisions on
>the live region markup. One the markup is stable,
>we're planning experiment more in-depth to find
>not only the optimal use of that markup, but also
>define a user interface, along with settings, that
>give power to the user without overwhelming them
>with options.
>
>- Aaron
>
>_______________________________________________
>dev-accessibility mailing list
>[hidden email]
>https://lists.mozilla.org/listinfo/dev-accessibility


Jon Gunderson, Ph.D.
Director of IT Accessibility Services
Campus Information Technologies and Educational Services (CITES)
and
Coordinator of Assistive Communication and Information Technology
Disability Resources and Education Services (DRES)

Voice: (217) 244-5870
Fax: (217) 333-0248
Cell: (217) 714-6313

E-mail: [hidden email]

WWW: http://cita.rehab.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/


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

Re: WAI ARIA Live Regions report

Peter-206
In reply to this post by Charles Chen-2
On Feb 16, 10:26 am, Charles Chen <[hidden email]> wrote:
> I have posted my report on using the WAI ARIA live regions markup athttp://accessibleajax.clcworld.net/report.html
>
> -Charles

Well done Charles! I thought I had posted about this last week but I
guess my post was lost when submitting using google groups - very odd.

But right, I found the report easy to follow and concise. My only note
would be the possibility of adding some code snippets of live regions
in use. Also, maybe even a tutorial. When I was looking around on how
to use live regions I couldn't find any useful examples or tutorials
but maybe now several exist - I did a quick search this morning and
couldn't find any.

Some aspects of Live Regions still confuse me but I think thats just
because I haven't had a chance to try them in a working example.

-peter

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

Re: WAI ARIA Live Regions report

Aaron Leventhal-3
In reply to this post by Gez Lemon
Gez,

The app shouldn't need to have these settings. The
AT will provide the same functionality but on a
scale that will make it applicable to any app. As
long as this markup is used, the AT should be able
to do a great job of providing prefs.

- Aaron

Gez wrote:

> Hi Charles,
>
> On Feb 19, 5:19 am, Charles Chen <[hidden email]> wrote:
>>> Slightly off-topic, but something I would like to see emphasised in
>>> the AIA documentation and considered in this report; whilst developers
>>> are likely to understand the importance of updates from their
>>> viewpoint, ultimately, it's the user who should dictate how verbose
>>> updates should be. It would be good to see an example of an
>>> application that includes AJAX live regions, but had a preferences
>>> section whereby the user dictates how verbose updated regions are,
>>> using the developers values as the default.
>> When you say application, do you mean an AJAX application itself? Or AT
>> support for changing the defaults? Because I think that allowing
>> overrides over the verbosity would probably be an AT issue...
>
> I meant the AJAX application itself, which makes it off-topic - sorry.
> I think it would be good to see examples where the author's settings
> for the live property are used by default, but preference sections are
> provided in the application itself that allow users to customise these
> values to suit their own preferences.
>
> Best regards,
>
> Gez
>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
If usability testing shows that we need something
more up-front like that, then I think that's where
AT's will go. Otherwise they AT will try to stay
out of your way but provide settings or modes.

The problem is this: dialogs that introduce
themselves when users don't expect them, and
require a user response, and a known usability
issue. Users are often just too busy to understand
the question being posed, and will accept or
reject before understanding the consequences.

- Aaron

David Poehlman wrote:

> Hi Arron and all,
>
> There is indeed aa huge difference here between the world and the author
> as we have found with aaccess key.  It's been the custtom, longstanding
> practice and judgementt based on a lot of user feedback and experrriment
> in the AT world I think that users need to controll as much of the
> presentation as possible.  Would it be possible to pass enough
> information to AT to allow AT to present the rendering options to the
> user at the outset?  I'm thinking of something like what browsers do
> with security notifications, "viewing this page will provide you with
> constantly updating information, how would you liike it handled?
> announce all, announce infrequently, announce none".  The security
> example simply informs the userr that the page about to be viewed will
> contain both secure and insecure items or that your information is
> abbout to be sent over an insecure channel and allows to user to decide
> whether/if to continue.
>
> Confronted with this, users will make a choice even if it is to accept
> the judgment of the renderer.
>
> Thanks!
>
> On Feb 18, 2007, at 11:48 PM, Aaron Leventhal wrote:
>
> Hi Gez,
>
> Excellent feedback.
>
> Thanks for bringing up the dichotomy of author and user control, which
> are really complimentary.
>
> Many users will not use settings to change the verbosity of live
> regions. Therefore, the developer needs to be given the capability to
> provide the most optimal default behavior possible, while keeping the
> markup as intuitive and usable as possible. That said, the developer
> does not really have greater control than the user. The user ultimately
> has the final say over what happens, through interaction modes (e.g.
> quiet/smart/verbose) and persistent per-region settings .
>
> For now, the priority is to get final decisions on the live region
> markup. One the markup is stable, we're planning experiment more
> in-depth to find not only the optimal use of that markup, but also
> define a user interface, along with settings, that give power to the
> user without overwhelming them with options.
>
> - Aaron
>
> _______________________________________________
> 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: WAI ARIA Live Regions report

Aaron Leventhal-3
In reply to this post by Charles Chen-2
Which issue is that ... #2?

- Aaron

Jon Gunderson wrote:

> This the live regions verbosity issue seems like a style sheet model, with author providing preferred settings, but the user can override author settings with their own style sheet.
>
> Except in this case the user style sheet is not part of the document, but is currently thought of as the assistive technology (i.e. screen reader)?
>
> Jon
>
>
> ---- Original message ----
>> Date: Sun, 18 Feb 2007 23:48:52 -0500
>> From: Aaron Leventhal <[hidden email]>  
>> Subject: Re: WAI ARIA Live Regions report  
>> To: [hidden email]
>>
>> Hi Gez,
>>
>> Excellent feedback.
>>
>> Thanks for bringing up the dichotomy of author and
>> user control, which are really complimentary.
>>
>> Many users will not use settings to change the
>> verbosity of live regions. Therefore, the
>> developer needs to be given the capability to
>> provide the most optimal default behavior
>> possible, while keeping the markup as intuitive
>> and usable as possible. That said, the developer
>> does not really have greater control than the
>> user. The user ultimately has the final say over
>> what happens, through interaction modes (e.g.
>> quiet/smart/verbose) and persistent per-region
>> settings .
>>
>> For now, the priority is to get final decisions on
>> the live region markup. One the markup is stable,
>> we're planning experiment more in-depth to find
>> not only the optimal use of that markup, but also
>> define a user interface, along with settings, that
>> give power to the user without overwhelming them
>> with options.
>>
>> - Aaron
>>
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>
>
> Jon Gunderson, Ph.D.
> Director of IT Accessibility Services
> Campus Information Technologies and Educational Services (CITES)
> and
> Coordinator of Assistive Communication and Information Technology
> Disability Resources and Education Services (DRES)
>
> Voice: (217) 244-5870
> Fax: (217) 333-0248
> Cell: (217) 714-6313
>
> E-mail: [hidden email]
>
> WWW: http://cita.rehab.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: WAI ARIA Live Regions report

Gez Lemon
In reply to this post by Aaron Leventhal-3
Hi Aaron,

On Feb 19, 6:40 pm, Aaron Leventhal <[hidden email]>
wrote:
> The app shouldn't need to have these settings. The
> AT will provide the same functionality but on a
> scale that will make it applicable to any app. As
> long as this markup is used, the AT should be able
> to do a great job of providing prefs.

I didn't realise that was part of the plan, but am pleased to read
that it has been considered. Allowing the live property values to be
overridden by AT so that users can determine their own level of
verbosity is far better than hoping the author will provide those
settings.

Best regards,

Gez

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

Re: WAI ARIA Live Regions report

David hilbert Poehlman
In reply to this post by Aaron Leventhal-3
Aaron,

I understand what you are saying, and wholeheartedly concur in most  
matters with this.  What we face here though is a choice it seems  
between two rocks andd a hard place.  On one hand, there will be  
defaults that people won't unnderstand that or how they can change.  
On the other, we face a situation where the user is presented with  
something they have to deal with.  In the latter case, if AT does it  
right, it will work toward positive change in the way we interact  
with the web.  I would hesitate to burden authoring with the task of  
figuring out best defaults unless we can automatically class this and  
even then, how do we decide what those defaults should be?

On Feb 19, 2007, at 1:43 PM, Aaron Leventhal wrote:

If usability testing shows that we need something more up-front like  
that, then I think that's where AT's will go. Otherwise they AT will  
try to stay out of your way but provide settings or modes.

The problem is this: dialogs that introduce themselves when users  
don't expect them, and require a user response, and a known usability  
issue. Users are often just too busy to understand the question being  
posed, and will accept or reject before understanding the consequences.

- Aaron

David Poehlman wrote:

> Hi Arron and all,
> There is indeed aa huge difference here between the world and the  
> author as we have found with aaccess key.  It's been the custtom,  
> longstanding practice and judgementt based on a lot of user  
> feedback and experrriment in the AT world I think that users need  
> to controll as much of the presentation as possible.  Would it be  
> possible to pass enough information to AT to allow AT to present  
> the rendering options to the user at the outset?  I'm thinking of  
> something like what browsers do with security notifications,  
> "viewing this page will provide you with constantly updating  
> information, how would you liike it handled? announce all, announce  
> infrequently, announce none".  The security example simply informs  
> the userr that the page about to be viewed will contain both secure  
> and insecure items or that your information is abbout to be sent  
> over an insecure channel and allows to user to decide whether/if to  
> continue.
> Confronted with this, users will make a choice even if it is to  
> accept the judgment of the renderer.
> Thanks!
> On Feb 18, 2007, at 11:48 PM, Aaron Leventhal wrote:
> Hi Gez,
> Excellent feedback.
> Thanks for bringing up the dichotomy of author and user control,  
> which are really complimentary.
> Many users will not use settings to change the verbosity of live  
> regions. Therefore, the developer needs to be given the capability  
> to provide the most optimal default behavior possible, while  
> keeping the markup as intuitive and usable as possible. That said,  
> the developer does not really have greater control than the user.  
> The user ultimately has the final say over what happens, through  
> interaction modes (e.g. quiet/smart/verbose) and persistent per-
> region settings .
> For now, the priority is to get final decisions on the live region  
> markup. One the markup is stable, we're planning experiment more in-
> depth to find not only the optimal use of that markup, but also  
> define a user interface, along with settings, that give power to  
> the user without overwhelming them with options.
> - Aaron
> _______________________________________________
> 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


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