Components: Add isFocusable state to Button #19337

diegohaz · 2019-12-27T00:45:29Z

Description

This PR tries to address this comment made by @gziolo: #18931 (comment)

[...] I'd like to replicate focusable and disabled fair implemented in Reakit for Button [...]

This is specially useful when the presence of a button is important enough to be perceivable. For example: a disabled tab that will be activated when the user completes another task.

Even though we should take the low contrast into consideration, sighted users will generally perceive the presence of the button, but screen reader users navigating with Tab won't.

This also enables tooltips for disabled label="tooltip" buttons. That's the standard behavior when using <button disabled title="title">:

How has this been tested?

Checking unit tests and storybook. But I can't reliably test event handlers with Enzyme. #18855 or #17303 could help with that.

Types of changes

New feature

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.
I've updated all React Native files affected by any refactorings/renamings in this PR. .

youknowriad · 2019-12-27T08:54:04Z

packages/components/src/button/style.scss

@@ -212,7 +212,7 @@
 			outline: none;
 		}

-		&:active:focus:enabled {
+		&:not([aria-disabled="true"]):active:focus {
 			box-shadow: none;
 		}


The styles changes make me a bit nervous :P because we have some many button styles ovverrides in the UI that I know this can trigger specificity issues and should be tested properly.

youknowriad · 2019-12-27T08:55:08Z

packages/components/src/button/index.js

@@ -30,6 +35,7 @@ export function Button( props, ref ) {
 		isSecondary,
 		isLink,
 		isDestructive,
+		isFocusable,


Should this default to true instead? I feel this was needed in every disabled button we have in the UI. I'm even wondering if we need a prop or just do this automatically.

Now, it makes me wonder how often we want to have a button which is both disabled and not focusable at the same time. It feels like for accessibility reasons it should always be focusable.

https://ux.stackexchange.com/questions/103239/should-disabled-elements-be-focusable-for-accessibility-purposes - it only confirms this reasoning.

It might be a good idea to set isFocusable to true by default as suggested.

We might be some disabled and not focusable buttons but it might be simply wrong. We should found those cases and take further steps based on that.

Made isFocusable true by default

gziolo · 2019-12-27T23:23:03Z

Is disabled isFocusable intuitive enough? Since isFocusable only makes sense when being used together with the disabled prop, maybe we should come up with a single prop that does the job: readOnly.

I did some quick research and it feels like readOnly doesn’t fit here. I can only see it work mostly in the context of form elements which take input.

diegohaz · 2020-01-06T14:03:31Z

I still don't know what's the best approach to keep the tooltip contrast high when the button is disabled. Right now, button has reduced opacity when it's disabled. Since the tooltip is inside the button in the DOM, it inherits the opacity.

Ideally, tooltips should always render outside the button using Portal or something similar. But maybe that's something for another PR.

youknowriad · 2020-01-07T08:26:22Z

I still don't know what's the best approach to keep the tooltip contrast high when the button is disabled.

Should we remove the tooltip when the button is disabled?

gziolo · 2020-01-07T09:30:13Z

I still don't know what's the best approach to keep the tooltip contrast high when the button is disabled.

Should we remove the tooltip when the button is disabled?

This is what I found in https://inclusive-components.design/tooltips-toggletips/:

[...] icons can accelerate the understanding of an interface, and help to internationalize it. But icons provided in isolation are always in danger of completely confounding a user — because they don't spell anything out. To users who don't recognize or can't decipher the icon, information is missing.

Most of the time, you should simply be providing text alongside icons. Like the perma-visible field labels I just mentioned, textual labels are the most straightforward way of labeling things and they're automatically screen reader accessible if provided as real text (not images of text).

I think we should keep them. In addition, we should stop using aria-label in favor of aria-labelledby pointing to the text in the tooltip. That is something we should consider separately.

gziolo · 2020-01-07T11:31:49Z

How can I reproduce the state where the button has the tooltip which has opacity applied? In the editor, it looks as before:

diegohaz · 2020-01-07T22:27:14Z

@gziolo You can reproduce it in the storybook (Button stories).

It seems that it works in the editor because it's using Popover.Slot, so the tooltip is placed in another place in the DOM.

gziolo · 2020-01-08T10:11:56Z

You can reproduce it in the storybook (Button stories).

It seems that it works in the editor because it's using Popover.Slot, so the tooltip is placed in another place in the DOM.

It's a known issue then. I did some source code checking and I found this:

gutenberg/packages/components/src/popover/index.js

Lines 491 to 506 in 87e5415

    
           	// In case there is no slot context in which to render, 
        
           	// default to an in-place rendering. 
        
           	if ( getSlot && getSlot( __unstableSlotName ) ) { 
        
           		content = <Fill name={ __unstableSlotName }>{ content }</Fill>; 
        
           	} 
        
           	if ( anchorRef || anchorRect ) { 
        
           		return content; 
        
           	} 
        
           	return ( 
        
           		<span ref={ anchorRefFallback }> 
        
           			{ content } 
        
           		</span> 
        
           	); 
        
           } }

If there is no Popover.Slot found, then it renders inline. In the case of the Button component, it's placed as a child element that causes the issue.

gziolo

Let's include the note in the CHANGELOG file about this new prop:

https://github.com/WordPress/gutenberg/blob/master/packages/components/CHANGELOG.md

Otherwise, it looks good. @youknowriad, do you still have concerns? I would be in favor of landing this change.

youknowriad · 2020-01-09T09:30:08Z

I don't have concerns, this is a great PR and I believe there's a lot of places where we can remove code as a follow-up. (We use this pattern in a lot of places).

I still wonder whether the prop is necessary at all, is there a place where we do want to effectively "disable" the button.

diegohaz · 2020-01-09T10:02:19Z

I can remove the prop for now and add it later if it’s needed or make it experimental?

youknowriad · 2020-01-09T10:03:32Z

Maybe we can do a quick audit of our existing "disabled" buttons in our code base and remove it if we want this consistently?

diegohaz · 2020-01-09T10:09:45Z

Sounds good! I’ll have a look.

gziolo · 2020-01-09T12:20:40Z

I still wonder whether the prop is necessary at all, is there a place where we do want to effectively "disable" the button.

Well, that's a great question. We need to find the answer first, I also shared it on WordPress Slack in the accessibility channel (link requires registration):

https://wordpress.slack.com/archives/C02RP4X03/p1578572361042000

diegohaz · 2020-01-09T22:34:10Z

The WAI-ARIA recommendations have a dedicated section to this topic: https://www.w3.org/TR/wai-aria-practices/#kbd_disabled_controls

After reading the article above and the conversation in the link @gziolo shared, since this will change how native buttons work in the browser, I'd make the prop false by default. To be even more safe, I'd expose it as __experimental until we make sure that it works well in Gutenberg use cases (this seems, to me, the best way to introduce any new feature here).

youknowriad · 2020-01-10T08:29:42Z

ok, that works for me 👍

gziolo

Still good, it makes sense to proceed this way 👍

youknowriad · 2022-04-12T09:31:03Z

packages/components/src/button/index.js

@@ -39,6 +44,7 @@ export function Button( props, ref ) {
 		shortcut,
 		label,
 		children,
+		__experimentalIsFocusable: isFocusable,


What's the story of this prop, should we make it stable @gziolo ? Recently I found a use-case where we have a button that switches from disabled to enabled and back and this causes focus loss unless this prop is true. So I'm going to use it but since it's now 2 years old, I was wondering if we should mark it stable? What's the reason for the experimental state.

Yes, we can promote it to stable after checking how the same functionality has evolved in Reakit.

In Reakit it was named focusable. That caused a bit of confusion. It wasn't obvious that the prop would make the element focusable when it was disabled. Some people were setting this prop to false thinking it would disable focus on the element.

We're renaming it to accessibleWhenDisabled in v2 (this name may still change though).

Components: Add isFocusable state to Button

21e3c9c

diegohaz requested review from ajitbohra, chrisvanpatten, jorgefilipecosta, talldan and youknowriad as code owners December 27, 2019 00:45

diegohaz self-assigned this Dec 27, 2019

youknowriad reviewed Dec 27, 2019

View reviewed changes

Make isFocusable true by default

9fb891f

diegohaz requested review from ellatrix, nerrad and ntwb as code owners January 6, 2020 13:43

Merge branch 'master' into update/button-is-focusable

db17a04

diegohaz mentioned this pull request Jan 6, 2020

Components: Improve ToolbarButton #18931

Merged

6 tasks

gziolo approved these changes Jan 8, 2020

View reviewed changes

Make isFocusable prop experimental and false by default

8d9bb96

gziolo self-requested a review January 13, 2020 07:11

gziolo approved these changes Jan 13, 2020

View reviewed changes

diegohaz merged commit 8d1afc9 into master Jan 13, 2020

diegohaz deleted the update/button-is-focusable branch January 13, 2020 17:04

diegohaz mentioned this pull request Jan 15, 2020

Dropdown in Modal Doesn't Work #19453

Closed

ellatrix added this to the Gutenberg 7.3 milestone Jan 20, 2020

youknowriad reviewed Apr 12, 2022

View reviewed changes

priethor added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed [a11y] Color Contrast labels Jul 24, 2023

ciampo mentioned this pull request Nov 15, 2023

DataViews: allow users to add filters dynamically #55992

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Components: Add isFocusable state to Button #19337

Components: Add isFocusable state to Button #19337

diegohaz commented Dec 27, 2019 •

edited

Loading

youknowriad Dec 27, 2019 •

edited

Loading

youknowriad Dec 27, 2019

gziolo Dec 27, 2019

diegohaz Jan 6, 2020

gziolo commented Dec 27, 2019

diegohaz commented Jan 6, 2020

youknowriad commented Jan 7, 2020

gziolo commented Jan 7, 2020

gziolo commented Jan 7, 2020

diegohaz commented Jan 7, 2020

gziolo commented Jan 8, 2020

gziolo left a comment

youknowriad commented Jan 9, 2020

diegohaz commented Jan 9, 2020

youknowriad commented Jan 9, 2020

diegohaz commented Jan 9, 2020

gziolo commented Jan 9, 2020

diegohaz commented Jan 9, 2020

youknowriad commented Jan 10, 2020

gziolo left a comment

youknowriad Apr 12, 2022

gziolo Apr 12, 2022

diegohaz Apr 12, 2022

Components: Add isFocusable state to Button #19337

Components: Add isFocusable state to Button #19337

Conversation

diegohaz commented Dec 27, 2019 • edited Loading

Description

How has this been tested?

Types of changes

Checklist:

youknowriad Dec 27, 2019 • edited Loading

Choose a reason for hiding this comment

youknowriad Dec 27, 2019

Choose a reason for hiding this comment

gziolo Dec 27, 2019

Choose a reason for hiding this comment

diegohaz Jan 6, 2020

Choose a reason for hiding this comment

gziolo commented Dec 27, 2019

diegohaz commented Jan 6, 2020

youknowriad commented Jan 7, 2020

gziolo commented Jan 7, 2020

gziolo commented Jan 7, 2020

diegohaz commented Jan 7, 2020

gziolo commented Jan 8, 2020

gziolo left a comment

Choose a reason for hiding this comment

youknowriad commented Jan 9, 2020

diegohaz commented Jan 9, 2020

youknowriad commented Jan 9, 2020

diegohaz commented Jan 9, 2020

gziolo commented Jan 9, 2020

diegohaz commented Jan 9, 2020

youknowriad commented Jan 10, 2020

gziolo left a comment

Choose a reason for hiding this comment

youknowriad Apr 12, 2022

Choose a reason for hiding this comment

gziolo Apr 12, 2022

Choose a reason for hiding this comment

diegohaz Apr 12, 2022

Choose a reason for hiding this comment

diegohaz commented Dec 27, 2019 •

edited

Loading

youknowriad Dec 27, 2019 •

edited

Loading