refactor radio and checkbox icons to use floats rather than position …

[simonschwartz]

Bugfix - Fix screen reader compatibility with radio and checkbox inputs

Description

A DTA Identity project identified that the UI Kit checkbox/radio labels were not being read out by a screen reader. I replicated this issue using VoiceOver on MacOSX 10.10.5

The screen reader currently just reads 'Checkbox checked/un-checked' so the user has no idea what the value of the input they are selecting is.

The cause of this issue was the use of position: relative on the <label> element.

Proposal

This PR proposes replacing css position properties on the <label> element with float: left and negative margin. Using negative margins isn't great - is there a better way?

Additional information

I tested the Checkbox and Radio inputs on gov.uk and they have the same issue. If we find a nice solution we could send a PR to the gov.uk style guide.

Definition of Done

• [ ] Content/documentation reviewed by Julian or someone in the Content Team
• [x] UX reviewed by Gary or someone the Design team
• [x] Code reviewed by one of the core developers
• [x] Acceptance Testing
  • [x] Cross-browser tested against standard browser matrix
  • [x] Tested on multiple devices (TBD)
  • [x] HTML5 validation (CircleCI)
  • [x] Accessibility testing & WCAG2 compliance (npm test)
• [x] Stakeholder/PO review
• [ ] CHANGELOG updated

[klepas]

@AndrewArch and I had a look at this.

I was using VO from OS X 10.12.1 and couldn’t replicate the issue directly.

We did discover that VO plainly seems to skip the legend; it seems to handle the labels fine, but never seems to read out of the legend, unless explicitly selected via the cursor… which defeats the purpose… and even then it’s treated as plain text, and not a legend or in any other way associated to the form it’s in.

From some digging this seems to be a bug with VO back from 2014. 18F have run into this issue also: https://github.com/18F/web-design-standards/issues/792

We overcame the issue by explicitly associating the id of a legend of a given fieldset to the input via aria-describedby. For example:

<form>
  <fieldset>
    <legend id="foo">Which electronic devices do you own?</legend>
    <input id="phone" name="reply" type="checkbox" aria-describedby="foo" value="phone"/>
    <label for="phone">Phone</label>
    <input id="tablet" name="reply" type="checkbox" aria-describedby="foo" value="tablet"/>
    <label for="tablet">Tablet</label>
    <input id="laptop" name="reply" type="checkbox" aria-describedby="foo" value="laptop"/>
    <label for="laptop">Laptop</label>
    <input id="desktop" name="reply" type="checkbox" aria-describedby="foo" value="desktop"/>
    <label for="desktop">Desktop computer</label>
  </fieldset>
</form>

This is apparently non-standard, and not needed by other screen readers.

It’s worth noting we also discovered inconsistent results with NVDA: it would read out the legend and labels without a problem for the radio buttons, but not consistently for the checkboxes. It would read the checkbox legend after each label when using the above markup, and otherwise it appeared inconsistent.

Additional information

• video demonstrating the issue
• table outlining iOS 9.1 HTML4, 5 and WAI-ARIA support — not sure on how up-to-date this is?
• test page for this bug
• test results for fieldset > legend that also holds links, which appears to be related — this page lists browser test results from October 2016
• I tested this in Google’s ChromeVox and it fails to read out the legend in all cases I tested

I’ve also spun up an instance that applies your SASS edits + a partial edit to the checkbox HTML (adding id and aria-describedby): http://dg-checkbox-radio-a11y-test.apps.staging.digital.gov.au/components/forms-buttons/index.html#checkbox-input

Where to from here?

I propose:

• test in JAWS
• potentially contact 18F and GDS?

[simonschwartz]

I tried the markup in your previous post @klepas but am still getting the same error where the label isn't being read out by the screen reader. I did some further research and it seems this may be a bug with Chrome.

http://stackoverflow.com/questions/40846788/why-does-relative-positioning-on-a-label-make-the-label-content-invisible-to-the

Can confirm that this bug isn't happening in Firefox for me with current UI Kit markup

[klepas]

@simonschwartz Hey, thanks for the further info. I was silly and only tested this in Chrome, which explains why I couldn’t reproduce your error the first time, instead finding a related bug. Lel. :)

I’m keen now to merge these changes given that it fixes this problem until this is fixed in Chrome directly.

I’m gonna do some more testing with FF and Safari. I want to investigate if we should update the markup and our guidance to overcome this 3 year old VoiceOver bug. Once done I’ll report back and then I’ll do the work to merge this.

Thanks again.

[klepas]

I’ve adjusted the spacing a bit, and cleaned up a few unnecessary padding and media queries.

[klepas]

Just adding some before | after screenshots from the padding edits to the radio buttons and checkboxes:

Before

---

After

[gazhands]

Great work!