[EuiBreadcrumbs] Not visually clear if a breadcrumb has a link

[Dosant]

For the new serverless navigation in Kibana we're changing the look of breadcrumbs from EuiHeaderBreadcrumbs to EuiBreadcrumbs elastic/kibana#166593

Currently in EuiBreadcrumbs it it not visually clear if a breadcrumb has a link or not, for example comparing to EuiHeaderBreadcrumbs:

https://codesandbox.io/s/thirsty-cray-5xspnj?file=/demo.tsx

Do you think we could change this and add a visual difference between a crumb with and without a link in the default EuiBreadcrumbs look?

cc @MichaelMarcialis @ryankeairns

[MichaelMarcialis]

Assuming we wish to maintain the minimalistic nature of these breadcrumbs (which I personally do), the first areas that come to mind where we could apply such visual affordance for linked vs. non-linked breadcrumbs are font weight and color.

Currently, it looks like we use a font weight of 500 for all breadcrumbs. The current/active breadcrumb uses our default text color, while all other breadcrumbs use our subdued text color. On hover/focus of a linked breadcrumb, an underline decoration is added. Without hovering/focusing, the user won't know if a breadcrumb is a link or not.

Perhaps we could update these styles with the following subtle changes to accommodate for a light affordance prior to the user attempting to hover/focus:

• All breadcrumbs switch to 400 font weight, except the current/active breadcrumb (which stays at the current 500).
• Linked breadcrumbs switch to using the default text color (instead of subdued).

It's subtle, but I think it's enough of an offset to indicate to users that something is different about them, without hurting the minimalism of the component. What do you think, @ryankeairns?

[ryankeairns]

Agreed. I briefly poked around at this yesterday and also noted the general use of the subdued color. As has been stated with the proposed changes, they are subtle may be all that is needed.

+1 for the proposed changes.

[cee-chen]

Going to be annoying and insert my non-designer opinion: that is absolutely too subtle for me to notice at a glance personally, especially at smaller font sizes 😅 (or, e.g. for users with low vision acuity).

Could we consider the good old "underline if a link and do not underline if not" pattern, which is generally held to be an accessibility best practice?

[ryankeairns]

Going to be annoying and insert my non-designer opinion: that is absolutely too subtle for me to notice at a glance personally, especially at smaller font sizes 😅 (or, e.g. for users with low vision acuity).

Could we consider the good old "underline if a link and do not underline if not" pattern, which is generally held to be an accessibility best practice?

It's easy enough to try and see how it looks. Let's take a peek when this reaches the PR stage.

[JasonStoltz]

Moving this to a discussion until we can come up with a solution. @1Copenut Can you help us drive this to a conclusion?

[cee-chen]

Just wanted to recap some thoughts we briefly discussed at sync today:

1. If we implement underlines in these breadcrumbs, is this inconsistent with the rest of our links? (see Adding underlines to some links/buttons #3202)
2. Will users be confused or wonder why these links are underlined but other links on the page aren't?
3. Should we consider addressing this more holistically, e.g. the way GitHub has done with making it an optional configuration for text links to have an underline vs not have an underline? See https://github.blog/changelog/2023-10-18-new-default-underlined-links-for-improved-accessibility/

[ryankeairns]

Point raised during sync today: With a guideline around using these on text links, then this (positively) implies they appear most frequently within the page body as opposed to the chrome.

[cee-chen]

Other point raised during sync today: Why do we have breadcrumbs that aren't links at all? Does our IA need work?

[Dosant]

Same for Applications Infrastructure in observability

[cee-chen]

😅 Now this starts to tie in, IA-wise, to #7337 (nav group/accordion titles aren't actually links or pages) which is fun.

[ryankeairns]

This had me curious how it works on the Elastic Stack side, today. Similarly, there is no APM landing page (it is the section title, similar to an accordion parent), and they set it to route to the first child. This makes the APM breadcrumb a link, but that is a curious workaround.

[ryankeairns]

fwiw, I still believe we should stay the course with the accordion change. The question remains, however, how to handle the parent in the breadcrumb. We could consider just not showing it, concatenating it with the child into a single breadcrumb, keeping the Stack behavior (link to first child; not fond of that), etc.

[1Copenut]

I want to consider folding the parent into the final (current) breadcrumb. So in this case our breadcrumb stack would be:

Observability > APM: Services

I feel very strongly that breadcrumbs should only show pages that can be reached. Having APM as a linked breadcrumb divorces the breadcrumbs from the information architecture. I'm left clicking around looking for the APM landing page and not finding it. This is a cognitive load we can reduce by mapping breadcrumbs 1:1 to reachable pages.

[1Copenut]

At the risk of overloading this discussion, I'd like to add another point about breadcrumbs and IA. Breadcrumbs must not be updated or appended when users click on a tab within a page. Tabs change local context; they do not change the parent context. The difference is subtle but important.

I found a concrete example when I started auditing Security Solution UI. I was on a rule detail, IE Endpoint Security. That was my page. But the breadcrumbs did not match this. It took me a while to realize the tabs farther down the page were determining what was in the final breadcrumb. If I hadn't had such a large screen, I might not have seen the tabs below the fold. This is a rough edge in UX and IA that we can improve on.