1727294 - Video element exposes unnamed graphic and button

Status: VERIFIED FIXED

(Toolkit :: Video/Audio Controls, defect, P3)

Description

[scottaohara]

Attachment: VoiceOver focused on unnamed image and button screenshots.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Firefox's implementation of the video element exposes an unnamed graphic (used to render the poster image, regardless if one is specified or not) and an unnamed button (initial CTA play button rendered atop the video).

CodePen of various video elements
https://codepen.io/scottohara/full/bGWRMBj

Using Firefox with VoiceOver on macOS, navigate using the VO cursor (VO key + right arrow) through the video elements in the test page provided.

Or, if on a PC, use a screen reader of your choice and navigate the test page. NOTE: based on your screen reader's settings, the unnamed image may be ignored by the screen reader.

Actual results:

When navigating through the video elements, VoiceOver will encounter the unnamed image in each video element instance.

Navigating to each initial large "Play" button that is rendered atop the video instance will be announced without an accessible name (VoiceOver), or will be announced as "unlabeled zero button" (with JAWS 2021).

Expected results:

Since there is presently no way to specify alternative text for a poster graphic, this graphic should be hidden from the accessibility tree.

Regarding the unnamed button, provide it an accessible name of "Play", as has been done with the Play button that is part of the video players control toolbar.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Changing severity to S3 because while this is a sub-par screenreader experience, the lack of labelling doesn't actually block any critical functionality.

Comment 3

[secret.okra-0z]

Hello! I'd like to tackle this issue. I'm currently setting up my firefox build now.

Comment 4

[secret.okra-0z]

Is this bug open? I am interested

Comment 5

[Micah [:mtigley] (she/her)]

(In reply to secret.okra-0z from comment #4)

Is this bug open? I am interested

Yes this one is available. I'll assign it to you :)

Comment 6

[secret.okra-0z]

Thank you!! I'll be working on getting familiar with the build environment and bugs over the weekend :)

Comment 7

[Micah [:mtigley] (she/her)]

(In reply to secret.okra-0z from comment #6)

Thank you!! I'll be working on getting familiar with the build environment and bugs over the weekend :)

Hi Sadie! Are you still able to work on this?

Comment 8

[Micah [:mtigley] (she/her)]

Unassigning this issue in case someone wants to pick this up.

Comment 9

[kum9748ar]

Hi there this is Kumar Kalyan I am new to this community; can anyone help me out by letting me know about how can I get started with this bug ?
(Reach me out ) https://linktr.ee/kumarkalyan

Comment 10

[Noel Lefevre]

Attachment: Bug 1727294 - Ensure that clickToPlay has an aria-label attribute. r=niklas,mtigley

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/72b54494d9a3
Ensure that clickToPlay has an aria-label attribute. r=mtigley DONTBUILD

Comment 12

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/72b54494d9a3

Comment 13

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on Firefox 91(20210804193234) on macOS Big Sur 11. This issue is fixed on the Firefox 98.0b4(20220213185901) and latest Nightly 99.0a1(20220213214259) on the same OS.