Hide Readspeaker for screen reader users

Created on 16 November 2023, about 1 year ago
Updated 17 September 2024, 2 months ago

Problem/Motivation

During an accessibility audit it was flagged we should hide the Readspeaker widget for screen reader users with 'aria-hidden=true' as Readspeaker is redundant for this user group.

Steps to reproduce

Run site with a screen reader (i.e Voiceover). Readspeaker is read out as a option to interact with.

Proposed resolution

Remaining tasks

Patch
Test
Review
Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Feature request
Status

Needs work

Version

2.0

Component

Code

Created by

🇦🇺Australia mcaddz

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mcaddz
  • 🇦🇺Australia mcaddz

    Attaching patch for composer.patches.json file.

  • Status changed to Needs review about 1 year ago
  • 🇩🇪Germany sunlix Wesel

    Thank you for your investigation.
    I agree with the aria-hidden due to the redundant content argument.
    But disabled is not an allowed attribute for anchor elements. So I think we should go with tabindex="-1".
    But the current template has an accesskey="L". I think this could be a discrepancy or?

    The original state of the template come direct from the vendor documentation.

  • Status changed to Needs work 2 months ago
  • 🇦🇺Australia mcaddz

    The original purpose was to hide Readspeaker from screen readers which setting tabindex=-1 won't do if using screen reader navigation (opposed to keyboard tabbing).

    We landed on leaving it as is and letting screen reader users choose to ignore so as not to interfere with keyboard users.

    Might be able to set this as 'won't fix' or 'works as designed'?

  • 🇩🇪Germany sunlix Wesel

    Maybe aria-disabled="true" is what we are looking for in this case?
    aria-disabled="true" only indicates semantically the state, but it's not by function.
    This would have to manually controled for custom elements but not needed here.

    Do you have an opinion on this?

  • 🇩🇪Germany sunlix Wesel

    Ah nope, I think it's worng. I am sorry. aria-disabled does not change focusability. But it must excluded.

  • 🇩🇪Germany sunlix Wesel

    @mcaddz

    Thank you for your feedback. I have discussed this with our partnered agency and considered your response.
    I am fully with you. Our assesment was similiar to yours.
    We leave it as it is. I think there is no full separation of the user groups with the differrent accessibility needs.
    So let them decide on their own.

    But nevertheless, thank you for bringing that up.

Production build 0.71.5 2024