Go back Solution

4.2. On-demand changes

Introduction

Nowadays it's very common to interact with pieces of UI where the content changes immediately after we click on it.

For example, the "like button" or "toggle dark theme". This is an action that happens immediately, without a middle step to confirm that action. That's the opposite of a traditional form submit.

Should that affect how we use/create those interfaces? Let's explore…

Exercise

In the exercise page, there is a layout with a few "toggle settings" that are applied immediately after change (without a submit button).

Visually, it's perceiveable the options available before we click (activate) them. What about people who use only the keyboard or a screen reader?

🎯 Goal: Improve the accessibility of each setting.

Note: Each case might have multiple solutions. It's totally okay if your own solution is different from the one proposed.

Suggestion for QA & designers:
This exercise will require a good chunk of code changes. It's totally fine if you don't feel comfortable with it.
As an alternative, I suggest you to write down a list of the things that need to be improved, and, perhaps pair up with your group to collaborate together!

🍀 Tips about moments of actions

One of the differences between a form control and a button is:

That's the main question we should ask ourselves when building an interactive element:

🍀 The way a funcionality is presented might misslead us to change its foundations. We need to be mindful about this thin layer between UX and semantics.

🍀 Tips about dynamic names and states

When we interact with "Sound toggle" using a screen reader, two things happen when pressing it:

For a screen reader, changing both name and status can be confusing when the toggle is not active.

If the "sound off" is "unselected", it means the sound is actually turned on. Confusing right?

Here's an example, much clear for screen readers:

🍀 When labeling dynamic elements, never change both label and state at the same time. Stick with one of them.

🍀 Tips about keyboard navigation

Although Tab is the main way to navigate between interactive elements, it's not the only one. In some cases the navigation is done with arrow keys (e.g <select> and <input> radio/checkboxes). We can even create our custom shortcuts.

We might ask: When to use Tabs or Arrow Keys?

The WAI keyboard guidelines are extended and a continuous work in progress. This is my current simplified decision tree:

Further reading

Exercise takeaways

(After the exercise) Reveal takeaways