[Feature Request]: Provide support for buttons that are both disabled and focussable

[grahamharper]

The problem

There can be instances where elements need to be exposed as disabled, but are still available for users to find when navigating via the Tab key. Doing so can improve their discoverability as they will not be removed from the focus order of the web page.

The solution

• Disabled styled button that has a focus indicator
• aria-disabled=true

Examples

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled
• https://css-tricks.com/making-disabled-buttons-more-inclusive/

Application/PAL

Merative Social Program Management

Business priority

Medium Priority = upcoming release but is not pressing

Available extra resources

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[mbgower]

You may want to have a look at the Authoring practices section on The focusability of disabled controls. Generally, focusable disabled buttons is a very problematic idea.

I have various issues with the second article you cite, among them the steps that have to be taken to try to prevent someone from being completely confused by a button that looks like it is enabled but is actually disabled. Rather than get into them in detail, I offer this basic consideration. If an item is disabled, its contrast is allowed to go way down because from an accessibility perspective, it's as if the item isn't there. As such, a good test of a design is to remove disabled elements from a UI, and see if the interaction works okay if they only became visible as they are enabled (essentially akin to the experience of a blind screen reader user).

User testing (with a decent pool of people with relevant disability and modes of operation) is going to help understand whether this is a perceived problem or is something actually impeding users. For example, in most interactions, blind users interact with a progressive form linearly. So they are not going to try to advance past the ticket input (to use the simplistic example in the article) without adding a ticket. If they don't add something, why would they expect to be prompted with a read-only button to add nothing to the cart?

Conventions should be tampered with cautiously. Sighted experienced users have had decades of adapting to the fact that disabled buttons are low contrast and inoperable, and buttons with decent contrast are operable. It doesn't take a lot of imagination to foresee how frustrating it could become for some of these users if Carbon pages suddenly had buttons which may or may not be operable popping up all over the place -- and the only way to tell is to hover on them (on a desktop), or worse having to click and see if anything happens (on a mobile), or worse yet, having to navigate to them and try to operate them (as a sighted keyboard user) to see if they tell you whether you can use them yet.

[grahamharper]

Thanks for all the input, really useful.

Your concern seems to mostly be with the visual presenation of the button and the risk of it looking enabled when it is actually disabled? If the visual design of the control was clearly dimmed/disabled, but the only difference from a real disabled control was that it was now focussable would you still have the same concerns?

Our specific use-case is a list of items, each item has a menu of actions: Edit, Delete. In some circumstances when a user first encounters this interface the Edit button might be disabled, due to some business rules about when they are allowed to edit the item. Later on once the business conditions are satisfied the Edit action may be performed and the button will become enabled.

To explain a bit more, the purpose of this enhancement is to allow the user discover the Edit action when they first encounter it so they know it's there as an action they might take in the future. Like a sighted user can. The intention is that the Edit button would still clearly look disabled.

Generally in this situation, I would prefer to solve the problem by having the action enabled and provide feedback to the user if they try to trigger it as to why they can't, but this approach isn't always feasible particularly in a product like our which has many existing instances disabled buttons.

[mbgower]

Ah, well take heart then, since a menu item isn't a button. If you have a look at that first link I referenced, you'll see that they are actually allowing something that is not in the tab order to behave as you're suggesting.

For example, as demonstrated in the 3.15 Menu or Menu bar pattern, disabled items are focusable when navigating through a menu with the arrow keys.

So menu items, which are reached by arrowing not tabbing, are given a get out of jail free card.

Note that this is still 'controversial'. For instance, many menus do not allow arrowing to disabled items. However, you have this document to back you up, so are on a lot firmer ground, at least for your menus :)

I'm less clear on the interaction of what you're calling an inline button. There is no such variant in core Carbon button, so I don't fully understand what it is or how it is intended to be operated.

[mbgower]

However, having looked a bit more closely at the details in your response, this also gets messy pretty fast, because it looks like you're adding interactions on your menu items...?

The challenge here is that menu items have one of two functions: activate or (where they have a submenu) open submenu. It sorta looks like you're trying to add actions to a menu-like control (what you call a list). That is a tough interaction to make both operable by keyboard and understandable by assistive technologies, because it's not expected behaviour and contradicts conventions -- if I'm understanding what's going on here.

[grahamharper]

Sorry for the confusing mock-up on my part, I just whipped it up quickly.

Imagine each of those “List items” were a row in a table (our exact use-case) or even an item in an unordered list, like a list of Issues in GitHub, and you can either Edit or Delete each one.

the button in my example is just a Carbon ghost button place in the list item row. Clicking it will perform that action on the item in that row.

In Carbon this would be Inline actions on a data table row see https://carbondesignsystem.com/components/data-table/usage#inline-actions

[grahamharper]

It might possible to consider the Edit and Delete buttons as a toolbar (we could implement the toolbar pattern so they are contained within a single tab stop).

Based on the article you referenced it does allow for

For elements contained in a toolbar, make them focusable if discoverability is a concern.

A toolbar in an editor contains a set of special smart paste functions that are disabled when the clipboard is empty or when the function is not applicable to the current content of the clipboard. It could be helpful to keep the disabled buttons focusable if the ability to discover their functionality is primarily via their presence on the toolbar.

[mbgower]

So, I'd like you to imagine you are navigating that hypothetical table with a keyboard. Depending on how that is implemented, if I want to move to the next row, I'd be forced to tab additional times to advance -- including on buttons I cannot even operate right now. Now multiply that by the number of rows in the table, and you start to see how it has a significant time-on-task hit. Not hard to imagine how your keyboard users may not think you're doing them any favours.

A better way to think of a toolbar, as discussed in that context, is the rich text one you see above the github input. Start typing a response to me, and then press Shift+Tab once on your keyboard. You'll notice that the focus goes to the a single item in the toolbar, and then all the other items are reached with arrow keys. If one of those gets disabled, it's not very expensive for a user, because at worst on those infrequent occasions they want to format text (and don't know the keyboard shortcut), it's going to be one more key press. That's why the article talks specifically about not disabling things in the tab order, and saves navigable disabled elements for arrow key operation -- where the effect on time of normal tasks is negligible.

[mbgower]

BTW, as mentioned, the kebab menu can contain disabled items (edit/delete), as per the ARIA guidance, so for that interaction, that's one solution. You could also consider an "edit" button for the entire table that turns on those kebabs/actions so that users don't always have them in the UI.

[sstrubberg]

Hey @grahamharper, this is a really cool thought exploration that probably requires additional hardening before it's worked on. I would suggest attending on of our Carbon/Accessibility Guild calls so we can have a more nuanced conversation. After that, during that process, we'll be able to more accurately determine if the maintainer team will take this on, it will be a community driven effort, or something else entirely. I'll keep this in our icebox for the moment though :)

[grahamharper]

@sstrubberg how do I join the accessibility guild? Is it open to non-IBMers?

[sstrubberg]

@sstrubberg how do I join the accessibility guild? Is it open to non-IBMers?

Hey @grahamharper, apologies. I just looked you up on Slack and it looks like you're no longer an IBMer. Hope everything is going well on the outside! I'll have to check with Accessibility team on having the call open to former IBMers ;)

[grahamharper]

Correct, part of the watson health spinoff to Merative. Still using Carbon though!

[mbgower]

I've asked for guidance