Having accessible tooltips when a button / checkbox is "disabled" (amongst a few other things)

[ckbedwell]

I'm looking at implementing some clearer feedback to the user in a certain part of our application where real estate is limited and naturally Tooltips feel like the correct solution to reach for to provide the user more detailed information if they wish. However, there are some issues with the current components and the way they interact with Tooltips.

I've created a StackBlitz which isolates these issues to make it clearer and if you'd like to follow along with interactive examples.

This is our Test Runs Table where a user can view, edit and delete test runs. You can see in the column header at the far right we have a checkbox where a user can select all the test runs at once to perform batch actions (in this case batch delete them). Due to the limited header space we have we can't add a label indicating that this button will select all test runs, so I've added a Tooltip.

1. First issue related to Tooltips is when you add a Tooltip to a Checkbox component the Tooltip doesn't appear when you hover the actual Checkbox itself, it does appear if you hover ever so slightly to the right of it. (Refer to StackBlitz to experience this behaviour yourself).

Once a user has hit this button, they are greeted with this UI with several different UI actions: Delete the selected test runs, exit batch selection, deselect all items and select / deselect individual runs.

The next issue we have is that for the Delete button we have to use a <Button /> component because the <IconButton /> doesn't have a fill option. If we were to use an <IconButton /> we would have to add the padding, background and border radius ourselves. However, the <Button /> component's tooltip prop doesn't work, so we have to manually wrap the <Button /> in a <Tooltip /> component.

2. Second issue is a mixture of either: lack of Fill on <IconButton /> and/or the tooltip prop not working on the <Button /> component.

If a user chooses to deselect all items, we disable the Delete Button. This is where we run into some a11y issues with the way disabled works with keyboard interaction. I've recorded the interaction with mouse and then when I switch to keyboard navigation to highlight the issue (as I can't screenshot the mouse cursor).

Screen.Recording.2023-03-14.at.09.45.48.mov

For a sighted user they get the visual cue that the Delete Runs button is unable to perform the action. If they are a sighted mouse user they have an additional cue with the mouse icon switching to a no-operation icon to enforce this. We would still like to improve this experience with Tooltips because it might not always be clear to a user why it is disabled (imagine this table is 30 rows long and flows off the screen and they thought they selected on a single run at the bottom but didn't).

For a user that is using a keyboard you can see this button is now completely impossible to interact with as it gets skipped when I am trying to target it with keyboard.

3. Third issue is that we can't provide a keyboard user, and especially those using a screen reader any information as to why actions they might be used to be performing are now unavailable. At the moment our only recourse is to not use the disabled prop on any of these components but manually recreate the UI state for when we want things to appear 'disabled' -- if we have to do this we have to reimplement a lot of what the design system is supposed to be providing us with (opinions on what a disabled state looks like) which is counter-intuitive.

Here are some other states with this table where we want the ability to convey some actions are disabled and explain why they are disabled so a user can be 100% confident, rather than trying to infer it themselves. It is equally likely that some actions might be disabled because a user has limited access with their role assigned, rather than just the state of the data.

I think this article and associated link are excellent for highlighting other situations of why using the disabled attribute on buttons is not great for a11y and inclusivity.

@staton-hyse11 @JoaoSilvaGrafana

[JoaoSilvaGrafana]

Hey Chris! Thank you for the really detailed points 🙌 Had a call with Staton to discuss some of the issues we have with this right now. Here is what we propose for each of your issues:

1. Checkboxes not displaying tooltips correctly: This is a bug, I will create an issue for it
2. Button not showing tooltip: In the past we thought this was going against how we wanted developers to use Button and if they needed a button with only an icon + tooltip, they could use IconButton, but we are not so convinced anymore, so I will create an issue for Button to support tooltip as well.
3. A11y issues with the disabled states: This will need a bigger discussion about our current disabled pattern. I agree that this is currently an issue for certain users, but it is a bigger change to move various components to stop using the native disabled property and we need to evaluate what consequences this might have.

This also raises another point which is the fact that we don't have a pattern for how to bulk delete on tables, so it might be inconsistent across the product, but also something for us to solve in the future 😄

So, I will create issues for those first two points. What is your level of urgency for those and then we will discuss the disabled state issue with the a11y working group to see everyone's suggestion on how to go about it.

What do you think about this?

[ckbedwell]

This is all great! There is no real urgency as we can find ways to get round all these issues for the time-being.

I have recently joined the a11y working group so looking forward to being part of that discussion! :)

[JoaoSilvaGrafana]

Ah that's great! You can talk about your issues around this as well then 😄

I've created two issues for the other points we talked about: #64755 and #64760

[gelicia]

Hello, as you may have heard, we are transitioning away from using discussions to discuss feature requests. It sounds like this is an open discussion, and we would like those to go to our community forum. I see a couple issues have already been made from this, but feel free to continue to make issues for whatever bugs/features come out of tooltips.