Bug 28081 - <video> and <audio> controller should be accessible
: <video> and <audio> controller should be accessible
Status: RESOLVED FIXED
: WebKit
Accessibility
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-08-07 13:14 PST by
Modified: 2009-08-25 16:29 PST (History)


Attachments
proposed patch (83.81 KB, patch)
2009-08-07 15:14 PST, Eric Carlson
eric: review-
Review Patch | Details | Formatted Diff | Diff
revised patch (122.97 KB, patch)
2009-08-21 09:03 PST, Eric Carlson
oliver: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-08-07 13:14:22 PST
Built-in <audio> and <video> controls do not work well with accessibility: controls are not in a logic tab order, all buttons names are reported as "button", the timeline slider values are reported as percentages, etc.
------- Comment #1 From 2009-08-07 15:14:00 PST -------
Created an attachment (id=34335) [details]
proposed patch
------- Comment #2 From 2009-08-10 14:28:38 PST -------
<rdar://7065736 >
------- Comment #3 From 2009-08-12 09:25:36 PST -------
http://trac.webkit.org/changeset/47110
------- Comment #4 From 2009-08-12 11:12:47 PST -------
This patch seem to have broken the Qt build:

failed
123 test cases (2%) had incorrect layout
3031 test cases (58%) crashed
------- Comment #5 From 2009-08-12 16:01:37 PST -------
(From update of attachment 34335 [details])
Was rolled out in:
http://trac.webkit.org/changeset/47140

failing tests were skipped in:
http://trac.webkit.org/changeset/47128
------- Comment #6 From 2009-08-21 09:03:35 PST -------
Created an attachment (id=38374) [details]
revised patch

This is a minor rework of the patch reviewed last week. New this time are updated layout test results for Leopard and Windows, and some gtk localized strings I missed last time.
------- Comment #7 From 2009-08-24 11:18:38 PST -------
(From update of attachment 38374 [details])

> +String AccessibilityMediaTimeline::valueDescription() const
> +{
> +    float time = static_cast<HTMLInputElement*>(m_renderer->node())->value().toFloat();
What is the guarantee that our renderer is an input element?


>  MediaControlMuteButtonElement::MediaControlMuteButtonElement(Document* document, HTMLMediaElement* element)
> -    : MediaControlInputElement(document, MEDIA_CONTROLS_MUTE_BUTTON, "button", element, element->muted() ? MediaUnMuteButton : MediaMuteButton)
> +    :: MediaControlInputElement(document, MEDIA_CONTROLS_MUTE_BUTTON, "button", element)
>  {
>  }
This change looks bogus (:: vs :)

r+ assuming you fix the bogosity and explain why the above cast is safe
------- Comment #8 From 2009-08-25 15:41:19 PST -------
> > +String AccessibilityMediaTimeline::valueDescription() const
> > +{
> > +    float time = static_cast<HTMLInputElement*>(m_renderer->node())->value().toFloat();
> 
> What is the guarantee that our renderer is an input element?

  AccessibilityMediaTimeline is only created if the node is an input element, but I will add an ASSERT() in any case.


> >  MediaControlMuteButtonElement::MediaControlMuteButtonElement(Document* document, HTMLMediaElement* element)
> > -    : MediaControlInputElement(document, MEDIA_CONTROLS_MUTE_BUTTON, "button", element, element->muted() ? MediaUnMuteButton : MediaMuteButton)
> > +    :: MediaControlInputElement(document, MEDIA_CONTROLS_MUTE_BUTTON, "button", element)
> >  {
> >  }
>
> This change looks bogus (:: vs :)

Indeed!
------- Comment #9 From 2009-08-25 16:29:19 PST -------
http://trac.webkit.org/changeset/47763