Closed
Bug 374999
Opened 19 years ago
Closed 18 years ago
Basic support for ARIA live regions via EVENT_ALERT
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: aaronlev, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Ultimately, good screen reader support for live regions will require processing of show/hide/children_changed events and checking the ancestor tree for live region markup.
However, there is a lot of nuance with how live region markup must be dealt with. It may take a long, long time before proprietary screen readers support it well. See http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions for some information on what Fire Vox does for live regions (via access to the DOM).
In the meantime, one option is to provide a hint for things that definitely need to be spoken.
I suggest that for rude (and possibly assertive) live regions, an EVENT_ALERT is fired for the appropriate node to be spoken. This event screen readers to read the object with that alert. Generally this is for the smallest change that occurred (the leaf node with the change), but if atomic="true" somewhere in the parent chain then we fire it on that.
In addition, if the current focus or ancestor of the current focus uses the controls relation to point to change item or an ancestor of the changed item, that should automatically be treated as rude, and thus get the event.
| Assignee | ||
Comment 1•19 years ago
|
||
Also, we need to pay attention to the relevant keyword (additions/removals/text) and not fire the EVENT_ALERT in the wrong cases.
My major concern of only firing EVENT_ALERT for rude (and maybe assertive) events is that until JAWS/Windows-Eyes can deal with politeness levels, the only way to get events to speak will be to use rude/assertive. I am worried that this will drive web developers to use rude/assertive for everything they want spoken (even when polite is a much better choice) as a hack for JAWS/Windows-Eyes compatibility. This kind of hacking could be a serious problem in the long run.
I agree that it is good to get some basic support for JAWS/Windows-Eyes working with EVENT_ALERT, but is there any way to also send additional politeness information? For example, once EVENT_ALERT is received, is it possible to use that to find out what fired it and its politeness level? If that is possible, I would say that EVENT_ALERT should be fired for polite, assertive, and rude events - that would enable web developers to use polite the way it should be used.
Thoughts?
| Assignee | ||
Comment 3•19 years ago
|
||
They wouldn't have to use rude/assertive. They could use controls as well.
Or maybe we need a mini-extension that lets users choose a verbosity level -- but I'm not sure how users would know about it.
The problem is not that we can't tell the AT what the politeness level -- it's that it will require coding for them to change it. It's unclear how much of that we can get in 2007.
| Assignee | ||
Comment 4•18 years ago
|
||
I agree with what CLC said in comment 2, as far as why not to do this.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•