Update accessibility criteria in component docs #4242
Conversation
MartinJJones
force-pushed
the
update-breadcrumbs-docs
branch
from
63d4350 to
51a9aff
Compare
| The breadcrumb links must have a text contrast ratio higher than 4.5:1 against the background colour to meet WCAG AA | ||
| (this especially applies when [using the inverse flag](/component-guide/breadcrumbs/inverse)). | ||
|
|
||
| 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. This relates to WCAG 2.2 success criterion [2.4.1 Bypass Blocks (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks). |
There was a problem hiding this comment.
Isn't this line too long?
There was a problem hiding this comment.
Also, there are cases of breadcrumbs being used twice on the page, so maybe "always" is too strong? Maybe something like: "Always place the top-level breadcrumbs at the top of the page, before the `<main>` element... This does not apply to secondary breadcrumbs which are e.g. below the title."
There was a problem hiding this comment.
Good points 🤔, the text is currently copied from the breadcrumbs component docs in the design system - https://design-system.service.gov.uk/components/breadcrumbs/#how-it-works
As you say, we do have examples where the breadcrumbs component is used more than once on a page, for example - https://www.gov.uk/hmrc-internal-manuals/debt-management-and-banking/dmbm510110
I think I would need to confirm which is correct and update either the documentation or the pages accordingly, @hannalaakso do you have any thoughts on this one? I can also reach out to the accessibility community / design system team, thanks.
There was a problem hiding this comment.
there are cases of breadcrumbs being used twice on the page
I don't think we know if two sets of breadcrumbs on a page is a pattern we want to encourage, or at least we don't know enough about it to document it here yet. We do have the one known occurrence of two sets of breadcrumbs on the HMRC internal manuals page but as Martin has pointed out separately, there might be an accessibility issue with that implementation which we'd like to investigate but that is out of scope here. The Design System doesn't document two sets of breadcrumbs on a page as a design pattern.
I think the best thing to do here would be to document the standard use of breadcrumbs as Martin has proposed. If we find out later that in fact the use of two sets of breadcrumbs is something we'd like to encourage and we understand the accessibility implications of doing so, then we could come back to this piece of documentation to update it. Reaching out to the accessibility community sounds like a good idea, but maybe doing it as part of that separate card to investigate two sets of breadcrumbs on a page.
| @@ -8,6 +8,8 @@ accessibility_criteria: | | |||
| An earlier version of the component did not use a heading element – this failed WCAG 2.1 Success Criterion 1.3.1 ("Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.") | |||
|
|
|||
| An early version of the component contained a hidden skip link for keyboard and screen reader users, that jumped to the step by step navigation component in the sidebar (similar to the 'skip to content' link at the top of all GOV.UK pages). User testing suggested that rather than helping users it confused them, so this has been removed. | |||
|
|
|||
| Always place the step by step navigation header at the top of a page, before the `<main>` element. Placing the component here means that the "Skip to main content" link allows the user to skip all navigation links, including the step by step navigation header. This relates to WCAG 2.2 success criterion [2.4.1 Bypass Blocks (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks). | |||
There was a problem hiding this comment.
Please see my other comment.
There was a problem hiding this comment.
I've made this a little shorter by removing the links to the success criterion.
MartinJJones
force-pushed
the
update-breadcrumbs-docs
branch
from
51a9aff to
c587bc6
Compare
MartinJJones
force-pushed
the
update-breadcrumbs-docs
branch
from
c587bc6 to
db55371
Compare
Update the accessibility criteria in in the components docs for the breadcrumbs and step by step navigation header components, stating they should be placed before the `<main>` element.
Update CHANGELOG.md, also moved "Remove breadcrumbs example from inverse_header docs" change log entry to unreleased as well
MartinJJones
force-pushed
the
update-breadcrumbs-docs
branch
from
db55371 to
acdf664
Compare
There was a problem hiding this comment.
As discussed with @MartinJJones, the YAML files can be improved by using the operators like >- etc. as the lines are too long for effective editing and git tracking of the changes. As this PR is not directly related to that, this would need to be addressed separately.
Besides that separate issue, it looks good.
What
Update the accessibility criteria for the breadcrumbs and step by step navigation header components, stating they should be placed before the
<main>element to avoid failing WCAG 2.2 success criterion 2.4.1 Bypass Blocks (Level A). This is similar to the guidance provided in the "How it works" section of the breadcrumbs component in the Design System.Trello card
Why
We found a number of places where the breadcrumbs were incorrectly placed inside the main container, which failed WCAG 2.2 success criterion 2.4.1 Bypass Blocks (Level A). Updating the dev docs should help developers when looking at how best to use the component.