Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate solution for operating the details component with VoiceOver #5310

Closed
6 tasks done
owenatgov opened this issue Sep 11, 2024 · 3 comments
Closed
6 tasks done
Assignees
Labels
accessibility audit july 2024 Issues from July 2024 external accessibility audit against WCAG 2.2 criteria details 🔍 investigation

Comments

@owenatgov
Copy link
Contributor

owenatgov commented Sep 11, 2024

What

Investigate if it's possible to enhance the details component in order for it to be operable via VoiceOver.

Why

This is in response to alphagov/govuk-design-system#4030. This was raised in a recent DAC audit that screen reader software VoiceOver doesn't announce the details component as interactable. More detail is available in that issue.

Notes

DAC's solution is similar to that proposed in alphagov/govuk-design-system#4029 which suggests rebuilding the details component to be accordion-esque. We'd like to avoid this if possible as it would undo work we did to remove the details polyfill for 5.0.

Ollie previously looked into this issue in #5089 so we should also test this to see if it solves the problem.

Timebox

1 week (preliminary)

Questions to answer

  • Can we make VoiceOver recognise the details component as a details element?
  • Does Ollie's solution work?
  • Is there a way to reimplement the polyfill progressively?

Done when

  • Questions have been answered or we have a clearer idea of how to get to our goal
  • Findings have been reviewed and agreed with at least one other person
  • Findings have been shared, e.g: via a write-up on the ticket, at a show & tell or team meeting
@owenatgov
Copy link
Contributor Author

owenatgov commented Sep 20, 2024

Update

From some intitial experimentation and discussion, we think that #5089 is the best solution. We know from testing that it solves the problem fro iOS Safari 17.5.1.

Our plan going forward is to:

  1. get the above PR ready for review and merge it. Specifically we're going to explore the spacing issue noted by @36degrees. We feel it's a useful change, agnostic of this investigation
  2. test in older versions of iOS Safari to see if it makes a difference to older versions. This is so that we have these testing records which we can then note in our accessibility strategy

@selfthinker
Copy link

From testing in older versions of iOS I found that it was worse in iOS 15 and likely the same in iOS 16.
So, this is only fixing the issue in iOS 17 (and surprisingly much older versions like iOS 12).
But that's still a good thing to do as iOS 17 is the predominant iOS version.

More about specific testing results in this comment: #5089 (comment)

@owenatgov
Copy link
Contributor Author

We're closing this investigation and the linked issue as we feel confident that we've solved this. We've noted @selfthinker's fidings above re: the behaviour on older versions of iOS Safari but we're very limited in what we can do here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility audit july 2024 Issues from July 2024 external accessibility audit against WCAG 2.2 criteria details 🔍 investigation
Projects
Status: Ready to release 🚀
Development

No branches or pull requests

2 participants