Open davidsauntson opened 1 week ago
🚀 Netlify deployed citizens-advice-design-system as draft
https://6724b6aad0918e2b286cb947--citizens-advice-design-system.netlify.app
I like the approach in the example test case. When I tried locally on MacBook with Voiceover on Chrome though, I get a different output:
(Tested on: https://6724b6aad0918e2b286cb947--citizens-advice-design-system.netlify.app/examples/radio_group/error/) What I hear:
Option 1 Select an option, invalid data, Radio button. 1 of 2. Example radio group, group
I found this a bit confusing because the error message came after the label so it almost sounded like part of the label. I think what is described on the example site, where the error message is the last thing the user hears for the field, could sound better.
What is described in the test case for Voiceover on Chrome (expected in our case):
Option 1. Radio button. 1 of 2. Example radio group, Group. [Pause] Select an option.
I thought that there is something to do with the order of our error summary (unlikely but I had no other ideas), but then realised that the example site gives me the same output so it could be that my VoiceOver is set up differently.
(Tested on: https://russmaxdesign.github.io/accessible-forms/fieldset-error04.html )
Also an alternative approach (not sure if it's a good one) could be appending the error message as part of the label somehow, maybe hiding it, although that would have its own accessibility issues (i.e > Option 1 invalid data, Radio button. 1 of 2. Example radio group Select an option, group
All of this with the big caveat that I'm not a screenreader user so I'm not sure what the best practice is - interested to hear what other people think.
At the moment, when a checkbox or radio input in a fieldset with an error gets focus, there is nothing that announces the error message if a keyboard user is just tabbing through the interactive elements of a form.
This PR changes how the error message and the radio button and checkbox groups are rendered to make sure that
aria-describedby
andaria-invalid
are added to the inputs, programatically linking the error message to the inputs.This means that the group error message is announced when an input in a group with an error gets focus. This was discussed in the accessibility working group as part of @danielnissenbaum's discussion about error summaries and the screen reader journey from error to input.
Using https://russmaxdesign.github.io/accessible-forms/fieldset-error04.html for testing, this seems to be the pattern that work best across the different screen readers.
Interested to know what others think and this isn't something that gov.uk do in their design system.