After some discussion I propose we make these edits to the example markup. They don’t break anything, and it’s a bit icky that we’re adding extra ids just to do this, but the value we add to VoiceOver users is immense (well, providing back basic functionality that this VoiceOver bug otherwise robs).
Additional information
This PR also fixes a minor margin-left bug on the labels that was introduced in the last merge.
I did have the idea of maybe uniting the guidance on ARIA tags in some capacity, thinking there’d be value in an implementer having all the ARIA info somewhere, so that we minimise the chances of them missing one of these two sections when intending to implement a form fieldset, but I guess it’s impossible to try to anticipate all the various browser–screen reader combinations and how they handle whatever implementation is made…
Description
During testing of https://github.com/AusDTO/gov-au-ui-kit/pull/456 we discovered that VoiceOver historically seems have poor support for
legend, and while it now seems to handle them in Safari, it fails in other browsers tested on Mac OS X (latest Firefox and Chrome).After some discussion I propose we make these edits to the example markup. They don’t break anything, and it’s a bit icky that we’re adding extra
ids just to do this, but the value we add to VoiceOver users is immense (well, providing back basic functionality that this VoiceOver bug otherwise robs).Additional information
This PR also fixes a minor
margin-leftbug on thelabels that was introduced in the last merge.I’ve added a PR to the design guide that just adds a small note to the guidance section for radios and checkboxes respectively, reminding implementers to use ARIA tags, just like we issue in the hint text section at the bottom of the Forms & buttons page.
I did have the idea of maybe uniting the guidance on ARIA tags in some capacity, thinking there’d be value in an implementer having all the ARIA info somewhere, so that we minimise the chances of them missing one of these two sections when intending to implement a form
fieldset, but I guess it’s impossible to try to anticipate all the various browser–screen reader combinations and how they handle whatever implementation is made…… case in point: https://www.powermapper.com/tests/screen-readers/labelling/ (look at the various combos and their support for
fieldset).Definition of Done
npm test)