Audio player has multiple functions, but only the player function is communicated to the user

[obulat]

Problem

The player focus has different behavior depending on whether you hit ‘Enter’ or ‘Space’. Space plays the track, Enter opens the track’s page. A single control should not have multiple functions, and only the player function is communicated to the user. The mapping of behaviors is extremely complicated for an interface that practically speaking consists of only three controls: a play button, a link, and a slider to control the audio position. Instead, what I’m seeing is an anchor element that’s been re-mapped to a slider aria-role and the application role. Only one of these behaviors is communicated to a screen reader.

Description

The use of the application role overrides all native functionality, so a user doesn’t come to this with any expectations. However, expectations are useful for keyboard and screen reader users, as it makes interactions more predictable. This means that the only recourse in this interface currently is for users to guess at interactions.

Additional context

Reported by Joe Dolson (https://make.wordpress.org/openverse/2022/09/07/frontend-release-v3-4-8-and-a-call-for-a11y-testing/#comment-95)

Implementation

• 🙋 I would be interested in implementing this feature.

[fcoveram]

I do not understand the design request correctly. What do we need to address visually for this use case?