WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question on descriptive control labels

for

From: Geethavani.Shamanna
Date: Apr 19, 2022 4:37AM

Hi Kian,

When there are multiple audio players with transcripts on a page, it would be useful to use the Show/Hide Transcript button to display transcripts in each of the audio players. These buttons will be displayed when the concerned audio is in focus.

I have come across pages with multiple audio activities, and the players are often not appropriately labelled. I would be interested in a practical solution to deal with this issue. One solution would of course be to embed each of these players within an iFrame, and then appropriately label the iFrames.

I have also come across instances where the Transcript button is embedded within the media player. On clicking the Transcript button, the screen reader reads out the entire transcript. However, since the screen reader automatically switches to the Application mode when navigating the media player, it is not possible to read through the transcript line by line or sentence by sentence. Purely from an accessibility perspective, is it good practice to disassociate the transcript button from other media player controls and make the transcript available outside the media player?

Many thanks.
Geetha



-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Kian Badie
Sent: 14 April 2022 23:14
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Question on descriptive control labels

CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content.

Hello Pitri,

Thank you very much for your input. It is very helpful! With your advice, I think I will use the aria-labelledby on the player attribute to point to the header that describes the section. This seems like it would provide more of a description since there are multiple audio players on the page.
Or do you think it would be better to label the individual controls with more context? I would guess labeling the parent player would be more concise and sufficient. Do you have any preferences on what is more helpful? I interpreted support for both options in your reply.

Also, if I may add a related question, how should transcripts be determined? The narration is just the spoken audio of text existing on the page. But how would one say "hey, this audio has a transcript over there in this part of the page"? The examples I have seen online just have a section on the page with a "Transcript" heading. However, I don't think I can add that heading to my page. Are there other ways to connect the text to the audio?

Thank you,
Kian Badie

On Tue, Apr 12, 2022 at 3:33 AM Priti Rohra < <EMAIL REMOVED> > wrote:

> Hi Kian,
>
> With regards to giving context I would suggest text describing the
> media. Yes heading if present can be referenced in the accessible
> name for Play/Pause control via aria-labelledby will give us better
> context about what we'll be playing.
> My thoughts about giving label as "Audio player" or "Video player"
> does suffice the requirement of labelling section/regions but is not
> of any help to the user. Such labels are pretty generic in nature
> whereas giving a descriptive text through hidden heading or labelling
> it via aria-label is a better option as it gives more context to
> users and keeps the content in check.
>
> Always BPositive!
> Priti Rohra
>
>
> On 4/9/22, Kian Badie < <EMAIL REMOVED> > wrote:
> > Hello All,
> >
> > Thank you all very much for the very insightful input!
> >
> > Priti, that is interesting that JAWS does that. From my experience,
> tabbing
> > or arrowing into a native audio element with NVDA unfortunately just
> > announces "play". Good to know that defining a region could be helpful!
> For
> > adding context in the text nearby, are you saying to possibly add
> > some
> text
> > visually that would point out the audio player. Like a heading of sorts?
> >
> > Mark, the heading recommendation is interesting. I have not seen
> > visually hidden headers before! If the slight redundancy is worth
> > better overall accessibility, I will consider that! Would you please
> > be able to expand
> on
> > the naming the player strategy. Is this different from adding a
> > label either through aria-label or a visually hidden label?
> >
> > I am also curious what everyone thinks of the labeling the player itself?
> > Would "audio player" be good, or should it be more specific to what
> > it
> is?
> > Like "page section - audio player", where "page section" is the
> > section
> of
> > the page that the audio pertains to?
> >
> > Thank you,
> > Kian Badie
> >
> > On Thu, Apr 7, 2022 at 8:06 AM < <EMAIL REMOVED> > wrote:
> >
> >> Mark,
> >> I am saving your discussion for future reference. I will need it.
> >> Meanwhile, I have been studying a custom player example at the
> >> Mozilla Developers Network.
> >>
> https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_del
> ivery/cross_browser_video_player
> >> The page has an example that uses the figure element as the player
> >> container and figcaption to label it. So far, my experiments
> >> indicate
> that
> >> JAWS announces the player when I navigate by tab or arrow keys.
> >> Just wondering what you think.
> >>
> >> Jeff Gutsell
> >>
> >> -----Original Message-----
> >> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf
> >> Of Mark Magennis
> >> Sent: Thursday, April 7, 2022 8:47 AM
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Subject: Re: [WebAIM] [EXTERNAL] Question on descriptive control
> >> labels
> >>
> >> The button name "Play" is correct. But as you've pointed out, this
> >> only works if the user knows they are on a page or in a part of a
> >> page that contains a media player, in which context "Play" (and any
> >> other player controls you have) is understandable.
> >>
> >> Using a named region is one way of doing this. If you Tab into a
> region, a
> >> screen reader will often announce the region and its name before
> >> announcing the focussed element. But this doesn't always happen and
> >> it may not
> happen
> >> if you arrow into the region or if you enter it by any other means,
> >> such as jumping to a heading or button within it or using a jump
> >> link that moves focus to it. So named regions are unreliable. Your
> >> task is to code the thing in such a way that the user will always
> >> know they are in a media player, no matter how they get into it.
> >> Unfortunately this can be difficult.
> >>
> >> One thing I would definitely recommend would be to add a heading,
> because
> >> headings are one of the most reliable structural indicators ad
> >> screen reader users often navigate within a page using them. You
> >> can combine
> this
> >> with a region so you could have for example <section
> >> aria-label="media
> >> player"><h2 class="sr-only">media
> >> player</h2>...<button>Play</button>...</section>. This means that
> >> you
> have
> >> a region starting with a heading of the same name and in some cases
> >> both will be read which is a unnecessarily verbose but a small
> >> price to pay
> for
> >> making the player understandable. Note that the "sr-only" class is
> >> there if you want to make the heading invisible which is sensible
> >> because it's probably visually unnecessary, though DHS Trusted
> >> Tester will flag this erroneously as an a11y fail).
> >>
> >> Another thing you may be able to name is the video player itself.
> >> This
> may
> >> be some kind of object and it may be embedded within a <div
> >> role="application"> if it implements common media player keyboard
> >> shortcuts such as Space for Play/Pause, arrow keys for volume and
> >> scrubbing. The player object and the application can both be given
> >> names. Obviously,
> the
> >> more things you name the more potential verbosity you may introduce
> >> but not all screen reader read all objects' names in all
> >> circumstances so it's worth playing around with naming all the
> >> different layers of containers (section, application, object,
> >> toolbar container, etc.) and testing it
> in
> >> the range of browser/screen reader combinations you want to support
> >> to
> see
> >> if you can find a best combination that will always ensure that the
> >> user gets something no matter how they enter it and there is never
> >> so much repetition that it gets confusing or totally annoying.
> >>
> >> Mark
> >>
> >> -----Original Message-----
> >> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf
> >> Of Kian Badie
> >> Sent: 06 April 2022 18:45
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Subject: [EXTERNAL] [WebAIM] Question on descriptive control labels
> >>
> >> I am creating a custom audio player, and I am confused on how to
> >> label
> the
> >> buttons. For example, I currently label the play button with just
> >> aria-label="Play" but I can't tell if that is sufficient for a
> non-sighted
> >> user. For me, If I see a play button and a time scrubber scrubber
> grouped
> >> together I can guess it is an audio player. But if a screen reader
> >> just announces "play button", is that enough?
> >>
> >> I am having trouble finding resources online that clarify this.
> >> MDNs "Accessible multimedia" article (
> >> https://developer.mozilla.org/en-US/docs/Learn/Accessibility/Multim
> >> edia
> )
> >> mentions nothing on this. It looks like able player (
> >> https://ableplayer.github.io/ableplayer/) adds a label to the
> >> container element and gives it a region role. It looks like that
> >> gives a more descriptive screen reader announcement. While that is
> >> a clue for me on
> how
> >> to write things, I haven't seen much else online describing this
> >> technique.
> >> Any insight would be much appreciated!
> >>
> >> Thank you,
> >> Kian Badie
> >> > >> > archives
> >> at http://webaim.org/discussion/archives
> >> > >> > >> > archives
> >> at http://webaim.org/discussion/archives
> >> > >>
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >>
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > archives at http://webaim.org/discussion/archives
> >