Lack of accessibility support

[rain-sk]

Hey, thanks for making this lovely little player!

I noticed while adding it to my site that the player itself doesn't have any support for keyboard navigation, and screen readers do not get any info about the player. Is this something you've already thought about? Would you be open to a PR which attempts to improve the situation?

I'm very happy to use this player on my site, but would love for anyone to be able to use it. Let me know what you think!

[rain-sk]

Ah, I was planning to fork this repo and try my hand at adding keyboard/screen reader support, but I see all the code is minified and obfuscated. That makes it impossible to contribute.

Feel free to write to me here if you'd be open to an external contributor helping with this.

[Freeedle]

Hello,

thank you for the input, and you absolutely got a point. Screen reader support is definitely important and valuable, and I had completely forgotten to consider this.

So far, I just wanted to share the script for use but was not ready to share the original code. That's why there is only the obfuscated version on GitHub, which is probably not what GitHub is meant for. And, of course, for someone like you the code is easy to reconstruct.

Still, before deciding to publish the original code I would like to understand first what is necessary to make the player screen reader accessible. I just took a glance at your code, and I see you added a title attribute to the player div and a role and aria-label to the play button which is changing with the player status. And then I see some additional css for highligthing the focussed player. Is that it? You write that your changes would make the player "a bit more accessible". Sufficiently accessible? Or is there more that could be done? If you have more advice to give, I'm very open to that!

If you like, write me privately to the email address indicated on the player website, and if it's easier to discuss directly we also might exchange phone numbers and just talk.

Thank you,

Freedle

https://essential-audio-player.net

[rain-sk]

Hey there, thanks for the quick reply!

I've had another go at this directly on my site, just editing the essential_audio_player.js/css directly. What I would say is that, in an ideal scenario, the div would instead be an actual button, specifically:

<button
  type="button"
  class="{play} || {loading} || {off} || {error}"
  aria-label="{play} || {loading} || {pause} || {error}: {data-title} || {source filename}"
  role="switch"
  aria-checked="{true} || {false} || {mixed}"
  id="{playerId}">
</button>

Source: MDN

For the focus styling, you could rely on the web browser's default outline style, or do something like below (note - unless the custom focus border is more visible than a browser's default, it's not recommended to do something like this):

button {
  border: 1px solid #000;
}

button:focus {
  outline: none;
  border: 1px solid #fff;
}

With JS, you'd set the aria-checked attribute to true if the player is playing, false if the player is paused, and mixed in the other two cases Source: MDN. You would also need to set the aria-label programmatically, so users know what to expect when interacting with the button ("play" would be for when the player is "off", for example).

The benefits of using an actual button are two-fold: you get focus behavior for free, and you get keyboard/screen reader interaction for free too. You only need to handle the click event of the button to support the button being pressed by keyboard and screen reader. You could further support arrow key events to allow for scrubbing through the audio file in time.

Note: I haven't actually tested this code, but this is my best guess at the moment. It would certainly make keyboard interaction much easier to implement. However, I'm not certain how screen readers would announce this button and its various states. Testing with real screen readers on multiple browsers and platforms is the only way to know what works.

If you have any questions about this, feel free to write here. Or let me know if you'd prefer a more direct conversation!

[rain-sk]

I updated the code and my recommendations and references a bit. Make sure you have a look on GitHub for my current thinking on how this should ideally work.

[rain-sk]

In my pull request, I added support for a data-title attribute on the root div, which gives website developers the ability to set a custom title on the player. This would be necessary if the player doesn't have adequate context around it to tell users what the contents of the audio player are. As a fallback, you could use the name of the first source file, but this may not be ideal to listen to, especially if filenames are generated or otherwise outside the control of the website maintainer.