(Accessibility) Some content is not fully visible on 200% zoom - example 2

[morhof]

WCAG success criterion 1.4.4 - resize text - AA

Steps to reproduce

1. Click on Menu Item Analytics
2. Click on Dashboard and Create visualisation
3. Change Browser Windows Zoom to 200% (monitor resolution = full HD)

Actual Result

*The breadcrumb is cut off on some pages, so that it’s not perceivable.

Expected Result

*After font size adjustment, all elements of the GUI should be scaled correctly, overlays should be avoided, and all elements should be reachable.

Meta Issue

Kibana Version: 8.3 OS: Microsoft Windows 10 Enterprise (64-bit) Browser: Google Chrome 109.0.5414.75 (64-Bit)

Screen reader: n.a. Relevant WCAG Criteria: WCAG success criterion 1.4.4 - resize text - AA https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

Relevant ARIA spec: n.a.

[elasticmachine]

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

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[Heenawter]

Reassigning to @elastic/kibana-visualizations because the screenshot is referencing Lens and not Dashboard - tested on Dashboard, and the items in the top nav bar collapse on zoom as expected so that the breadcrumbs remain visible :+1:

[bhavyarm]

@Heenawter you rock. Thanks <3

[stratoula]

I cant replicate it, can you give us more details? Which browser are you using? This cant be a visualizations problem as the navigation component is usiversal, so if it happens it happens everywhere :)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[Heenawter]

@stratoula You're right, sorry about that! I think it's just easier to get into this situation in Lens than it is on Dashboard because the Lens app has more/longer links in the top nav than the Dashboard app does. Played around with both Dashboard and Lens, switching different zoom levels + different browser sizes, and it's possible for the breadcrumbs to be completely hidden on both apps under different conditions.

I was able to fix it by adding popoverBreakpoints={['xs', 's', 'm']} to the EuiHeaderLinks component in top_nav_menu.tsx, but I'm not sure this is the best solution since it would be overkill in some apps to break to the bento box menu on 'm'.... The breakpoints should almost be dependent on the number/length of links included. Not sure if this is possible 🤷 cc @elastic/eui-design

[cee-chen]

The breakpoints should almost be dependent on the number/length of links included. Not sure if this is possible 🤷 cc https://github.com/orgs/elastic/teams/eui-design

It's theoretically doable if we add a size observer onto both the EuiHeaderBreadcrumbs and the EuiHeaderLinks (instead of relying on the size of the entire window), but that's a fairly high lift for the EUI team (although we'd welcome contributions!) and not something currently on our roadmap.

In the interim, without any EUI changes, my feedback is there's simply too many header links - is there any way the plugin/app can consider:

1. Reducing the number of links, period, or
2. Adding their own responsive EuiShowFor/EuiHideFor that reduces their header links to EuiButtonIcons (with tooltips with full text) when lower than the m breakpoint

[RalfO99]

@stratoula & @cee-chen : I'm a DT colleague from @morhof : Any question to us left? The test setting (OS, browser, resolution, ...) is described in the ticket ...

[cee-chen]

No questions for you @RalfO99, this is an issue caused by too many header links on smaller width screens/windows.

[vadimkibana]

Hey @stratoula! It seems @cee-chen is suggesting above that it could be solved by reducing the number of links or the amount of space they consume:

1. Reducing the number of links, period, or
2. Adding their own responsive EuiShowFor/EuiHideFor that reduces their header links to EuiButtonIcons (with tooltips with full text) when lower than the m breakpoint

Is there possibility or intent to solve it on the Lens side?

---

Alternatively, EUI or Shared UX could solve it for everyone. I guess there are a number of approaches, @cee-chen has already mentioned a few. I have another approach in mind, tell me what you think:

On smaller screens we could render just a single button of links, on click it would open a dropdown popup with all the links.

[stratoula]

@vadimkibana let me bring it to the team to see what we can do, we can possibly make the text smaller but I can't see any link there that can be removed. I will let you know about the outcome.

[vadimkibana]

On small screen buttons are already collapsed to a popup dropdown, we could do the following:

• [ ] Collapse the buttons sooner
• [ ] Add spacing around button element

[stratoula]

So after discussing with the team the best we can do is chaging the Explore data in Discover to Explore in Discover but I am not sure if this is going to improve the situation here. We already have changed the Download as CSV to Share so the menu is already smaller.

[bhavyarm]

@stratoula apologies. I wrote my comment here but forgot to press comment last Friday. Here is the latest screenshot from 8.10.4. So yes, its not fixed yet. Adding @1Copenut for visibility.

[stratoula]

Thanx Bhavya for confirming. Yes even if we change to Explore in Discover I don't think it will help the situation a lot. So I am afraid we should solve it holistically and have the same behavior for all the nav component consumers

[chrisberkhout]

This issue was reported by a user (unknown OS) and reproduced on Linux by setting the OS display scaling to 2.0. Please see https://github.com/elastic/integrations/issues/8970#issuecomment-1910406351 for screenshots.

[eriroley]

As the user mentioned above- windows 11 - I was able to temporarily fix this by changing display scaling on windows to 125% and then back to 100%, but it didn't last, and reverted the the old behavior again after refreshing

[tsullivan]

I'm starting on this task and making some progress.

Adding their own responsive EuiShowFor/EuiHideFor that reduces their header links to EuiButtonIcons (with tooltips with full text) when lower than the m breakpoint

This is the plan I want to achieve. It will require two phases.

1. Support a boolean option in AggregateQueryTopNavMenu (part of the navigation plugin) to switch to icon types on mobile width
   1. When this option is given, all items in the TopNavMenuData array (which is passed as config to AggregateQueryTopNavMenu) must include a mobileIconType field.
   2. The option will be called useMobileIconTypes
   3. When the nav menu item is rendered, it will rely on having a tooltip field. If a tooltip isn't provided, we will use label as the tooltip.
2. Lens must be updated separately
   1. Set useMobileIconTypes={true} when rendering AggregateQueryTopNavMenu
   2. Ensure that each top nav menu data item includes a mobileIconType field

Step 2 must be done by the Lens team as there are judgement calls that need to be made, about which icon type for that mobile view.

The result will look something like this, from my POC. You can see why judgement calls are needed: if we just go along with what seemed OK to me, we end up with 2 different "Save" icons.

https://github.com/user-attachments/assets/c3571ff6-9c13-4071-90a1-2655da564f36

[RalfO99]

Thank you in advance for your commitment! Last week I had the chance to join a community meeting of more than 40 colleagues with severely low vision or beeing blind. It's so important to support our experts and colleagues so they can furtheron do their job. :-)