Summary

Explore accessible implementation of conditional form fields.

💬 Description

If one form field is enabled/disabled due to completion of another, then how is this change described to assistive technology users.

Aria-live regions, statuses and other labels can be used to announce the content.

From a WCAG perspective, disabling a field (disabled=true) and making sure that's handled programatically would satisfy the technical WCAG requirement. What you need to consider is the usability of the solution. A WCAG-compliant solution isn't necessarily good user experience for the SR user.

Essentially disabling/clearing a field conditionally is fine as long as all users knows a) it will happen based on their choices and b) are aware when it has happened.

You would need to 'announce' (via an aria-live region) that the place field has been cleared because a SR user isn't going to notice that and might subsequently try to save.

Also, consider helper text above the form that's useful to sighted and SR users - "Add a location. Changing City will clear the form". You may choose to make this only 'visible' to SR users.

Validation should occur on the form as a whole too, so you should disable the 'progress' or 'save' or 'next' button. 'aria-describedby' on the button might be sufficient for SR usability to point back to the error message indicating any failure. If you can't disable 'save' but validate on the save click, then make sure the error message is announce (aria role="alert", I think).

💰 Use value

Guidance and example patterns will allow developers to more easily create accessible conditional forms which will improve overall end user experience and usability of applications.

mi6 / ic-design-system

Conditional form fields patterns #203

Summary

💬 Description

💰 Use value

Additional info

Related stories

188

189

222