[TASK] Fix Lighthouse failure - radios

[MagdalenaLarge]

Alessio addressed Lighthouse failure in the ticket https://github.com/ONSdigital/design-system/issues/3350.

As an outcome of the above ticket, identified a need to address the warnings for all below radio component.

List of components

1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-text-input.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-text-input-expanded.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-text-area.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-text-area-expanded.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-select.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-select-expanded.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-radios.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-radios-expanded.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-checkboxes.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-revealed-checkboxes-expanded.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-clear-button.html 1 result(s) for http://localhost:39203/components/radios/example-radios-with-clear-button-expanded.html 1 result(s) for http://localhost:39203/patterns/correct-errors/example-errors-proto.html 1 result(s) for http://localhost:39203/patterns/correct-errors/example-errors-proto-errors.html 1 result(s) for http://localhost:39203/patterns/feedback/example-feedback-form.html 1 result(s) for http://localhost:39203/patterns/feedback/example-feedback-form-errors.html

Action Use yarn start and then move onto the above components in order. Use the lighthouse test from the google chrome dev tools. Run the test on the component and only look at the accessibility score. Fix the issues highlighted under the accessibility section. Run the test again and confirm that they are now at 100. Move on to the next component.

[rmccar]

This one is flagged by lighthouse because the aria-expanded attribute that we set to true when the revealed input is shown isnt currently fully supported by radios (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded#associated_roles) but it is supported by checkboxes though so that is why this is only an issue with the radios component. There is an open issue on the aria GitHub repo raised by someone working on the gov.uk design system (https://github.com/w3c/aria/issues/1404) this could be added support for in aria 1.4 as it has been moved to that milestone but it does still seem to be under consideration for W3C.

Here is the discussion that has been had on the gov.uk DS about it (https://github.com/alphagov/govuk-design-system-backlog/issues/59#issuecomment-2102440106) and the following issue (https://github.com/alphagov/govuk-frontend/issues/979) in which it is discussed and their rationale for making the decision of keeping the invalid attribute in and ignoring the test failures for the time being.

Based on this I think we should do the same and see if we can ignore this failure by changing the lighthouse config.

[rmccar]

Have contacted DAC to see if there is any value in using this attribute on radios for screen readers. Moving to blocked waiting for response

[rmccar]

Response from DAC on this that may require some discussion and a design decision:

While we recognise the use of radio elements with unsupported aria-expanded attributes as a technical failure of WCAG 2.2 Success Criterion 4.1.2: Name, Role, Value, our users do not find there to be an issue with it.

In some cases, depending on the combination of web browser and assistive technology, the expandible / collapsible functionality is not exposed to screen reader users; however, our screen reader users do not typically report issues locating or interacting with conditionally revealed content.

So in that sense, removing aria-expanded attributes from the conditionally revealing radio elements should not have an adverse effect on most screen reader users. However, this would not conform with the GOV.UK Design Systems current recommendations and it would deprive screen reader users who may otherwise benefit from the use of radio elements with aria-expanded attributes.

We are aware that the Government Digital Service have had conversations with the ARIA Working Group who agree that the use of radio elements with aria-expanded attributes should not be classed as a fail.

For that reason, we do not report the use of radio elements with the presently unsupported aria-expanded attributes as a failure.

We do, however, recommend that clients address this subject in their accessibility statement to indicate that they are aware of the continued development of the ARIA Working Groups technical specifications.

We don’t believe that the ARIA Working Group has amended the technical specifications as of yet and in the meantime we strongly recommend avoiding conditionally revealing radios. Suitable alternatives might include:

Providing an additional form input related to specific radios directly below the radio group and provide a descriptive label that references the corresponding radio; Presenting users with an additional question page, similar to the GOV.UK Design System’s guidance regarding Question pages – GOV.UK Design System. These methods would avoid non-conformance with 4.1.2 Name, Role, Value and should decrease the probability of users being unaware that additional content is displayed upon selection of some specific radios.

[rmccar]

After discussion with IXD have decided to remove the ability to hide inputs on radios and just have them always show on page load, we will then not need to set the aria-expanded attribute