Topbar accessibility mobile and zoomed view

[shainanigans]

Describe the bug The Deque audit of Teams raised three issues related to the mobile or zoomed view of the topbar:

1. Content is lost at 200% zoom
2. Content overlaps other content at 320px width
3. Horizontal scrolling at 320px

To Reproduce Steps to reproduce the behavior:

1. Go to stackoverflow.com
2. Open the developer tools
3. Use the responsive emulator and select iPhone 12 (this will give you a similar experience to both a mobile user and a user operating the site at 200% zoom)
4. See the horizontal scrollbar that appears around the action menus and the lost information on the avatar

Expected behavior The design of the topbar for smaller screens is adapted to better suit the available real estate as per the Figma file.

Functional specs

• Priority navigation for the action menu btns (see CSS Tricks or this example), which moves items into the overflow menu as the screen changes sizes.
• When outside the overflow menu, action menus are full width and use existing UI (see the search example)
• When inside the overflow menu, action menus open like an accordion and use existing UI (see the help example)
• The overflow menu can only have one open action menu at once
• Entire block for menu items (e.g. “Help” in the overflow menu) and subitems (e.g. the Help subitems) are clickable
• Sub menus and dropdowns inherit the theme (Teams is always dark, public depends on user’s theme)
• There must be at least a 96px gap (TBC; this should be configurable so we can play with it) between the end of the team name or SO logo and the first menu item unless the first possible item is the overflow menu, in which case the team names gets a ... at the end (rather than wrapping). Exception: logged out view.

[dancormier]

Thanks for documenting the design! I like it but I'd like to raise some concern I have about this approach. Most significantly, this would be considerable technical work within Stacks (and additional work in Core to implement), and it's enough of a departure from our existing design it probably will warrant some CM cycles to communicate these specific changes and collect feedback. Before I forge ahead with implementing this, I figured it's best to see if there's a lighter-lift approach here.

I included some specific notes below.

Describe the bug The Deque audit of Teams raised three issues related to the mobile or zoomed view of the topbar:

1. Content is lost at 200% zoom

2. Content overlaps other content at 320px width

3. Horizontal scrolling at 320px

To Reproduce Steps to reproduce the behavior:

1. Go to stackoverflow.com

2. Open the developer tools

3. Use the responsive emulator and select iPhone 12 (this will give you a similar experience to both a mobile user and a user operating the site at 200% zoom)

4. See the horizontal scrollbar that appears around the action menus and the lost information on the avatar

Expected behavior The design of the topbar for smaller screens is adapted to better suit the available real estate as per the Figma file.

Functional specs

• Priority navigation for the action menu btns (see CSS Tricks or this example), which moves items into the overflow menu as the screen changes sizes.

If at all possible, I'd like to avoid JavaScript solutions for this issue. Having JS handle this issue has the potential to introduce FOUC from the topbar loading before JS has hidden items and it could also introduce additional other accessibility issues (market share and issues for people browsing with JS disabled are remarkably under-reported because most analytics/audit tools report using JS).

FWIW, I think we could handle this in pure CSS using a combination of media queries and :nth-child() rules.

Here's a very rough pure CSS proof of concept:

• When outside the overflow menu, action menus are full width and use existing UI (see the search example)

• When inside the overflow menu, action menus open like an accordion and use existing UI (see the help example)

• The overflow menu can only have one open action menu at once

• Entire block for menu items (e.g. “Help” in the overflow menu) and subitems (e.g. the Help subitems) are clickable

• Sub menus and dropdowns inherit the theme (Teams is always dark, public depends on user’s theme)

• There must be at least a 96px gap (TBC; this should be configurable so we can play with it) between the end of the team name or SO logo and the first menu item unless the first possible item is the overflow menu, in which case the team names gets a ... at the end (rather than wrapping). Exception: logged out view.

I have a few notes on this design:

• At the smallest viewport widths, we might have to make some tricky compromises around how much we include in the overflow menu and it's accordion sections. Panels like inbox and achievements can have lots of pretty low-density information in scrolling panels. I'm concerned that including additional stacked UI elements will make the view cluttered and tough to navigate. We might be able to deal with this by setting a max-height and including horizontal scroll on the overflow menu or by using tree navigation instead of accordions.
• We'd probably want to implement the accordion as a component separately from topbar. We could extend the existing .s-expandable component.
• It's worth noting that the panels that currently open when a topbar item is clicked are all live outside of Stacks and are loaded dynamically. This could require a little refactoring on the Core side of things.

These are just a few thoughts I came up with and I'd be glad to brainstorm with or expand on any points I made if you'd like.

[shainanigans]

@dancormier Thanks for having a look. In terms of a lighter lift approach, the only thing that comes to mind is shoving all the action menus under the overflow menu from the get-go, but we lose some nice visibility of functionality for the user. Depending on how we handle no.1 below, we can have a think about that more seriously.

1. That CSS solution makes sense to me. I think that should work, with a couple questions. How would that work with dynamic team name lengths on the left side—would we set a max-width on the team name? Would we be able to configure that max-width differently to accommodate team names in Teams and the SO logo on the public platform? What happens if a user has custom font sizes enabled in their browser? Do our icons scale with text? If they do, if a user's font size setting is high it may create issues. For the JS solution, we could wait until items have loaded and widths are calculated before showing anything, reversing the show unwanted things first then hide issue into hide everything by default then decide what to show.
2. I'm having trouble visualizing what you mean by "setting a max-height and including horizontal scroll on the overflow menu." Why would a max-height create a horizontal scroll? Did you mean something like this with vertical scroll? If not maybe we can hang to go over it :)
3. For the accordion, whatever makes sense for y'all is good :)
4. That's a good point about the topbar panels that open. I'll raise it with the design team about how we will handle that.

Edit re no.4 I just had a look at the code and fortunately those panels are added in the right place in the DOM underneath the opening item, so all that should be required is removing position: absolute from them in a media query.

[b-kelly]

I'm currently reviewing this in detail and will write up my thoughts separately. In the meanwhile, here are some common cases that have not been outlined in this exploration:

Stack Exchange network sites topbar is a little different

pics

 

Logged in to the network, but no user on this site

pics


topbar is shared with https://stackexchange.com/

pics


[shainanigans]

@b-kelly apologies for the slowest reply ever :) I think all of these cases can easily follow the pattern established. Have a look at the updated Figma here and let me know if you have any other concerns!

[shainanigans]

@dancormier and @b-kelly any fresh thoughts on this?

[dancormier]

I’ve done some thinking and tinkering on this. @shainanigans I think your initial suggestion of priority navigation is probably a better approach than my original suggestion (and other CSS-based approaches I’ve since considered). Going CSS-only seems too fragile and inflexible.

A few finer points/questions on the priority navigation approach:

• Would we show all icons initially then hide some with JS? Or hide all and show after loading? Something else? There’s a few trade-offs to any approach here, particularly when it comes to FOUC and navigating around the site.
• Do we want to listen to browser resizing or just apply on load?
• Showing/hiding icons based on container width should be pretty straight forward. We can most likely use flex to have the action menu btn container take up the remaining width and use it’s dimensions to determine which action menu btns to show/hide.

My most significant concern with these changes is resourcing. Since the topbar is such a hotpath component, we’ll need to allocate time to test, retest, and share changes with the community to gather and address feedback/bug reports.

[shainanigans]

Thanks for looking into this @dancormier :)

• Showing the icons: On the one hand, showing all and then hiding with JS ensures that all users, even those that have turned off JS, can access the nav. That seems like the benefit of that approach to me. Hiding all and showing after loading seems like a less intrusive form of FOUC because we are only adding to the view, not adding then removing. If we decided that isn't a good choice though, and we go for show all --> hide with JS, we could have a media query based default number of icons to show and then override that with JS so we aren't flashing all the icons on the screen for small screens when we really don't have to. Ultimately, I'm happy with whichever approach proves the least jarring for users and least performance-killing.
• Browser resizing: In an ideal world, we would listen to browser resizing. But, again, if it kills the performance, I'm fine without it.

If it's possible to build the priority navigation pattern in such a way that it can be available for all sorts of other menus, it might prove useful. For example, if we design a sidebar that opens and closes and changes the available space of a menu, we could listen to the button click that controls the sidebar and re-render the menu.

What needs to happen to get these resources allocated? Is there anything I can do from a design perspective?