491443 - Fire OBJECT_NAMECHANGE events when the HTML 5 media Play/Pause or Mute/Unmute buttons are pressed and the caption changes

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[alexander :surkov (:asurkov)]

I'll fix this once we land bug 489549.

Comment 2

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 3

[Marco Zehe (:MarcoZ)]

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 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 376874 [details] [diff] [review]
patch

r=me

Comment 5

[Justin Dolske [:Dolske]]

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.

Comment 6

[Marco Zehe (:MarcoZ)]

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

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

(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).

Comment 8

[Justin Dolske [:Dolske]]

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

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

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

Comment 11

[alexander :surkov (:asurkov)]

Attachment: patch2

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 ;) ).

Comment 12

[alexander :surkov (:asurkov)]

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

[Marco Zehe (:MarcoZ)]

Comment on attachment 377083 [details] [diff] [review]
patch2

Nice one, thanks! r=me

Comment 14

[Justin Dolske [:Dolske]]

Yeah, this seems like a better solution to me.

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 377083 [details] [diff] [review]
patch2

yep. r=me

Comment 16

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/mozilla-central/rev/fe3e17356dfe

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 377083 [details] [diff] [review]
patch2

a191=beltzner

Comment 18

[alexander :surkov (:asurkov)]

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

Comment 19

[Marco Zehe (:MarcoZ)]

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)