GNOME Bugzilla – Bug 511885
Support relevant and channel live region properties
Last modified: 2008-07-22 19:33:44 UTC
Orca currently does not support the "relevant" and "channel" live region properties. Implement them. References http://www.w3.org/TR/aria-state/#relevant http://www.w3.org/TR/aria-state/#channel http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support
The relevant property, as it's name implies, allows developers to identify live region changes relevant to the eventual output. The property can take on the following values: additions: Nodes are added to the [DOM] within the region removals: Nodes are removed from the [DOM] text: (default) Text is added or removed from the [DOM] all: Additions, removals, text To fully implement this property we will need to monitor object:children-changed:remove and object:text-changed:delete events. I believe this will impact Orca performance too much to rationalize the implementation of this seldom used property (when relevant="removals"). At the moment, I think the default value for relevant will suffice. To implement the channel property, I simply output the message immediately when channel='notify' (no queuing). For testing purposes, I set a different ACSS (louder output) for 'notify' events. This can easily be removed before committing but I kinda like it. Patch to follow.
Created attachment 103734 [details] [review] first version of Support relevant and channel live region properties See proceeding comment for description of this patch.
(In reply to comment #2) > Created an attachment (id=103734) [edit] > first version of Support relevant and channel live region properties > > See proceeding comment for description of this patch. I'm not sure I understand the W3C spec for the channels: main: (default) The default channel on which to send live region events notify: A channel with higher priority than the Main channel on which to send the live regions events The patch currently just speaks all 'notify' messages, but has no other interaction with any currently speaking or pending messages. Should there be some sort of speech.stop() call or anything like that? In addition, can you give me an idea of the kinds of web pages that might give these kinds of events? Finally, I'll let Mike determine if setting the volume louder is the right thing to do. We might want to consider making a whole new entry in settings.voices to handle the ACSS for these things. That way, it could be more easily overridden and we could eventually provide UI for it in the speech preferences pane.
> I'm not sure I understand the W3C spec for the channels: > > main: (default) The default channel on which to send live region events > notify: A channel with higher priority than the Main channel on > which to send the live regions events I think they purposefully left it a little vague. I have read where the higher priority channel could be Braille output or an entirely new AT (whatever that may be). I believe FireVox takes the same approach I am taking, namely to treat notify message similar to a rude message except don't clear the queue. I do not know if Firevox is using different speech personalities. In the future I can foresee multiple audio output streams with the notify channel simply being one of them (earcons could be other(s)). Right now, a different ACSS for the notify "channel" might add to it's functionality. > The patch currently just speaks all 'notify' messages, but has no other > interaction with any currently speaking or pending messages. Should there be > some sort of speech.stop() call or anything like that? Yes, a speech.stop() would probably be a good idea. I hate losing information (the current utterance and other utterances that slip by due to isSpeaking() inaccuracies) but this is suppose to be a critical type of alert. > In addition, can you give me an idea of the kinds of web pages that might give > these kinds of events? The notify events should be restricted to critical warnings. An example might be a chat session where the server is going down. Many other web apps might have similar needs.
(In reply to comment #4) > > some sort of speech.stop() call or anything like that? > Yes, a speech.stop() would probably be a good idea. I hate losing information > (the current utterance and other utterances that slip by due to isSpeaking() > inaccuracies) but this is suppose to be a critical type of alert. OK - if my understanding is correct, there probably should be a speech.stop() in there. If you agree, I'd say go ahead and add it and also remove the special ACSS for now. But, add a big comment in there that we'll likely see in the future to let us know we'd like an ACSS in there when we work on bug 412656. What do you think?
Created attachment 105241 [details] [review] second version of Support relevant and channel live region properties Sounds good. Requested changes are reflected in the new patch.
I think this looks good. I'm OK with it if it tests well. Thanks!
I tested this the other day and it seems to test OK. It's a little hard to tell for sure without much in the way of real world examples though.
Mike. I hear you on the real world examples. I'll see if I can track one down. I suspect http://reefchat.overscore.com/ has it built in but I need to verify. committed to trunk. marked as fixed.