-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Amsterdam] Fixing some focus states #4876
Conversation
Note to reviewers: This needs to be a quick fix so that we can get it into Kibana 7.14. There is certinaly more we can do to tackle focus states, but let's keep this scope limited and make issues for follow up. |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in FF@next, Safari, and Chrome
&:focus { | ||
outline: none; // Hide focus ring because of `tabindex=0` on Safari | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(not blocking)
Rather than removing the focus outline, can we set tabindex
to -1
instead? (L519)
I don't imagine the context menu scrolls? (Or, if it does, that'd probably be the edge so I'd rather optimize for the general case and remove a tab stop).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That focus ring around the whole popover is, just that, around the popover.
There used to be two tab stops: the popover and the context menu. Now there's one.
You could go into the example and set tabIndex="-1"
for the popover panel to remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #4884 to further discuss
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Retested in FF, Safari, Chrome on Mac.
Spot checked in FF and ChromiEdge on Windows.
UpdateI added just a few more updates to the mix: EuiBetaBadgeThe new EuiCardNot a focus state, but the |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
One more one last thing 😉When I was fixing the cards ^^, I realized that the border-radius' of EuiPanel's were completely wrong. It was still getting the default theme value of This will actually make quite the impact on consuming applications. 😬 But it's technically a bug fix. |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in Chrome, Safari, Edge and Firefox, and LGTM! 🎉
After working with focus states I can say that now you're my focus states hero! 🦸♀️
I really like the extra updates. The panels look much better with a higher border-radius
and the disabled card looks great.
Preview documentation changes for this PR: https://eui.elastic.co/pr_4876/ |
Preface
The Amsterdam theme prioritizes using the browser's internal focus management through the
outline
property. However, browsers not only display these slightly differently, but also controls when to display them differently. For instance, specifically on Mac OS:outline
on regular:focus
, but supports the new:focus-visible
property to control the display of the focus outline only when using the keyboard.:focus-visible
(yet), but already chooses not to show theoutline
on:focus
unless using the keyboard to navigate.:focus-visible
but does not support customizing theoutline-color
.This portion of the
reset
file also explains further alongside the code.eui/src/themes/eui-amsterdam/global_styling/reset/_reset.scss
Lines 72 to 89 in 7dc7da7
By adding that to the reset file, all focusable elements will have the same focus behavior (within each browser). By all "focusable" elements, that also means anything with a forced
tabindex
. There are a few caveats and gotchas that the following components ran into and therefore needed custom focus states/fixes.EuiPopover
Slightly fixes #4443.
Accessibility note: Accessibility standards require that elements with overflow scrolling ability should be focusable.
I saw this PR only slightly fixes #4443, because the issue still remains for Safari users. This is because, again, Safari uses it's own "magic" to determine when to show focus outlines. While it de-prioritizes
outline
on most interactive elements until using they keyboard to navigate, it does prioritize it when content "pops" in, focus is moved to a new element via JS.One of the main problems that was happening in the issue, though, was that when using EuiContextMenu, there are then 2 panels that get a
tabindex
for shifting focus. I removed the visible outline solely from the context menu panel, but left it on the normal EuiPopover.So that instead of multiple focus rings when tabbing like:
We only get one that is placed (somewhat, at least the arrow is visible) correctly.
EuiHeaderBreadcrumbs
Fixes #4719
Technical note: Header breadcumbs use
clip-path
to create their arrow shape. Usingclip-path
means any outer style likeoutline
andbox-shadow
are not visible outside of theclip-path
.Because of the technical note above, without any customizations, the EuiHeaderBreadcrumbs focus state looked odd because it was cut off by the
clip-path
.Even using
box-shadow
did not work because of theclip-path
.So the best solution I found was to just eliminate the
clip-path
when the breadcrumb is:focus-visible
.Note that the "overflow" breadcrumb has a slightly inner focus ring, this is because of how the display had to be handled with a popover. I didn't think this variant compromising enough to warrant a complete re-work of the elements.
Also, while this still doesn't fix Safari, it's a good compromise of effective focus states and waiting for support.
EuiButtonGroup
Fixes #4684
Technical note: The current functionality of
:focus-visible
cannot be used to target elements via:focus-within
. This discussion is on going and may be supported in the future via:has()
.#4056 refactored EuiButtonGroup for much better (innate) accessibility usability. There are essentially two types that render different HTML elements.
multi
renders<button>
s because their selection are independent of one another and we just use thearia-pressed
attribute for selection.single
renders visually hidden radio inputs encompassed by a clickable<label>
element.The
single
type of button group is what got tricky because of not supporting:focus-within
so originally, and probably mistakenly, we left off thefocus
outlines hoping we'd get support soon.Instead, now this PR prioritizes showing some sort of focus state if there's no support for
:focus-visible-within
. The result is thatmulti
groups work similarly to the regular buttons (only show outline during keyboard nav), butsingle
groups will always show focus ring even when using the mouse (in Chrome & Firefox).Checklist
[ ] Props have proper autodocs and playground toggles[ ] Added documentation[ ] Checked Code Sandbox works for the any docs examples[ ] Checked for breaking changes and labeled appropriately