Button after video element with no controls is not accessible

[joe-watkins]

Summary

When a button immediately follows a <video> element that has no controls, that button can be reached by JAWS but the accessible name is not announced nor can the control be activated.

(Warning test link has autoplay video with no controls to stop)

1. With JAWS activated, visit this test test using IE11.
2. Attempt to activate the button that follows the <video> element.

Expected result

1. JAWS will announce the button correctly and will be able to activate the button with enter or spacebar.

Actual result

1. JAWS does not announce the button's accessible name nor can it activate the control.

Example

https://s.codepen.io/joe-watkins/debug/geRgMe

Additional Information

When controls are present, by adding the controls attribute on the <video> element the button that follows the control is accessible. I believe this extends to the <audio> element as well.

An example use case for a video with no controls and a button that follows it would be a video background for a hero that has a button to stop animation/video.

JAWS version and build number

18.0.5038

Operating System and version

WIN7

Browser and version:

IE11

[clane]

This issue also occurs with the audio tag. See http://www.chrislane.info/examples/buttonLabelNotAnnouncedDueToAudioTag.html

[stevefaulkner]

Tested with JAWS 2018 and can reproduce

[OwenEdwards]

This significantly impacts frameworks such as Video.js which provide alternative user controls for video playback. See videojs/video.js#4583.

[EDIT] All the effort to make the video player framework as accessible as possible is negated by the fact that the very first button a user must interact with to play the video is not announced with JAWS+IE11!!

[stevefaulkner]

Thanks for the issue report, have filed internally as Bug 101267 - Cannot interact with HTML video element UI. In investigating this issue found some further issues with JAWS/IE video element support.
Using JAWS with Internet Explorer 11, there are various major issues with
interacting with HTMl5 video elements:

1. When the video element does not have the controls attribute set, a
   placed after the
2. When the video element does have the controls attribute when the video
   element receives focus via tabbing, the accessible name announced comes from
   elements surrounding the video element, despite the video element having a
   explicitly set name (via aria-label, for example). Sometimes when tabbing
   through the video UI elements the same accessible name is used for all of the
   controls at other times nothing is announced at other times the full string for
   all video UI is announced for each of the individual controls.

to reproduce: navigate to https://s.codepen.io/stevef/debug/LmdNga
tab through the page:
Note on test 1 the button after the video is not announced
Note on test 2 sometimes nothing is announced or the each control has the same accessible name or the accessible name is from the button after or the heading before.cannot appear to operate video UI controls.

In investigating the original issue I found that the IE/JAWS issue with the button not being announced can be mitigated by placing role="application" on the video element. test case https://s.codepen.io/stevef/debug/LmdNga which may be helpful in the short term.

[stevefaulkner]

@OwenEdwards see my comment about use of role=application which may be a short term fix, until JAWS itself is fixed.

[joe-watkins]

@stevefaulkner Thanks for digging into this and for the update w/temp fix :)

[OwenEdwards]

Thanks @stevefaulkner. I don't suppose you checked what the effect of putting role="application" was with other browsers and/or SR, did you? Otherwise I'm going to need to dig in and see if it can be used broadly or the framework needs to do browser identification, etc.

FYI (and I don't know if this is useful or a red herring) IE is the only browser which leaves active content like a link inside fallback content inside the <video> tag as tabbable (as though it was aria-hidden but not hidden), and I think it's the only browser that leaves the <video> element itself still focusable even without controls (it's been a little while since I had to deal with that issue).

[ohpyupi]

I had the same issue with <audio> tag. And I applied the suggested fix here. And this worked like charm. Thanks.

[OwenEdwards]

@stevefaulkner this issue appears to also affect the latest version of Chrome (Version 72.0.3626.109 (Official Build) (64-bit)) and JAWS (2019.1901.66); see @joe-watkins' examples at:

Without <video> element native controls: (JAWS+Chrome has trouble with button)
https://s.codepen.io/joe-watkins/debug/b343f69dddba68cc6f5427e1e869e72e

With <video> element native controls: (JAWS+Chrome appears to access button)
https://s.codepen.io/joe-watkins/debug/d2fb16335b121511a9eb1e60e779cea0

I think this is a new problem, because we hadn't run into it when we initially reported #78 as affecting IE. I don't know if it is due to a change in Chrome, in JAWS, or in both.

Joe was also able to confirm that the previous workaround seems to work (adding role="application" on the <video> element), but it's alarming if this bug is getting worse or more widespread!

[hadleyel]

I have tested the linked examples with JAWS 2020.2008.24, Chrome 85.0.4183.121, and IE 11.508.19041.0, and the buttons seem to announce and operate properly now. Is this true for anyone else?

[JAWS-test]

With JAWS 2020, the problem no longer occurs in Chrome and IE 11, but continues to occur with older versions of JAWS (for example, JAWS 2019 and IE 11 or JAWS 18 and Chrome)

[stevefaulkner]

as the issue is no longer present in 2020, am closing this issue.

[OwenEdwards]

@stevefaulkner are you (and @JAWS-test) confirming that this issue has been fixed in JAWS? Just wondering how this process works, since I see you had previously labeled this issue as "JAWS-bug-filed" - are you able to confirm back from that (internal) bug that this was fixed in a specific version of JAWS, or will it always be a matter of people noticing that the bug is no longer reproducible?

[JAWS-test]

@OwenEdwards: Unfortunately I cannot answer the question about the internal process because I have nothing to do with Freedom Scientific. I only publish JAWS bugs that I find in my work and comment on JAWS bugs that other people have posted

[OwenEdwards]

@JAWS-test ahh, my mistake. Then this is just a question for @stevefaulkner.