You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix caption track labels pointing at non-existent input ids #372
In the closed captions menu, each caption track's label points at an id that does not exist, so the label is not associated with its radio button. Screen reader users hear the options announced with no name, and clicking a label does not select the track.
The for attribute is missing the -btn suffix that the input's id actually carries. Only the "None" option, whose id is generated differently, is correct:
label[for]
actual input id
associated?
mep_0_captions_none
mep_0_captions_none
yes
mep_0_track_0_subtitles_en
mep_0_track_0_subtitles_en-btn
no
mep_0_track_1_subtitles_fr
mep_0_track_1_subtitles_fr-btn
no
Your environment
Framework 5.56.2, adapt-contrib-media v7.0.6. libraries/mediaelement-and-player.js is byte-identical in v7.1.0, so it affects that release too.
Chrome 150, macOS 15.
Steps to reproduce
Add a media component with a video that has two or more caption tracks, and set toggleCaptionsButtonWhenOnlyOne to false so the language list is used rather than an on/off toggle.
Inspect the caption menu markup, or run this in the console:
Inspect the accessibility tree for the caption options.
Expected behaviour
Each label's for matches the id of the input beside it, so the input takes its accessible name from the label and clicking the label selects that track.
Actual behaviour
Every track label except "None" points at a non-existent id. The accessibility tree exposes the checked radio with no accessible name, with the language name sitting beside it as loose static text.
Suggested fix
addTrackButton in libraries/mediaelement-and-player.js builds the input id and the label's for from different values. The for needs the same -btn suffix as the id.
This is separate from #232 and #297, which are about the menus being invisible while focused. It came to light while testing the fix for those in #371, and that fix does not address it.
Activity