Rebuilding GUI-radios & GUI-checkboxes

[jonnystening]

Rationale

We have decided to rebuild the GUI-radios and GUI-checkboxes modules, addressing a number of a11y and implementation concerns and bring about some new benefits...

1. Accessibility (WCAG 2.1 AA)

• We have done some major work with form components, working in conjunction with a number of large forms based projects. There will be a 'Forms design system' communicated in the GEL in due course. This will aim to document the ins & outs of robust, accessible and usable forms – which are on-brand and consistent across projects.
• As part of our process we engaged with a leading accessibility testing company who have thoroughly tested our form components and the specific use-case designed assemblies of (what we're referring to as) our 'Form patterns'.
• Our existing radio and checkbox elements were found to have a few issues, as mentioned at https://github.com/WestpacCXTeam/GUI-source/issues/433, concerning...
  • Touch hit area
  • Implicit label/input association
  • SVG check indicator implementation
  • Consistent focus outline styling

2. Reduce maintenance overhead / unnecessary codebase bloat

• GUI-radios and GUI-checkboxes are 99% the same codebase, duplicated into two separate modules. Consolidating GUI-radios and GUI-checkboxes into a brand new module (GUI-form-checks) makes a lot of sense. This provides one module for maintenance, testing and download via the Blender. The only difference required to implement a radio vs checkbox is the html type attribute. Simple.
• This consolidated approach was implemented in Bootstrap some time ago (also called a form-check in their codebase)

3. Markup implementation

• Our implementation required the use of .radio-block and .checkbox-block modifiers in order to render stacked radios/checkboxes, which have become the convention – and strongly encouraged by the likes of Nielsen Norman Group etc. ref. Checkboxes vs Radio buttons
• Rather than require the overly verbose use of these modifiers for every one of these controls we have decided to go with an approach (much like Bootstrap) which is to render block layout by default, and require a modifier for the inline layout edge case. Basically flipping the block/inline layout implementation.

Change summary

The following items have changed...

1. The new module GUI-form-checks replaces GUI-radios and GUI-checkboxes, which are both now deprecated
2. The HTML markup structure and modifier class options have changed, as mentioned below
3. There is a new large option to satisfy the touch hit area requirement – use the modifier .form-checks-item-large
4. We no longer require the use of SVGs to render the check indicators (radio dot and checkbox tick)

Additionally, worth mentioning...

• A number of changes have been made to existing modules and a new Form-Base module has been created to deliver the 'Forms design system' and meet new accessibility requirements. Further details can be found at https://github.com/WestpacCXTeam/GUI-source/issues/433/.

Implementation guide

The following is a quick guide to illustrate the new HTML markup structure. Please refer to the GEL GUI Framework documentation of Form-Checks for the official implementation notes.

<div class="form-checks [form-checks-flip] [form-checks-inline]">
   <div class="form-checks-item [form-checks-item-large]">
      <input type="{INPUT_TYPE}" class="form-checks-input" name="{INPUT_NAME}" id="{INPUT_ID}" value="{VALUE}">
      <label for="{INPUT_ID}" class="form-checks-label">{INPUT_LABEL}</label>
   </div>
   <!-- etc. -->
</div>

[jonnystening]

Ref https://github.com/WestpacCXTeam/GUI-source/issues/173 for additional legacy context

[jonnystening]

GUI-radios and GUI-checkboxes to be deprecated. Both now rolled into GUI-form-checks https://github.com/WestpacCXTeam/GUI-form-checks