E-mail List Archives

Search E-mail List Archives 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

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
--------------------

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
> --------------------
>
>
>

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
--------------------