WAI ARIA Live Regions report
Charles Chen
http://accessibleajax.clcworld.net/report.html
-Charles
Charles Chen
http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions
Aaron Leventhal
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
David Bolter
conf call?
D
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
David Bolter
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
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:
Aaron Leventhal
> 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
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.
Gez
On Feb 16, 4:37 pm, Aaron Leventhal <aaronlevent...@moonset.net>
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
Aaron Leventhal
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
Charles Chen
> 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
Charles Chen
> 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.
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...
Gez
On Feb 19, 5:19 am, Charles Chen <clc4...@HotPOP.com> 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
David Poehlman
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!
Hi Gez,
Excellent feedback.
- Aaron
_______________________________________________
Peter
> 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
Aaron Leventhal
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
Aaron Leventhal
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
> in-depth to find not only the optimal use of that markup, but also
Aaron Leventhal
- 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
> 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: jon...@uiuc.edu
>
> WWW: http://cita.rehab.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
>
Gez
On Feb 19, 6:40 pm, Aaron Leventhal <aaronlevent...@moonset.net>
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
David Poehlman
Gez,
- Aaron
David Poehlman
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?
David Bolter
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
Steve Lee
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
--
Steve Lee
www.fullmeasure.co.uk
www.oatsoft.org
www.schoolforge.org.uk
T.V Raman
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.
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
--
Best Regards,
--raman
Title: Research Scientist
Email: ra...@google.com
WWW: http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk: ra...@google.com, tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Rich Caloggero
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
Charles Chen
> 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.
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
Victor Tsaran
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
Aaron Leventhal
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
Tom Brunet
> 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.
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