Accessibility Guidelines for saving changes to boolean controls in a web app

Question

We currently have some settings pages in a web app where there is a list of controls with checkboxes, so you can enable/disable certain features. We also have a save option below these that is disabled until a change is made to the previous checkboxes.

We are trying to conform this form to be more accessible and the current approach is to simply not disable the save option, but throw an error if no change has been made and a success message on a successful change.

This doesn't seem like it makes the form more usable but only helps to get around the accessibility rule that a submit button shouldn't be disabled. However, from an interaction perspective, the affordance of the disabled look of a button lets a user know that their work isn't complete.

There's 3 possible solutions I've come up with for this scenario:

1. Maintain a READ view of these controls where no action can be taken unless clicking EDIT to change the controls. in EDIT mode, the checkbox options are available as well as SAVE & CANCEL and **SAVE* would be disabled until a change was made (not sure if this passes accessibility, but at least makes the idea that you are "editing these fields and must save it" more deliberate).
2. Style the button like a disabled button but use HTML to treat it like a regular button. If clicking the button, we can display a warning that states "You did not make any changes. Please change some controls in order to save".
3. Change the checkboxes to be a switch-style component that simply autosaves, which takes the "Save" button out of the equation.

If any accessibility inclined people have thoughts on which of these options (or some alternate that I didn't think about) would improve the usability of this scenario while making it accessible, please let me know.

Answer 1

but only helps to get around the accessibility rule that a submit button shouldn't be disabled

There is no such "rule". There is nothing implied in WCAG that says a submit button cannot be disabled.

Personally, I think the simplest approach is to leave the SAVE enabled and allow someone to save even if they didn't make changes. Why should that throw an error? It's a very simple UI. Let the user click on SAVE as often as they want.

Another possibility is to autosave, depending on how "expensive" it is to save. You could save everytime a checkbox is selected. This is a very popular pattern. Then you wouldn't need a SAVE button, although you might need a way to UNDO.

Answer 2

The question says,

We are trying to conform this form to be more accessible and the current approach is to simply not disable the save option, (...).
This doesn't seem like it makes the form more usable but only helps to get around the accessibility rule that a submit button shouldn't be disabled.

However, WCAG 2.1 does not prohibit disabled buttons or user interface components. In fact, success criteria 1.4.3 (Contrast Minimum), 1.4.6 (Contrast Enhanced and 1.4.11 (Non-text Contrast) all contain an exemption for "inactive components". There is no success criterion that prohibits disabling user interface components.

The first scenario, using a read view and an edit view, is something I have seen in learning management systems but seems over the top for normal forms. Users will expect the checkboxes to work like checkboxes in other web apps.

The second scenario, making a regular save/submit button look like a disabled button until something in the form has been changed, has other disadvantages:

• WCAG SC 1.3.1 requires that, "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." So if it looks like a disabled button, it should be programmatically determinable as such, e.g. by using the aria-disabled state.
• WCAG SC 4.1.2 requires, among other things, that the state of user interface components is programmatically determinable. This would also apply to disabled buttons.

(You should also think about whether you want that disabled button to be keyboar-focusable.)

Scenario 3 would also work but probably involves much more work than using a disabled button that conforms to the criteria listed for the second scenario.