E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Kian Badie
Date: Wed, Apr 06 2022 11:45AM
Subject: Question on descriptive control labels
No previous message | Next message →

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

From: Priti Rohra
Date: Thu, Apr 07 2022 4:17AM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

Hello,

Yes "Play" is the label we screen reader users listen while accessing
audio or video files online. The advantage of using the HTML <audio>
and <video> tags is that Jaws tells us "Audio starts" or "Video
starts".
This gives us an indication if we will be playing an audio or video.
Defining a region with a suitable label also helps to understand what
we are about to deal with.

Would be great if more context can be added to the control labels
especially when a page includes multiple audio/video's. May be giving
authors an option to add more context to the control label using the
text available near by is a good option to consider.

Always BPositive!
Priti Rohra


On 4/6/22, Kian Badie < = EMAIL ADDRESS REMOVED = > wrote:
> 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
> > > > >

From: Mark Magennis
Date: Thu, Apr 07 2022 6:47AM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Kian Badie
Sent: 06 April 2022 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS 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

From: jeffgutsell@fuse.net
Date: Thu, Apr 07 2022 9:06AM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, April 7, 2022 8:47 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Kian Badie
Sent: 06 April 2022 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS 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

From: Mark Magennis
Date: Thu, Apr 07 2022 9:49AM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

Jeff,

In normal language you would think of a figure as a static illustration and I'm always reluctant to use an element in a way that doesn't reflect its intended semantics, but I guess <figure> probably does fit as it's intended for "self-contained content related to the main content". A video embedded on a page sounds like that. So if it does what you need with AT, then fine. Test with more than just JAWS though. I would suggest testing in JAWS/Chrome, NVDA/Firefox, MacOS/Safari/VoiceOver, iOS/Safari/VoiceOver, and Android/Talkback. I know it's a lot of testing but something that works in most of those combinations can still fail badly in one or more of them. And like I said, think of all the ways users might approach your content. In particular, navigating by headings is a very common approach.

Mark

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: 07 April 2022 16:07
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Question on descriptive control labels

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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, April 7, 2022 8:47 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Kian Badie
Sent: 06 April 2022 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS 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

From: Kian Badie
Date: Fri, Apr 08 2022 3:43PM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, April 7, 2022 8:47 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Kian Badie
> Sent: 06 April 2022 18:45
> To: WebAIM Discussion List < = EMAIL ADDRESS 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
> >
> > > > >

From: Mark Magennis
Date: Mon, Apr 11 2022 12:53AM
Subject: Re: Question on descriptive control labels
← Previous message | Next message →

Regarding the naming the player, yes I mean using aria-label. Something that a screen reader can announce when you enter the player. In terms of how descriptive the name should be, that's just your judgement. Consider how much the user will already know about what this player does. If it matters what section it's in and the user might not have that information already, then consider adding it.

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

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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, April 7, 2022 8:47 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Kian Badie
> Sent: 06 April 2022 18:45
> To: WebAIM Discussion List < = EMAIL ADDRESS 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/Multimedi
> a) 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
> >

From: Priti Rohra
Date: Tue, Apr 12 2022 4:33AM
Subject: Re: Question on descriptive control labels
← Previous message | No next message

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> Mark Magennis
>> Sent: Thursday, April 7, 2022 8:47 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> Kian Badie
>> Sent: 06 April 2022 18:45
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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
>> >>
>> >> >> >> >>
> > > > >