Spun off bug 489549. Once that lands, this one should be addressed. Currently, NVDA will not take notice of the change in captions from "Play" to "Stop" and "Mute" to "Unmute" once these buttons have their proper accessible names and are pressed. An OBJECT_NAMECHANGE event is needed to notify NVDA of these changes.

I'll fix this once we land bug 489549.

Comment on attachment 376874 [details] [diff] [review] patch r=me. Tried this with NVDA and it works great! NVDA immediately picks up the name changes from "Play" to "Pause", and "Mute" to "Unmute", and vice versa.

Comment on attachment 376874 [details] [diff] [review] patch r=me

Comment on attachment 376874 [details] [diff] [review] patch I don't think the videocontrols should be dispatching events -- see discussion in bug 472090, where we already took pains to suppress other events.

(In reply to comment #5) > (From update of attachment 376874 [details] [diff] [review]) > I don't think the videocontrols should be dispatching events -- see discussion > in bug 472090, where we already took pains to suppress other events. Then how do you suppose assistive technologies get notified of changes in labels when I press the "Play" button? The label should change to "Pause", and you only get that if you fire an OBJECT_NAMECHANGE event on the accessible object that represents this button. The only alternative I see to this is for the a11y APIs to implement special classes for these buttons that override the accessible name, and therefore tap into the media element's API to find out whether a media file is currently playing, muted or whatever. And that's C++ code, which would make localization really ugly I think.

(In reply to comment #5) > (From update of attachment 376874 [details] [diff] [review]) > I don't think the videocontrols should be dispatching events -- see discussion > in bug 472090, where we already took pains to suppress other events. Is this because of performance concerns? Perhaps we could only dispatch the event if accessibility is instantiated? (Gecko accessibility is lazily instantiated).

No, AIUI the main concerns were about content being able to see these events coming from the <video> element, which would be a defacto extension of the spec. Eg, <video onfoo="...">. There's additionally the concern about exposing native anonymous content nodes to page script (eg, via event.target).

Nit, content will never see native anonymous content via event.target, only via .originalTarget. And nowadays content page will get a security error if it tries to access native anon content. But yeah, we shouldn't expose any new non-standard events to content, if just possible. It *might* be ok to dispatch NameChange iff a11y is activated, IMO. A11y could add capturing listener to chrome event handler and call stopPropagation when handling the event. One thing I'm actually not sure about is whether the NameChange event created in xbl binding is trusted. Depends on what the new SystemOnlyWrapper does.

Alex, can you work up a patch that only dispatches the event if a11y is instantiated, and in our listener, swallow the event (stop propagation)?

Approach taken from discussion with NVDA developers. Let's fire name change event whenever aria-label/aria-labelledby are changed (like title/alt attributes) and work with screen readers on cases when they 100% need name change event (sure in different bug ;) ).

(In reply to comment #11) > Approach taken from discussion with NVDA developers. Let's fire name change > event whenever aria-label/aria-labelledby are changed (like title/alt > attributes) for you information: title/alt logic has been introduced in bug 417363 where we faced with similar problem

Comment on attachment 377083 [details] [diff] [review] patch2 Nice one, thanks! r=me

Yeah, this seems like a better solution to me.

Comment on attachment 377083 [details] [diff] [review] patch2 yep. r=me

Comment on attachment 377083 [details] [diff] [review] patch2 a191=beltzner

checked in on 1.9.1 - http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c869ef44ba83

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090517 Minefield/3.6a1pre (.NET CLR 3.5.30729)