govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Breadcrumbs
I'd like to propose harmonising the designs for breadcrumbs and back links. At the moment they're similar, but have different underline styling. I'd like it if we could have the same underline styling for both.
The text position stays the same, but the lower underline makes the element perceptually larger and appear to move when you go between pages.
My service uses both breadcrumbs and back links depending on whether you're in the portally type bit, or in a flow with back links. When moving between pages, it feels odd that the underline changes for something that's otherwise a conceptually similar action.
Video moving between the two:
My preference would probably be an underline somewhere between the two - not as much space as the back link, but more than the regular underline. I presume it was shifted down in the back link to allow some space below the arrow.
Quick hack with both having same space as back link:
We're doing a little bit an accessibility review on our site at the moment and in doing so I had a look at our site breadcrumbs, which currently use the GOV.UK Design System pattern. When testing with voiceover, I noticed that there was no indication, on entering the breadcrumb trail, that you'd entered a breadcrumb/nav section.
On reading https://www.w3.org/TR/wai-aria-practices/examples/breadcrumb/index.html, they seem to recommend to use of a <nav> element with aria-label="breadcrumb". Is there a reason that GOV.UK Design System just recommends a plain div over the more descriptive alternative?
Happy to put up a PR if this feels like a thing that was missed rather than being the outcome of a specific decision.
@samuelhwilliams From memory we used <div> in this case as the default to limit confusion screen reader users may face with multiple navigational roles on the page. In this instance the breadcrumbs' role is secondary.
I believe the consensus was - If the breadcrumb is the only form of navigation on the page then it should be marked up using <nav> in place of a <div>, however this can only be done using the HTML, the Nunjucks macro doesn't have the option to switch.
I cannot find this rationale recorded anywhere so it might be worth double checking with the accessibility team too.
There's some more historical context here: https://github.com/alphagov/govuk_elements/issues/412
I'd be happy to revisit this, but we'd want to test any change pretty thoroughly and it's not a priority right now.
The Design System / GOV.UK Frontend will be audited in the next couple of months, so we'll see if anything gets flagged as part of that.
We had a question from a designer about the best way to truncate long text in breadcrumbs.
Was there ever an answer to this question? Should we be truncating long text in breadcrumbs?
We're doing a little bit an accessibility review on our site at the moment and in doing so I had a look at our site breadcrumbs, which currently use the GOV.UK Design System pattern. When testing with voiceover, I noticed that there was no indication, on entering the breadcrumb trail, that you'd entered a breadcrumb/nav section.
On reading https://www.w3.org/TR/wai-aria-practices/examples/breadcrumb/index.html, they seem to recommend to use of a
<nav> element witharia-label="breadcrumb". Is there a reason that GOV.UK Design System just recommends a plain div over the more descriptive alternative?Happy to put up a PR if this feels like a thing that was missed rather than being the outcome of a specific decision.
Consider adding aria-current="page" to the last list item in the W3C example. BTW, I think that the combination of role and name combination makes it reasonable to implement multiple navigations on the same page (site, navigation; breadcrumbs, navigation; etc).
In terms of why we don't put breadcrumbs in a navigation landmark I've documented that decision here:
https://github.com/alphagov/govuk-frontend/issues/1604#issuecomment-539524177
Consider adding aria-current="page" to the last list item in the W3C example.
We do add this attribute to the last item at the moment, thanks for the reminder though.
As mentioned in a previous comment, the WAI-AIRA Authoring Practises breadcrumb example applies an aria-label of Breadcrumb so that users know when they have entered or existed the breadcrumb. Without any landmark being applied to the breadcrumb or any label, screen reader users don't seem to be informed that what they are focusing is a breadcrumb are are left with a standard list. I haven't been able to find any research or documentation around why there was a decision to not label the breadcrumb, so I was just wondering whether it was a purposeful decision, and if so, why?
Are there any research findings/design documentation around why the breadcrumb uses the govuk-text-colour rather than the govuk-link-colour or link typography style? We included the component in some recent testing where a participant explained that they didn't click on the breadcrumb because it wasn't a different colour to the other text on the screen and therefore didn't appear clickable which I thought was interesting!
@JeffersonBledsoe Is that issue due to the list having no list style? It's a feature not a bug: https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html
This was a purposeful change due to rampant “list”-itis by web developers. … Basically, if you remove all default visible indication of the list, there is no indication to a sighted user or screen reader user that the content is a list. If you want to override this heuristic for accessibility, you can always add an explicit ARIA role=”list”.
During a recent accessibility audit of our service, our auditor told us that the govuk-breadcrumbs--collapse-on-mobile on class was inaccessible, as it hides the full breadcrumb trail for users that magnify up to 400%.
I'd like to propose a design change that makes the GDS breadcrumbs component more accessible and increases usability.
The last breadcrumb (on the right) usually always represents the page the user is currently on.
Therefore, this breadcrumb should never appear as a link – as this will confuse users that rely on assistive technology. Currently, the link will reload the page the user is on, which will add no value or purpose to the user experience.
Can this last link be styled to static text without any interactive aspect or underline styling?
This is the adapted design from the GDS breadcrumb component for The National Archives 'Find Caselaw service'. We have found this avoids user confusion and increases accessibility value.
@Terry-Price Our Breadcrumbs component guidance already states that the current page should not be included within the breadcrumb trail (emphasis mine):
Always place breadcrumbs at the top of a page, before the
<main>element. Placing them here means that the ‘Skip to main content’ link allows the user to skip all navigation links, including breadcrumbs.The breadcrumb should start with your ‘home’ page and end with the parent section of the current page.
It is also already possible for a breadcrumb item to be displayed as plain text by not setting the href property on it, though we don't emphasise this functionality in our documentation due to the above guidance.
For example, the below Nunjucks code produces this result with the last item as plain text, also marked up with aria-current="page":
{{ govukBreadcrumbs({
items: [
{
text: "Home",
href: "/"
},
{
text: "Passports, travel and living abroad",
href: "/browse/abroad"
},
{
text: "Travel abroad"
}
]
}) }}
Would our documentation benefit from better emphasising some of these?
Thank you, yes I do think the emphasis should be increased if possible and also the on-page example could show the last breadcrumb without a link. That would really explain it very well to everyone.
Be interested to know how many FE's use Nunjucks? We don't use it at TNA.
we recently tested with a user with visual impairments and used software to zoom into the content more clearly. this user commented that they found it difficult to see the breadcrumbs when not zoomed in at a very high level and found it difficult to find the breadcrumb above the h1
has anyone else experienced this?
Hello, when the screen is under 640px wide breadcrumbs link size and the space between the link are reduced below what is acceptable for WCAG2.2 criteria Target Size (minimum) 2.5.8. It appears to be that the text is 17px high with a 5px margin at the bottom. 17px + 5px = 22px, which 2px short of the minimum requirement. When links stuck in column layout they do not have sufficient spacing between them. It would be good to get a review and confirmation if this is an issue or not as we are starting to audit against WCAG 2.2 and will have to report if it is.
Thanks. P.S. see similar issue on footer link
