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

[a11y]: Left UI Shell and Side rail implementation have bugs and inconsistencies #12323

Closed
7 tasks done
mbgower opened this issue Oct 17, 2022 · 4 comments
Closed
7 tasks done
Labels
component: ui-shell package: @carbon/react @carbon/react planning: umbrella Umbrella issues, surfaced in Projects views severity: 2 https://ibm.biz/carbon-severity type: a11y ♿ type: bug 🐛

Comments

@mbgower
Copy link

mbgower commented Oct 17, 2022

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.

  1. The responsive design implementation of the left nav, when it is hidden behind a hamburger 'menu', has some keyboard interaction problems.
  2. The Side rail with header implementation of a slide out panel, in combination with the responsive design left nav, does not properly handle breakpoint content arrangement
  3. The Side rail in either implementation (with or without header) fails WCAG On Hover or Focus

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.
Screenshot 2022-10-17 at 1 51 47 PM
This menu expands the left nav on activation.
Screenshot 2022-10-17 at 1 52 04 PM
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:

  1. It allows the user to dismiss the temporarily displayed left nav from anywhere inside the menu
  2. Because the focus does not immediately go into the revealed left nav, but instead traverses the site, it is even more difficult for a keyboard user to reach the X to dismiss the nav
  3. As discussed in the next problem, because the main content is partially obscured with a light-box effect, the inability for the keyboard user to dismiss the left panel, either through Esc or by tabbing out of the left nav, becomes more problematic.

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.

  1. There is a lightbox effect, which dims all the main content
  2. The main content is not adjusted so that it reflows into the space not obscured by the left nav. Instead it continues to display across the whole width of the screen, despite being partially non-visible.

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

  1. Open Chrome browser and navigate to https://react.carbondesignsystem.com/?path=/story/components-ui-shell--header-base-w-navigation
  2. Press tab to navigate through the interface until you reach the end of the left nav and focus lands in the main content. Observe how tab progresses.
  3. Zoom up to 175% so that the top navigation is hidden behind a hamburger menu.
  4. Repeat step 2

Side rail breakpoint

  1. Return browser down to 100% zoom
  2. Open Chrome browser to https://react.carbondesignsystem.com/iframe.html?args=&id=components-ui-shell--side-nav-rail-w-header&viewMode=story
  3. Press tab to navigate through the interface until you reach the end of the left nav and focus lands in the main content. Observe how tab progresses.
  4. Zoom up to 175% so that the top navigation is hidden behind a hamburger menu.
  5. Repeat 3.

Side rail Esc

  1. Open browser to https://react.carbondesignsystem.com/iframe.html?args=&id=components-ui-shell--side-nav-rail&viewMode=story
  2. Press tab to enter Side rail
  3. Press Esc to confirm Side rail is not dismissed (BAD)
  4. Press Tab until main content is reach (side rail collapses, GOOD)

Code of Conduct

Tasks

  1. component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
  2. component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
  3. component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
  4. component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
  5. component: ui-shell role: dev 🤖 severity: 2 status: needs accessibility info type: a11y ♿
    guidari
  6. 0 of 2
    component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
  7. component: ui-shell role: dev 🤖 severity: 2 type: a11y ♿
    guidari
@mbgower
Copy link
Author

mbgower commented Oct 19, 2022

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.

@mbgower
Copy link
Author

mbgower commented Oct 20, 2022

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

@mbgower
Copy link
Author

mbgower commented Feb 24, 2023

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.

@mbgower
Copy link
Author

mbgower commented May 11, 2023

Just as a follow up, my understanding of the complexities around left navigation behaviours has changed since opening this issue.
A key consideration is persistence -- whether the left nav is appearing 'when needed' as opposed to persistently hiding/showing. There have been discussions about whether a hamburger menu is the best icon to use when the main operation is 'persistently hide/show left navigation'.
Happy to help think through all the use cases with whomever.

@guidari guidari closed this as completed Jul 11, 2023
@github-project-automation github-project-automation bot moved this from ⏱ Backlog to ✅ Done in Design System Jul 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ui-shell package: @carbon/react @carbon/react planning: umbrella Umbrella issues, surfaced in Projects views severity: 2 https://ibm.biz/carbon-severity type: a11y ♿ type: bug 🐛
Projects
Archived in project
Development

No branches or pull requests

4 participants