SuffolkLITLab / docassemble-AssemblyLine

Quickly go from a paper court form to a runnable, guided, step-by-step web application powered by Docassemble. Swap out branding and pre-built questions to meet your needs.
https://suffolklitlab.org/docassemble-AssemblyLine-documentation/
MIT License
41 stars 5 forks source link

Radio Button Keyboard control #796

Open BryceStevenWilley opened 9 months ago

BryceStevenWilley commented 9 months ago

From the VT accessibility audit:

The groups of radio inputs, although nominally keyboard-operable, do not respond to standard keyboard interactions. (Illustrated below is just one example.) 2-Significant. In a standard radio group:

  • The group is contained within a < fieldset > whose < legend > holds the question.
  • The Tab key takes the user into the group.
  • The arrow keys navigate among the radio inputs within the group.
  • Standard visual focus indicators are presented.
  • Each radio input becomes selected in turn when it receives the focus.
  • Hitting Tab again leaves the most-recently-focused radio input selected as the user’s choice for that group and takes the user out of the group and on to the next focusable element.

In the current implementation:

  • The < fieldset > is present, but the < legend > is generic; in every instance it just says “Choices”. This is unhelpful. Screen reader users do not hear the question unless they go hunting around for it.
  • The Tab key navigates among the radio inputs.
  • The arrow keys have no function.
  • The user must hit Space or Enter to mark an input as selected.
  • Visual focus indication of the radio inputs is inconsistent and relies on a change to the background color.
  • The standard behavior is all default browser behavior—no scripting or ARIA needed so long as standard HTML is used. We assume that the current implementation stems from a desire to create a custom look for the radio inputs. However, instead of relying on hidden form controls, ARIA, and JavaScript, we recommend using standard HTML and styling with CSS.

I've never really considered these before, always generally thinking that the tab and space controls were good. It might be difficult to get an upstream change, but I'll play around with it. At the very least the legend label can be improved.

VTskier commented 4 months ago

@nonprofittechy This was marked a high "level 2-Significant" issue in the audit.

nonprofittechy commented 4 months ago

Another upstream one. I don't think the Lab will be able to do this one on our own.

Pinging @jhpyle on Slack about these ones marked upstream might be a good idea. I know he cares about accessibility and at least he'll be able to tell us if he has interest in fixing it. If it needs to be fixed by Lab, it will need to wait for our new developer.

plocket commented 4 months ago

One of the items isn't about keyboard control:

  • The < fieldset > is present, but the < legend > is generic; in every instance it just says “Choices”. This is unhelpful. Screen reader users do not hear the question unless they go hunting around for it.

This issue is having a deeper discussion about screen readers with fieldset and legend.