Skip to content
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

[Dashboard] [Controls] Make floating actions keyboard accessible #152155

Merged

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented Feb 24, 2023

Closes #135458
Unblocks #151233

Summary

This PR adds the floating actions back into the regular HTML tree by removing the EuiPortal that surrounded them, thus making them keyboard accessible via some added CSS.

Mar-02-2023 11-54-13

In order to do this, however, there were a few changes that had to be made to the overall Dashboard HTML structure. Previously, as part of relocating the Dashboard scrollbar, the scrollable section of the app was moved to the Dashboard viewport, like so:

Screen.Recording.2023-03-02.at.10.54.43.AM.mov

While this had a lot of visual appeal, because of the structure of the HTML tree, the floating actions had to be moved to an EuiPortal as part of this change so that they would continue to float above the top navigation bar rather than clipping behind it alongside the other contents of the viewport - this made it impossible to add native keyboard accessibility since they were removed from the natural HTML structure.

Unfortunately, by removing the EuiPortal in order to allow for keyboard accessibility, this meant that the scrollable section could no longer be constrained to the viewport - this is because the z-index of child of a given scrollable div is always relative to its parent, which means that the floating actions would clip behind the top nav bar regardless of how high you set their z-index:

Therefore, in order to avoid this clipping, the scrollable section had to remain at the top of the app, like so:

Screen.Recording.2023-03-02.at.10.56.25.AM.mov

In order to keep the benefit of the top query bar remaining in place, the top nav bar was added to a fixed position div that floats above the contents of the viewport as the user scrolls - this ensures that the floating actions, which are now also positioned via a fixed container, can still float above the nav bar while remaining part of the natural order of the HTML tree.

As a follow up, we should also address #152609.

Checklist

For maintainers

@Heenawter Heenawter added Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:large Large Level of Effort release_note:skip Skip the PR/issue when compiling release notes impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. backport:skip This commit does not require backporting Project:Controls labels Feb 24, 2023
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch 9 times, most recently from 993d1f0 to b2529d8 Compare February 28, 2023 19:06
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch 4 times, most recently from b607541 to b430bec Compare March 1, 2023 20:36
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch from b430bec to 17d0107 Compare March 1, 2023 20:37
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch from 17d0107 to 666c5ea Compare March 1, 2023 20:46
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch 2 times, most recently from 8b2995f to 7735e0a Compare March 2, 2023 00:07
@Heenawter Heenawter force-pushed the fix-floating-actions-a11y_2023-02-23 branch from c44397d to d6cb83a Compare March 2, 2023 17:06
// constrained to the container - so, the dashboard is rendered with a vertical scrollbar
css={css`
height: 600px;
overflow-y: auto;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the Dashboard viewport is no longer constrained to the height of its parent container, we need the container (in this case, the EuiPanel) to be responsible for handling the overflow.

Mar-02-2023 09-56-09

Comment on lines +50 to +55
if (parent) {
await parent.scrollIntoViewIfNecessary(DASHBOARD_TOP_OFFSET);
await this.browser.getActions().move({ x: 0, y: 0, origin: parent._webElement }).perform();
} else {
await this.testSubjects.moveMouseTo('dashboardPanelTitle');
}
Copy link
Contributor Author

@Heenawter Heenawter Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The web_element_wrapper service does not accept a topOffset for their moveMouseTo function - this was causing issues because, at the top of this function, they call scrollIntoViewIfNecessary without taking in to account the necessary offset. This was causing the top of the panels to be overlapped by the sticky top nav bar, even if they were already in view before this function was called.

Rather than requesting a review from the QA team to make their version of moveMouseTo accept a top offset for the scroll, I decided to just recreate the actions here instead 🤷

@Heenawter Heenawter marked this pull request as ready for review March 2, 2023 18:50
@Heenawter Heenawter requested review from a team as code owners March 2, 2023 18:50
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-accessibility (Project:Accessibility)

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

Copy link
Contributor

@ThomThomson ThomThomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked through the code and left a few comments + one nit.

Tested this locally and everything works great!

Just out of curiosity, is there any way we could swap the scrollbar design for the EUI scrollbar as a later enhancement?

@Heenawter
Copy link
Contributor Author

Just out of curiosity, is there any way we could swap the scrollbar design for the EUI scrollbar as a later enhancement?

@ThomThomson The scrollbar now belongs to the body of the HTML tree, so I don't think we can make any changes to the style of the scrollbar without that applying to all apps unfortunately.

@ThomThomson
Copy link
Contributor

That makes sense, thank you for the clarification!

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
dashboard 377 382 +5
presentationUtil 149 154 +5
total +10

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
controls 179.2KB 179.4KB +195.0B
dashboard 385.5KB 386.5KB +1018.0B
presentationUtil 146.1KB 129.0KB -17.1KB
total -15.9KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
presentationUtil 31.6KB 35.2KB +3.7KB
Unknown metric groups

ESLint disabled line counts

id before after diff
securitySolution 428 430 +2

Total ESLint disabled count

id before after diff
securitySolution 506 508 +2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Contributor

@andreadelrio andreadelrio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice improvement.

@Heenawter Heenawter merged commit 8fec139 into elastic:main Mar 6, 2023
sloanelybutsurely pushed a commit to sloanelybutsurely/kibana that referenced this pull request Mar 8, 2023
…stic#152155)

Closes elastic#135458
Unblocks elastic#151233

## Summary

This PR adds the floating actions back into the regular HTML tree by
removing the `EuiPortal` that surrounded them, thus making them keyboard
accessible via some added CSS.

![Mar-02-2023
11-54-13](https://user-images.githubusercontent.com/8698078/222524586-8051b8e5-fe1e-48b2-bd83-30a90f9b3417.gif)


In order to do this, however, there were a few changes that had to be
made to the overall Dashboard HTML structure. Previously, as part of
[relocating the Dashboard
scrollbar](elastic#145628), the
scrollable section of the app was moved to the Dashboard viewport, like
so:



https://user-images.githubusercontent.com/8698078/222511861-8707917c-9edc-4292-a182-58924bb00c8a.mov


<br>

While this had a lot of visual appeal, because of the structure of the
HTML tree, the floating actions had to be moved to an `EuiPortal` as
part of this change so that they would continue to float above the top
navigation bar rather than clipping behind it alongside the other
contents of the viewport - this made it impossible to add native
keyboard accessibility since they were removed from the natural HTML
structure.

Unfortunately, by removing the `EuiPortal` in order to allow for
keyboard accessibility, this meant that the scrollable section could
**no longer** be constrained to the viewport - this is because the
`z-index` of child of a given scrollable `div` is **always relative** to
its parent, which means that the floating actions would clip behind the
top nav bar regardless of how high you set their `z-index`:

<p align="center"><img
src="https://user-images.githubusercontent.com/8698078/222518354-80f1df75-69e5-4433-a256-d0b7dc57cd97.gif"/></p>



Therefore, in order to avoid this clipping, the scrollable section had
to remain at the top of the app, like so:


https://user-images.githubusercontent.com/8698078/222512203-60a88fc5-dd68-47ba-aeab-2425afc60a67.mov


<br>

In order to keep the benefit of the top query bar remaining in place,
the top nav bar was added to a **fixed position** `div` that floats
above the contents of the viewport as the user scrolls - this ensures
that the floating actions, which are now also positioned via a `fixed`
container, can still float above the nav bar while remaining part of the
natural order of the HTML tree.

As a follow up, we should also address
elastic#152609.

### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)


### For maintainers

- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
bmorelli25 pushed a commit to bmorelli25/kibana that referenced this pull request Mar 10, 2023
…stic#152155)

Closes elastic#135458
Unblocks elastic#151233

## Summary

This PR adds the floating actions back into the regular HTML tree by
removing the `EuiPortal` that surrounded them, thus making them keyboard
accessible via some added CSS.

![Mar-02-2023
11-54-13](https://user-images.githubusercontent.com/8698078/222524586-8051b8e5-fe1e-48b2-bd83-30a90f9b3417.gif)


In order to do this, however, there were a few changes that had to be
made to the overall Dashboard HTML structure. Previously, as part of
[relocating the Dashboard
scrollbar](elastic#145628), the
scrollable section of the app was moved to the Dashboard viewport, like
so:



https://user-images.githubusercontent.com/8698078/222511861-8707917c-9edc-4292-a182-58924bb00c8a.mov


<br>

While this had a lot of visual appeal, because of the structure of the
HTML tree, the floating actions had to be moved to an `EuiPortal` as
part of this change so that they would continue to float above the top
navigation bar rather than clipping behind it alongside the other
contents of the viewport - this made it impossible to add native
keyboard accessibility since they were removed from the natural HTML
structure.

Unfortunately, by removing the `EuiPortal` in order to allow for
keyboard accessibility, this meant that the scrollable section could
**no longer** be constrained to the viewport - this is because the
`z-index` of child of a given scrollable `div` is **always relative** to
its parent, which means that the floating actions would clip behind the
top nav bar regardless of how high you set their `z-index`:

<p align="center"><img
src="https://user-images.githubusercontent.com/8698078/222518354-80f1df75-69e5-4433-a256-d0b7dc57cd97.gif"/></p>



Therefore, in order to avoid this clipping, the scrollable section had
to remain at the top of the app, like so:


https://user-images.githubusercontent.com/8698078/222512203-60a88fc5-dd68-47ba-aeab-2425afc60a67.mov


<br>

In order to keep the benefit of the top query bar remaining in place,
the top nav bar was added to a **fixed position** `div` that floats
above the contents of the viewport as the user scrolls - this ensures
that the floating actions, which are now also positioned via a `fixed`
container, can still float above the nav bar while remaining part of the
natural order of the HTML tree.

As a follow up, we should also address
elastic#152609.

### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)


### For maintainers

- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
nkhristinin pushed a commit that referenced this pull request Mar 22, 2023
…2155)

Closes #135458
Unblocks #151233

## Summary

This PR adds the floating actions back into the regular HTML tree by
removing the `EuiPortal` that surrounded them, thus making them keyboard
accessible via some added CSS.

![Mar-02-2023
11-54-13](https://user-images.githubusercontent.com/8698078/222524586-8051b8e5-fe1e-48b2-bd83-30a90f9b3417.gif)


In order to do this, however, there were a few changes that had to be
made to the overall Dashboard HTML structure. Previously, as part of
[relocating the Dashboard
scrollbar](#145628), the
scrollable section of the app was moved to the Dashboard viewport, like
so:



https://user-images.githubusercontent.com/8698078/222511861-8707917c-9edc-4292-a182-58924bb00c8a.mov


<br>

While this had a lot of visual appeal, because of the structure of the
HTML tree, the floating actions had to be moved to an `EuiPortal` as
part of this change so that they would continue to float above the top
navigation bar rather than clipping behind it alongside the other
contents of the viewport - this made it impossible to add native
keyboard accessibility since they were removed from the natural HTML
structure.

Unfortunately, by removing the `EuiPortal` in order to allow for
keyboard accessibility, this meant that the scrollable section could
**no longer** be constrained to the viewport - this is because the
`z-index` of child of a given scrollable `div` is **always relative** to
its parent, which means that the floating actions would clip behind the
top nav bar regardless of how high you set their `z-index`:

<p align="center"><img
src="https://user-images.githubusercontent.com/8698078/222518354-80f1df75-69e5-4433-a256-d0b7dc57cd97.gif"/></p>



Therefore, in order to avoid this clipping, the scrollable section had
to remain at the top of the app, like so:


https://user-images.githubusercontent.com/8698078/222512203-60a88fc5-dd68-47ba-aeab-2425afc60a67.mov


<br>

In order to keep the benefit of the top query bar remaining in place,
the top nav bar was added to a **fixed position** `div` that floats
above the contents of the viewport as the user scrolls - this ensures
that the floating actions, which are now also positioned via a `fixed`
container, can still float above the nav bar while remaining part of the
natural order of the HTML tree.

As a follow up, we should also address
#152609.

### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)


### For maintainers

- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. loe:large Large Level of Effort Project:Accessibility Project:Controls release_note:skip Skip the PR/issue when compiling release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.8.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Accessibility][Controls] Hover Actions Must be Reachable by Keyboard
6 participants