WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Media player/recorder accessibility

for

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

From: Isabel Holdsworth
Date: Thu, Nov 15 2018 1:11AM
Subject: Media player/recorder accessibility
No previous message | Next message →

Hi all,

I'm creating an all-purpose media player and audio capture component,
and I have a few quick questions:

Is it a good idea to use a single button for Play/Pause, or are
separate buttons preferable so long as the focus is managed? Is it
easier for users with cognitive issues or learning disabilities if
both buttons are always visible?

What's the best way to implement a volume control? I'm guessing a
vertical slider with ten stop points, but is there a better way?

If the user is playing and recording at the same time, would a tabbed
interface be the best way to provide access to the player and
recorder, or would it be better to present them in separate sections
with H1 or H2 headers? This approach could be clumsy for sighted
keyboard users, who would still have to tab their way through a bunch
of controls to get to the one they need.

Thanks as always, Isabel

From: glen walker
Date: Thu, Nov 15 2018 1:28AM
Subject: Re: Media player/recorder accessibility
← Previous message | Next message →

If you have two buttons for play/pause, you get into some weird situations
such as after selecting play, does it become disabled because the audio is
already playing? And if so, do you leave the focus on the play button even
if it's disabled? If you move the focus to the pause button, that might
violate 3.2.2 because a "change of context" is defined as moving the focus
unexpectedly (see
https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html#context-changedef
).

I think it's a pretty common UI to have one button that toggles. The image
on the button usually switches between a right-facing triangle (play) and
two vertical bars (pause). The aria-label of the button would have to
change *and* you'd need an aria-live region to announce "play" or "pause"
since the changing of the aria-label is not announced.

For volume, yes I would do a slider. The number of stop points is up to
you. Youtube has 20 increments.

When you say the user is playing and recording at the same time, do you
literally mean they pressed the record button and the play button at the
same time? Or do you mean that the user has two tasks to perform,
recording and playing, but they won't be doing both at exactly the same
time? If you go back to the 80's and tape decks, there was a play button
and a record button on the same panel. You couldn't do both at the same
time. Not sure if that analogy fits your case - having one play/pause
button and having a separate record button. The user can record something,
press stop (which might be different from pause - you can pause a
recording, get a drink, then continue recording, or press stop if you're
completely done, but maybe that's a relic of the 80's tape deck), then
press play to hear the recording.

Glen

From: Swift, Daniel P.
Date: Thu, Nov 15 2018 6:25AM
Subject: Re: Media player/recorder accessibility
← Previous message | Next message →

Isabel:

Regarding the playing/recording, it sounds like you are trying to do a multitrack recording. It's been a number of years since I used ProTools, but the transport UI for that was hit record which would then flash repeatedly (slow pulse) until you hit the play button. At this point, you were playing back audio that was already captured while recording a new track. To me (and growing up with pressing play and record buttons simultaneously) this makes sense.

Are you envisioning a substantial number of different controls between the player and the recorder?

Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of glen walker
Sent: Thursday, November 15, 2018 3:28 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Media player/recorder accessibility

If you have two buttons for play/pause, you get into some weird situations such as after selecting play, does it become disabled because the audio is already playing? And if so, do you leave the focus on the play button even if it's disabled? If you move the focus to the pause button, that might violate 3.2.2 because a "change of context" is defined as moving the focus unexpectedly (see https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html#context-changedef
).

I think it's a pretty common UI to have one button that toggles. The image on the button usually switches between a right-facing triangle (play) and two vertical bars (pause). The aria-label of the button would have to change *and* you'd need an aria-live region to announce "play" or "pause"
since the changing of the aria-label is not announced.

For volume, yes I would do a slider. The number of stop points is up to you. Youtube has 20 increments.

When you say the user is playing and recording at the same time, do you literally mean they pressed the record button and the play button at the same time? Or do you mean that the user has two tasks to perform, recording and playing, but they won't be doing both at exactly the same time? If you go back to the 80's and tape decks, there was a play button and a record button on the same panel. You couldn't do both at the same time. Not sure if that analogy fits your case - having one play/pause button and having a separate record button. The user can record something, press stop (which might be different from pause - you can pause a recording, get a drink, then continue recording, or press stop if you're completely done, but maybe that's a relic of the 80's tape deck), then press play to hear the recording.

Glen

From: JP Jamous
Date: Thu, Nov 15 2018 6:39AM
Subject: Re: Media player/recorder accessibility
← Previous message | Next message →

Isabel,

I prefer that the Play button toggles between Play and Pause. That way, it
does announce to the user what action is to take based on what the player is
doing.

Having a stop button might be optional. In the case of Youtube, I just pause
a video and that is the same to me as stop. Less buttons to navigate through
and performs 2 different tasks. It pauses the playing, which allows me to
continue from where I left off, or it pauses the playing to allow me to read
the page or close it.

I have to agree with Glen on the progress bar and specifically the record
button. Why would you want to play if you are recording?

Also, having both present will be based on what your app specifications are.
If the app supposed to play a video by obtaining a URL from the user and you
want to capture the audio to save it, then yes you can use the record
button. However, this would have to run on the client and have access to the
sound card or extract the audio from the downloaded track.

I think if you give us more info on what the purpose is for the record
button, we can give you a better answer.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Isabel Holdsworth
Sent: Thursday, November 15, 2018 2:12 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Media player/recorder accessibility

Hi all,

I'm creating an all-purpose media player and audio capture component, and I
have a few quick questions:

Is it a good idea to use a single button for Play/Pause, or are separate
buttons preferable so long as the focus is managed? Is it easier for users
with cognitive issues or learning disabilities if both buttons are always
visible?

What's the best way to implement a volume control? I'm guessing a vertical
slider with ten stop points, but is there a better way?

If the user is playing and recording at the same time, would a tabbed
interface be the best way to provide access to the player and recorder, or
would it be better to present them in separate sections with H1 or H2
headers? This approach could be clumsy for sighted keyboard users, who would
still have to tab their way through a bunch of controls to get to the one
they need.

Thanks as always, Isabel
http://webaim.org/discussion/archives

From: Isabel Holdsworth
Date: Thu, Nov 15 2018 8:30AM
Subject: Re: Media player/recorder accessibility
← Previous message | Next message →

Thanks everyone. I'll make Play/Pause a single button.

The kind of scenario we're thinking about might be, for example,
someone taking a sign language test, where they watch a video of a
person speaking in sign language, and translate what they're saying
into spoken word so it can be saved as an audio recording and uploaded
for marking. In this scenario, the candidate would be watching a video
and recording their answer simultaneously. So I guess a single button
could start/pause both functions at once.

Cheers, Isabel

On 15/11/2018, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Isabel,
>
> I prefer that the Play button toggles between Play and Pause. That way, it
> does announce to the user what action is to take based on what the player
> is
> doing.
>
> Having a stop button might be optional. In the case of Youtube, I just
> pause
> a video and that is the same to me as stop. Less buttons to navigate
> through
> and performs 2 different tasks. It pauses the playing, which allows me to
> continue from where I left off, or it pauses the playing to allow me to
> read
> the page or close it.
>
> I have to agree with Glen on the progress bar and specifically the record
> button. Why would you want to play if you are recording?
>
> Also, having both present will be based on what your app specifications
> are.
> If the app supposed to play a video by obtaining a URL from the user and
> you
> want to capture the audio to save it, then yes you can use the record
> button. However, this would have to run on the client and have access to
> the
> sound card or extract the audio from the downloaded track.
>
> I think if you give us more info on what the purpose is for the record
> button, we can give you a better answer.
>
>
>
> --------------------
> JP Jamous
> Senior Digital Accessibility Engineer
> E-Mail Me |Join My LinkedIn Network
> --------------------
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Isabel Holdsworth
> Sent: Thursday, November 15, 2018 2:12 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Media player/recorder accessibility
>
> Hi all,
>
> I'm creating an all-purpose media player and audio capture component, and I
> have a few quick questions:
>
> Is it a good idea to use a single button for Play/Pause, or are separate
> buttons preferable so long as the focus is managed? Is it easier for users
> with cognitive issues or learning disabilities if both buttons are always
> visible?
>
> What's the best way to implement a volume control? I'm guessing a vertical
> slider with ten stop points, but is there a better way?
>
> If the user is playing and recording at the same time, would a tabbed
> interface be the best way to provide access to the player and recorder, or
> would it be better to present them in separate sections with H1 or H2
> headers? This approach could be clumsy for sighted keyboard users, who
> would
> still have to tab their way through a bunch of controls to get to the one
> they need.
>
> Thanks as always, Isabel
> > > http://webaim.org/discussion/archives
> >
> > > > >

From: JP Jamous
Date: Thu, Nov 15 2018 8:54AM
Subject: Re: Media player/recorder accessibility
← Previous message | No next message

If you make this clear to your users before-hand, then yes you can use the
Play/Record button to execute both functions. This will ensure the user does
not forget to press the record button. I like that approach, because it is
simple and leads to less navigation.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Isabel Holdsworth
Sent: Thursday, November 15, 2018 9:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Media player/recorder accessibility

Thanks everyone. I'll make Play/Pause a single button.

The kind of scenario we're thinking about might be, for example, someone
taking a sign language test, where they watch a video of a person speaking
in sign language, and translate what they're saying into spoken word so it
can be saved as an audio recording and uploaded for marking. In this
scenario, the candidate would be watching a video and recording their answer
simultaneously. So I guess a single button could start/pause both functions
at once.

Cheers, Isabel

On 15/11/2018, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Isabel,
>
> I prefer that the Play button toggles between Play and Pause. That
> way, it does announce to the user what action is to take based on what
> the player is doing.
>
> Having a stop button might be optional. In the case of Youtube, I just
> pause a video and that is the same to me as stop. Less buttons to
> navigate through and performs 2 different tasks. It pauses the
> playing, which allows me to continue from where I left off, or it
> pauses the playing to allow me to read the page or close it.
>
> I have to agree with Glen on the progress bar and specifically the
> record button. Why would you want to play if you are recording?
>
> Also, having both present will be based on what your app
> specifications are.
> If the app supposed to play a video by obtaining a URL from the user
> and you want to capture the audio to save it, then yes you can use the
> record button. However, this would have to run on the client and have
> access to the sound card or extract the audio from the downloaded
> track.
>
> I think if you give us more info on what the purpose is for the record
> button, we can give you a better answer.
>
>
>
> --------------------
> JP Jamous
> Senior Digital Accessibility Engineer
> E-Mail Me |Join My LinkedIn Network
> --------------------
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Isabel Holdsworth
> Sent: Thursday, November 15, 2018 2:12 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Media player/recorder accessibility
>
> Hi all,
>
> I'm creating an all-purpose media player and audio capture component,
> and I have a few quick questions:
>
> Is it a good idea to use a single button for Play/Pause, or are
> separate buttons preferable so long as the focus is managed? Is it
> easier for users with cognitive issues or learning disabilities if
> both buttons are always visible?
>
> What's the best way to implement a volume control? I'm guessing a
> vertical slider with ten stop points, but is there a better way?
>
> If the user is playing and recording at the same time, would a tabbed
> interface be the best way to provide access to the player and
> recorder, or would it be better to present them in separate sections
> with H1 or H2 headers? This approach could be clumsy for sighted
> keyboard users, who would still have to tab their way through a bunch
> of controls to get to the one they need.
>
> Thanks as always, Isabel
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >
http://webaim.org/discussion/archives