WAI ARIA Live Regions report

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

Re: WAI ARIA Live Regions report

David hilbert Poehlman
Hi Aaron, I think what you say here is what I'm getting at.

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

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


_______________________________________________
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 Charles Chen-2
Hi Charles,

Charles Chen wrote:

>
>> 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?
When I wrote this I was thinking the former, that the AT decides what to
filter, but not to the exclusion of user preference where that makes sense.

If it became an event communication performance/useability issue, and
the ajax application specified threshold idea solved it well than there
might be a strong case for it but I suppose a danger here is that we
(AT) are at the mercy of the good or bad judgement of the web2 app
developer.

If the events exposed to the AT developer were a subset of the events
exposed to the non-AT user that would raise a red flag for me.

> 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.
Here's an example of GOK filtering events: when GOK gets an
"object:state-changed:defunct" event it only puts it on the internal
event queue if the event came from the currently active window (because
GOK has decided not to react to any other defunct event).  But it is
nice as an AT designer/developer to have the choice to handle other
defunct events.

Make sense?

D

>
>
>> 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

_______________________________________________
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

Steve Lee-3
In reply to this post by Aaron Leventhal-3
Or worse you hit return just as it poppes up and grabbed the focus.
You're left wondering what on earth you just did. I'm finding this
with things that popup from the system tray on Windows. Some have a
mouse only UI, presumably to get around this, but that causes other
usability problems.

Steve

On 2/19/07, Aaron Leventhal <[hidden email]> 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
>


--
Steve Lee
www.fullmeasure.co.uk
www.oatsoft.org
www.schoolforge.org.uk
_______________________________________________
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

T.V Raman
In reply to this post by Aaron Leventhal-3
So question: Is it perhaps worth exposing relevant CSS
pseudo-classes for the live region attirubtes?

If we implemented such a pseudo-class then you'd be able to
control live region behavior through CSS which would  bring with
it all the benefits of cascading.

Aaron Leventhal writes:
 > 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

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  [hidden email], [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

_______________________________________________
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

mozilla accessibility
In reply to this post by Charles Chen-2
Live Region Report

Charles et al, this is excellent work.  My comments are below.

* Causality
In some sense, it doesn't really matter who or what caused the region to
change, as long as the updates are announced promptly and in order of
receipt.  However, maybe modifying some of the politeness rules could help
here?
Imagine that a user tabs away from a form field that has an error in it, and
at the same time a message comes in. First of all, these will be two
separate regions (most likely), so setting a rude politeness level on the
form fields would allow it to speak as soon as it can.  I assume that this
rudeness would not throw away events caused by other live regions, so after
the rude event gets spoken, then the polite chat message would then be
spoken.
If these two actions were to happen on the same region, then perhaps
allowing politeness to be modified with another keyword which specifies
whether or not to discard events of lower politeness could be added. If the
form field is changed and gives an error, then that rude event could be
announced and be set so that polite events are not discarded, which would
then allow the polite chat message to be spoken.

* access technology vs. author controlled
I think these are in a sense one and the same.  The access technology could
allow the user to specify settings, and could even make these persistent
based on the page URL and region identifier.  Setting/changing settings in
the screen reader might simply modify the DOM and make the appropriate
changes in the live region markup. So, the markup provides a way for both
the author and the user agent (in this case the access technology) to
control what gets spoken and  when.

* Frequency
I think waitmin is an excellent addition. I also think that the access
technology could "learn" an optimal setting for this based on defaults and
user input/configuration.

* Batching -- busy =  boolean
Another excellent idea. This may only be useful if specified by the author,
since its state would need to be changed based on the current state of the
page and what the author expects to happen based on that state.

* interim
Another great idea. This should be settable by the access technology as
well.

* Higher level abstractions -- role=...
I agree. This could be very useful.  Anything that can save time/effort for
the developer is crucial.  It also provides a tried and tested set of
defaults such that similar pages should behave similarly, which is very
important for screen reader users.  Sometimes, consistency is the most
important thing you can provide to a screen reader user, even if the
information provided isn't optimal.

* Browser support -- addition of DOM events
I wonder if some of this could be taken care of in the toolkits? For
instance, if using dojo, might it be possible to create a new event which
gets fired when a node changes, and then the access technology could listen
for that?  Similarly, for style changes, the toolkit could fire some other
event that the access technology can hear that somehow reflects the style
change.  Not clear how this would happen, so just throwing out vague ideas
here.


Again, great work to all involved!
-- Rich Caloggero, WGBH NCAM

_______________________________________________
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 Charles Chen-2
Rich Caloggero wrote:

> Live Region Report
>
> Charles et al, this is excellent work.  My comments are below.
>
> * Causality
> In some sense, it doesn't really matter who or what caused the region to
> change, as long as the updates are announced promptly and in order of
> receipt.  However, maybe modifying some of the politeness rules could help
> here?
> Imagine that a user tabs away from a form field that has an error in it, and
> at the same time a message comes in. First of all, these will be two
> separate regions (most likely), so setting a rude politeness level on the
> form fields would allow it to speak as soon as it can.  I assume that this
> rudeness would not throw away events caused by other live regions, so after
> the rude event gets spoken, then the polite chat message would then be
> spoken.
> If these two actions were to happen on the same region, then perhaps
> allowing politeness to be modified with another keyword which specifies
> whether or not to discard events of lower politeness could be added. If the
> form field is changed and gives an error, then that rude event could be
> announced and be set so that polite events are not discarded, which would
> then allow the polite chat message to be spoken.
Well, the problem is that ruder announcements will cause politer ones to
be discarded. That's a large part of why causality matters; if it is a
confirmation to a user action, then feedback should be immediate (rude)
but without causing other events to be discarded.

Aaron and I had discussed the possibility of a "purge" flag to tell a
polite event to clear out earlier polite events, but that was dropped
after introducing the idea of interim. If interim is not specified as
relevant, then interim changes will be dropped. It seems like your idea
for adding another keyword to specify whether or not an announcement
should cause more polite announcements to be discarded is similar to
this earlier purge idea, and it might be worth reconsidering from this
angle.



> * access technology vs. author controlled
> I think these are in a sense one and the same.  The access technology could
> allow the user to specify settings, and could even make these persistent
> based on the page URL and region identifier.  Setting/changing settings in
> the screen reader might simply modify the DOM and make the appropriate
> changes in the live region markup. So, the markup provides a way for both
> the author and the user agent (in this case the access technology) to
> control what gets spoken and  when.
I'm not sure why the screen reader would want to go in and change the
DOM. The only advantage that I can see there might be to store a setting
in there, but then that means the DOM for each page must be touched.

Also, touching the DOM is something that I avoid in Fire Vox as much as
possible since that could cause problems with and/or be interfered with
by the JavaScript on the page itself. For example, if the JavaScript on
the page decided to remove a cell in a table and then put in a new cell
with different data (rather than just change the data in the existing
cell), and I had stored some information in the properties of the cell,
then that information will be lost since it is a new cell.


> * Browser support -- addition of DOM events
> I wonder if some of this could be taken care of in the toolkits? For
> instance, if using dojo, might it be possible to create a new event which
> gets fired when a node changes, and then the access technology could listen
> for that?  Similarly, for style changes, the toolkit could fire some other
> event that the access technology can hear that somehow reflects the style
> change.  Not clear how this would happen, so just throwing out vague ideas
> here.
>
I think that these will need to be standardized and come directly from
the browser.

-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

Victor Tsaran
In reply to this post by Charles Chen-2
Hello Charles,
Thank you very much for putting this report together.
I only have several suggestions to bring forward:
1. I think "introduction" section should be a bit expanded to explain
the concept of live regions and why developers should care about it.
2. It would be great to specify which versions of Firefox support live
regions and which don't.
3. Do we have any data as to how well mainstream AT works with live
regions? From y own tests, only JAWS reacts to some extent to live
regions, but this is not because it understands the mark-up, rather it
simply reacts to some system events.
Aaron, which are they?

Thanks,
Victor

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

Aaron Leventhal-3
Hi Victor,

I've updated the Intro section quite a bit. Please
take a look.

Part of the problem is that the report's original
intended audience was the W3C group working to
standardize live region markup. That's how new all
of this is. There were no test cases and no proof
of concept.

Fire Vox support will work with any version of
Firefox. In fact the reason we're starting with
Fire Vox, is that it gets everything from the DOM,
which hasn't changed since Firefox 1.0. Other
screen readers users will need to wait until
Firefox 3 support comes out *and* their particular
screen reader picks up the available object
attributes and events. Firefox 3 will be the first
version of Firefox to expose information such as
the politeness level -- in fact it uses
IAccessible2 object attributes to do so, and
support for that API will be completely new in
Firefox 3.

As the issues get dealt with they'll be removed
from the list, and the report will evolved into a
combination how-to for both authors and assistive
technology vendors.

- Aaron


Victor Tsaran wrote:

> Hello Charles,
> Thank you very much for putting this report together.
> I only have several suggestions to bring forward:
> 1. I think "introduction" section should be a bit expanded to explain
> the concept of live regions and why developers should care about it.
> 2. It would be great to specify which versions of Firefox support live
> regions and which don't.
> 3. Do we have any data as to how well mainstream AT works with live
> regions? From y own tests, only JAWS reacts to some extent to live
> regions, but this is not because it understands the mark-up, rather it
> simply reacts to some system events.
> Aaron, which are they?
>
> Thanks,
> Victor
>
> 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

Tom Brunet
In reply to this post by Charles Chen-2
 > I'm not sure why the screen reader would want to go in and change
 > the DOM. The only advantage that I can see there might be to store
 > a setting in there, but then that means the DOM for each page must
 > be touched.
HPR did a couple of DOM manipulations for various reasons.  As long as
you properly consider how the web page might be affected by those
changes and how the web page might override those changes, it can
provide benefits.

Anyway, I finally got around to reading all of this - it's been on my
todo list for over a month now.  I had two comments, but some of this
was slightly touched here.

#1) What happens to the user reading-point during an event notification?

Does it remain where it was, or does it go to the region being read?  If
it stays where it was, how does someone use their various reading keys
if they misunderstood what they heard?  If it jumps to the region, how
do they get back to where they were?  I assume this is mostly left to
the ATs to decide, but it might be worth thinking about a little.

#2) I'm bothered by the discarding behavior.

This scares me a bit because I have a feeling that it will force web
authors to make more rude events than are necessary.  Let's say that I
have a webpage that has some sort of event notification that acts as an
alarm (Google Calendar).  I would probably make that rude.  Now, if I
have anything else on the page that I want to be sure the user hears, I
also have to make those rude or I risk the chance that an ill-timed
alarm would not present that information.  So, now because I have one
alarm on the page, I have to interrupt the user whenever I have
something remotely important to convey to them, even though the alarm
might be rare.

I can think of three ways to handle it:
2a) The smallest change that might accomplish this is to keep the
behavior for polite events, but change assertive behavior.  Don't
discard assertive events, and insert rude events like a priority queue.
  Then, let page authors worry about ordering problems.  Rude events
should be rare, so this might not be a large burden.

2b) Auto-promote any assertive event to rude if a rude event comes in.
It maintains the ordering, and ensures that important information is read.

2c) I think this might need an ARIA change, but add some parameter to
assertive events to indicate if they are discardable.  By default, they
would be discardable.  Then, non-discardable events are auto-promoted to
rude if a rude event comes in.

Hope you're all having fun in Cali,
Tom

Charles Chen wrote:

> Rich Caloggero wrote:
>> Live Region Report
>>
>> Charles et al, this is excellent work.  My comments are below.
>>
>> * Causality
>> In some sense, it doesn't really matter who or what caused the region
>> to change, as long as the updates are announced promptly and in order
>> of receipt.  However, maybe modifying some of the politeness rules
>> could help here?
>> Imagine that a user tabs away from a form field that has an error in
>> it, and at the same time a message comes in. First of all, these will
>> be two separate regions (most likely), so setting a rude politeness
>> level on the form fields would allow it to speak as soon as it can.  I
>> assume that this rudeness would not throw away events caused by other
>> live regions, so after the rude event gets spoken, then the polite
>> chat message would then be spoken.
>> If these two actions were to happen on the same region, then perhaps
>> allowing politeness to be modified with another keyword which
>> specifies whether or not to discard events of lower politeness could
>> be added. If the form field is changed and gives an error, then that
>> rude event could be announced and be set so that polite events are not
>> discarded, which would then allow the polite chat message to be spoken.
> Well, the problem is that ruder announcements will cause politer ones to
> be discarded. That's a large part of why causality matters; if it is a
> confirmation to a user action, then feedback should be immediate (rude)
> but without causing other events to be discarded.
>
> Aaron and I had discussed the possibility of a "purge" flag to tell a
> polite event to clear out earlier polite events, but that was dropped
> after introducing the idea of interim. If interim is not specified as
> relevant, then interim changes will be dropped. It seems like your idea
> for adding another keyword to specify whether or not an announcement
> should cause more polite announcements to be discarded is similar to
> this earlier purge idea, and it might be worth reconsidering from this
> angle.
>
>
>
>> * access technology vs. author controlled
>> I think these are in a sense one and the same.  The access technology
>> could allow the user to specify settings, and could even make these
>> persistent based on the page URL and region identifier.  
>> Setting/changing settings in the screen reader might simply modify the
>> DOM and make the appropriate changes in the live region markup. So,
>> the markup provides a way for both the author and the user agent (in
>> this case the access technology) to control what gets spoken and  when.
> I'm not sure why the screen reader would want to go in and change the
> DOM. The only advantage that I can see there might be to store a setting
> in there, but then that means the DOM for each page must be touched.
>
> Also, touching the DOM is something that I avoid in Fire Vox as much as
> possible since that could cause problems with and/or be interfered with
> by the JavaScript on the page itself. For example, if the JavaScript on
> the page decided to remove a cell in a table and then put in a new cell
> with different data (rather than just change the data in the existing
> cell), and I had stored some information in the properties of the cell,
> then that information will be lost since it is a new cell.
>
>
>> * Browser support -- addition of DOM events
>> I wonder if some of this could be taken care of in the toolkits? For
>> instance, if using dojo, might it be possible to create a new event
>> which gets fired when a node changes, and then the access technology
>> could listen for that?  Similarly, for style changes, the toolkit
>> could fire some other event that the access technology can hear that
>> somehow reflects the style change.  Not clear how this would happen,
>> so just throwing out vague ideas here.
>>
> I think that these will need to be standardized and come directly from
> the browser.
>
> -Charles
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
12