[a11y]: Left UI Shell and Side rail implementation have bugs and inconsistencies #12323
Comments
|
Jess Lin pointed out that the main content does not always dim when the Hamburger menu is opened. It does on React and on https://carbondesignsystem.com/ but not on https://www.ibm.com/design/ (I assume because that is Carbon for IBM.com). I would strongly advocate that it not be dimmed, at least not unless you automatically dismiss it on loss of focus or hover. Even then, I question the value. |
|
Also, please see my comments in a prior issue on the UI Shell Header regarding use of "sub-menu", "sub-menu-item" and other inconsistent and often inaccurate terms used to describe things in the UI Shell, including in the Left panel. I didn't repeat those in my list above, but they exist here too |
sstrubberg
added
component: ui-shell
type: bug 🐛
package: @carbon/react
|
The ability to dismiss the sidebar with ESC remains a clear violation of WCAG, and warrants Sev 2. Further, although I think design needs to be brought in to validate the rest of the issue and suggested changes, I believe all the items in the issue continue to warrant Sev 2, because it is an area inconsistent for many Carbon interactions, and clarity here may help provide consistency in future decision-making. |
tay1orjones
added
the
planning: umbrella
|
Just as a follow up, my understanding of the complexities around left navigation behaviours has changed since opening this issue. |
Package
@carbon/react
Browser
Chrome
Operating System
MacOS
Package version
https://react.carbondesignsystem.com/
React version
No response
Automated testing tool and ruleset
n/a
Assistive technology
No response
Description
There are a number of keyboard interactions and other behaviours in the Left panel which need to be addressed.
I will detail each issue:
Responsive design issues
When a user zooms up the browser magnification, the left navigation is hidden behind a hamburger menu.
This menu expands the left nav on activation.
Five issues arise with how this is exposed and the resulting content behaves, and two related issues with SideNav rail.
Click to expand the original content that was moved into the individual issues at the bottom of this issue
Problem 1: The Focus Order fails
When the hamburger menu is activated, it discloses a left nav panel.
The traditional and expected behaviour is that the user's next navigation point will be the first item in this revealed panel, either via tab (if it's just revealing a list of links, etc) or via down arrow (if it is revealing a menu).
Instead, the focus progresses across the top navigation, and does not reach the first item in the left nav until all items in the top nav have been reached.
It appears that the same tab order established when the top and left nav were persistent, has not been altered. This seems to constitute a failure of Focus Order. Combined with other issues to be detailed, this leads to a higher severity result for keyboard users.
Problem 2: The responsive menu is not dismissable with Esc
When the hamburger menu is activated, it becomes an X, which can be activated to close the left nav. This is an awkward implementation of a close function, which really doesn't work well with this disclosure pattern. There is no good reason not to cause the left nav to be dismissed on pressing Esc, and there are several good reasons to do it:
Problem 3: The hamburger menu disclosure does not collapse on loss of focus
If the menu is activated, the hamburger menu is displayed. The user can eventually tab through it, but it does not disappear when the tab leaves the left nav.
This is particularly odd since Carbon's implementation of the left nav when the hamburger menu ISN'T activated is much better. In that situation, the left nav is automatically revealled after focus leaves the top menu, and automatically hidden when focus leaves the left nav and enters the main content.
If the behaviour of the activated left nav matched the behaviour when it was just revealed on focus, it would resolve or diminish almost every problem.
Problem 4: The hamburger menu is not renamed
When its icon has changed to an X (which I don't find a great design, personally), its name remains "open menu". If the menu is going to toggle to a closed icon, its name should likewise toggle to "close menu".
Problem 5: The main content is obscured, both through a failure to reflow and the lightbox effect.
When the hamburger menu is activated, two things happen to exacerbate the issue.
This means that the main content is both made less visible due to contrast and partially fully obscured behind the left navigation. This will be a failure in WCAG 2.2 (Focus Not Obscured), and is not a great experience!
These problems are compounded, and there are several ways to alleviate them, some of which solve more than one problem at once. Carbon needs to decide what exactly the responsive design interaction is supposed to be. Happy to discuss the possibilities -- both optimal and acceptable -- from an accessibility perpspective!
Side rail implementation on Storybook failing to handle content in breakpoint - and has an 'impossible' version.
The non-persistent left nav that arises from responsive design is quite similar to the Side rail variation, which reveals a consistently non-persistent left nav. It's quite a nice implementation, and Carbon may want to consider how the variations can be merged into something consistent and best.
However, the implementation of the side rail with header has a significant glitch and some cautions.
The first is, what is the point of having a side rail and a hamburger menu? They both do the same thing (and have the same content!). If the side rail is implemented, there does not seem to be any reason to have a hamburger menu.
Secondly, in the storybook implementation, the 4 links displayed at the top of the nav, which disappear due to response design at about 175% zoom, do NOT appear in the left 'rail' or in the hamburger menu. They should.
Thirdly, there is an implementation of side rail without a UI Shell header. I believe it is impossible to have no UI Shell header -- that it is a requirement of all Carbon pages. Is there some other use case where this makes sense?
That aside, if you consider how the side rail works without the need for the hamburger menu here, you can see that it serves as further evidence that there is NO NEED for the hamburger menu when side rail is used. As mentioned above, where responsive design collapses the top nav, those links can just appear at the top of the side rail content
Side rail cannot be dismissed with Esc
The side rail is essentially a reveal-on-focus (or hover) side panel, which auto collapses when interaction leaves its elements, either via keyboard activation or focus or pointer location. I think it's quite nicely done, but it has one key glitch. Its current implementation fails On Hover or Focus, since it is not possible to dismiss the side panel with Esc. This should be an easy fix (just need to decide where focus would go, which I think is the main content, probably at top of region)
WCAG 2.1 Violation
5.4.3 Focus Order, 1.4.13 Content on Hover or Focus
Reproduction/example
exists in storybook
Steps to reproduce
Responsive design issues
Side rail breakpoint
Side rail Esc
Code of Conduct
Tasks
The text was updated successfully, but these errors were encountered: