Investigate solution for operating the details component with Dragon

[owenatgov]

What

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

Why

This is in response to https://github.com/alphagov/govuk-design-system/issues/4029. This was raised in a recent DAC audit that dictation software Dragon doesn't recognise the details component and can't operate it. More detail is available in that issue.

Notes

As mentioned in the linked issue, we'd like to avoid DAC's suggestion to convert the details component from a literal details element into an accordion-like component as this will add extra weight to govuk-frontend and undo work we did to remove the details polyfill for 5.0.

Timebox

1 week (preliminary)

Questions to answer

• [x] Can we make Dragon recognise the details component as a details element?
• [x] Is there a way to reimplement the polyfill progressively?

Done when

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

[owenatgov]

Update

Alongside desk research to see if there are other solutions we could try, we'll be experiementing with reverting the removal of the details polyfill to see if that version of the details component works.

This isn't a guarantee that we'll merge that reversion as there are other downsides to including the details polyfill.

Something we could also potentially explore is distributing an extension that contails the details polyfill for end users so that they can use them with Dragon without adding weight to govuk-frontend.

[owenatgov]

After testing the reverted polyfill, we found that it did in fact work with Dragon. We were able to drill down to the specific feature added by the polyfill that was making it work: adding role="button" to the summary element.

We made a PR in order to test this against as many screen reader combos as we couldas this could significantly impact how screen readers interact with the details component. Results of extended screen reader testing available in this spreadsheet.

The analysis of these results isn't positive. Several screen readers swap out the name they use to describe the details component for 'button'. For example, VoiceOver in Chrome uses the phrase 'disclosure triangle' to identify details elements normally, which is now 'button' instead which might be confusing for regular VO users. This is a potential regression but not a huge issue as it still notes that it's expandable.

The dealbreaker is in macOS VoiceOver on Safari. Adding the button role stops VO announcing the expanded state, which is a significant regression and makes this solution on it's own inoperable. A positive is that this could be resolved by adding aria-expanded via js. Testing this very quickly using dev tools in Safari suggests it could work. I'll discuss this with the team and potentially test this next.

[owenatgov]

Update on the above comment: we've discovered the js aria-controls enhancement does work! We've updated the linked PR to include it.

We'd like to double check this with DAC to both verify that the change in announcement from 'summary' or 'disclosure triangle' to 'button' isn't an issue and so that they know about our solution for future audits.

[owenatgov]

We're closing this issue as we have a way forward as per my previous comment. I'll be making an issue to talk to DAC after this.