WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question on descriptive control labels

for

From: Kian Badie
Date: Apr 8, 2022 3:43PM


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
> > > at http://webaim.org/discussion/archives
> > > > at http://webaim.org/discussion/archives
> >
> > > > >