WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question on descriptive control labels

for

From: Kian Badie
Date: Apr 14, 2022 4:13PM

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_delivery/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/Multimedia
> )
> >> 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
> >> > >>
> >> > >> > >> > >> > >>
> > > > > > > > > >
> > > > >