Get WCAG 2.2 updates ready to replicate across all pages

[CharlotteDowns]

What

Finalise everything we need to start replicating WCAG 2.2 visual treatment and summary content across all affected pages.

Includes:

• finalise visual treatment – tags, jump links, etc.
• summary of WCAG-affected pages
• design crit actions

Why

We need to finalise this to be ready to replicate this across all affected pages as part of #3302 .

Notes on Visual treatment

In the WCAG 2.2 prototype we have added text fragments to links in order to highlight the specific updated content in chromium supported browsers.

Text fragments are not currently supported in Firefox (and will never be supported in IE 11, which we still technically support). In these browsers, the user will be jumped back to the top of the page instead which is not a interaction we want our users to have.

The links should probably be swapped out for hardcoded IDs/classes to ensure support for all of our browsers. This wouldn't do the text highlighting effect that fragments do, but this can be mimicked using :target CSS styles.

Using IDs could also mean that the fragment wouldn't need to be kept in sync with any changes to the actual text, making them a little easier to maintain.

Who needs to work on this

Charlotte, Calvin developer

Who needs to review this

@calvin , @steve

Done when

Finalise prototypical WCAG page summary to use on all affected pages

• [x] Draft top-of-the-page summary for each component/pattern affected page (~37 pages)

Actions from design crit #3303 (link to comment)

As of 20/11:

Definitely

• [x] Use our own way of highlighting content using classes and :target, applying a blue inset text to the tagged content from a link. Removing the use of text fragments.
• [x] Edit heading in the WCAG 2.2 summary on each component/pattern page affected – highlight WCAG 2.2 and that it's new
• [x] Run a quick experiment moving the WCAG 2.2 tag to a new line
• [x] Investigate options how to organise list – draft options for by criteria, by component or patterns as-is and add subcategories where possible

Maybe

• [x] Run a quick experiment with the proposed default tag. See the comment on Analyse feedback from WCAG 2.2 prototype crit.
• [x] Putting the list of components/patterns affected in a table.
• [x] Add that we do not own WCAG 2.2.

Finalise visual treatment

• [x] Decided whether we are using a classor an ID
• [x] If using a class we might need to rejig the content to all be contained in one highlighted area
• [x] Agree what the 'custom' highlight could look like (thoughts at the moment are a blue inset text highlight, like we are currently doing in the prototyped summary)
• [x] Accessibility checks, specifically on announcement of highlighted content. @romaricpascal suggested we could use aria note or region
• [x] Implement the changes and add to the combined outcome for one example component.

[CharlotteDowns]

Transcribing a slack thread:

Me:

Hey folks, so I want to add custom :target styling to the new WCAG 2.2 bits of guidance. I need to be careful that I don't apply the same styling to things like headings that may also have :target css. How would I go about naming the ID or class, I see we do something like app-thing-thing, is that the correct assumption and/or doing the implementation?

Team:

Given there’ll be multiple of these snippets across the site (or even on a single page?), you’ll likely want a class rather than an ID (IDs would limit you to only one per page). That’d give a selector of .<THE_CLASS_NAME>:target for the selector (rather than only :target altogether which would catch the headings). I think our sites classnames have a .app- prefix to separate them from the govuk-frontend one. Regarding the naming of that class after the prefix it depends on whether we plan this highlighting system only for linking to WCAG 2.2 bits or something more generic we could reuse to highlight other bits in the future.

1. For the former, something like .app-wcag-2-2-notice (or more suitable English words to describe these little paragraphs)
2. For the later, something like .app-targetable would be generic enough to be applied in different places.

Overall, there’s not a massive pressure on the naming if it’s unique enough for a search and replace. We could start with something like 1. then decide that we need to make it more generic and at that point in time rename .app-wcag-2-2.notice. And similarly if we find 2. too generic, we could later replace .app-targetable with say .app-targetable--<SPECIFIC_THING_1> and .app-targetable--<SPECIFIC_THING_2> .

Me:

This is great, just to replay my understanding, if I used a class name (preferred) to wrap the WCAG 2.2 tagged stuff, I'd only be able to jump and/or style one of these per page?

Team:

Not quite, that would be if you’d used an ID where you’d be forced to have only one per page. Classes will allow you to have as many as you want on a page

Beyond the styling, this also made me wonder if we need to structure the markup of these notices in specific ways for accessibility. Mostly wondering if someone with a screen-reader will get any feedback that they’ve been sent down the page after clicking the link.

When linking to a heading, I’d expect the screen-reader to announce that the user is now on a heading and what the heading’s content is (would need confirmation that it’s what happens). If we point the link to a paragraph in the middle of the content, will they know where they’ve ended? (Depending on the screen-reader support, there are roles we could give to that content, like note or region that may give users an announcement after their browser moved the focus to the linked note)

Me:

Would that mean that all items with that class would be highlighted from a click of one link? For example, on this page, the link 'interact with row actions' highlights a different piece than the link 'change information they’ve previously given in an answer', would this still be possible or would both things be highlighted from either link?

Team:

I can’t think of any other reason to do custom highlighting of content, I suspect this is at a bit of a limit for us. As for accessibility, yeah that’s a good point that content should be clear as possible that the link will jump down a page.

Team:

Only the element whose ID matches whatever is after the # in the URL will be highlighted thanks to the :target part of the whole .<THE_CLASS_NAME>:target selector.

In your example, say the “interact with row actions” linked to #interact-with-row-actions, only the relevant note which would have an id="interact-with-row-actions" attribute would get highlighted. The other WCAG note, which would have a different ID (say id="change-information-previously-given") would not get styled. Both elements having an .app-wcag-2-2-notice or .app-targetable class helps with us maintaining the code: there’s a single selector in the CSS that helps us share the styles in once single place for all the elements that need to be highlighted when linked to for WCAG 2.2 purposes.

So you’ll need both on the notes:

• an ID for the link to function and the :target to pick the right note
• a class to help share the styles across multiple elements (as not inadvertently style another part of the page that could have been linked to, like a heading).

[CharlotteDowns]

Summarising a conversation on Design System team slack

We have come up with a way of custom highlighting WCAG 2.2 related content within our guidance pages. Using the :target selector on the class app-wcag-22 we have styled the contained content to have a background colour when accessed from a link that references a specific ID. The IDs follow a naming structure id ="wcag-[string]".

For users of assistive technology we have included role="note" which we intend to give users more context.

Concerns and experimentation with background-color

Yellow

The initial design solution used background-color: #fff3a4, a tint of the $govuk-focus-colour #ffdd00.

Our reservations on this colour choice are:

• That it should somehow be visually consistent with the way the focus state looks (so it looks like part of the same design) – like having the same padding height, etc
• …whilst also having enough colour contrast with a focus state (for links inside the highlight) – obviously this one is probably more important

Pink

Another suggestion used the govuk-colour("light-pink") #f499be.

Our reservations on this colour choice are:

• It's a little threatening as close to red
• It has low contrast issues with text that uses the $govuk-link-colour #1d70b8

Blue

Another suggestion used background-color: #ecf3f9, a tint of the new blue tag colour #bbd4ea.

Our reservations on this colour choice are:

• It's very close to white and could be easily missed
• Blue is also the same colour as text selection

Purple, green and orange

All of these colours, like blue, had to be very light in order to provide enough contrast with the link colour.

Other suggestions and thoughts

Would this be a good use case for system colour keywords?

color: HighlightText;
background-color: Highlight; 

We could potentially try text-decoration instead of a background-color? but had challenges when a link was focused

Another approach is to have a background colour initially but fade it out after a few seconds.

We have also tried :focus-wthin to remove the highlight when a link is focused.

Further experimentation with outline and outline-offset

We further discussed using outline and outline-offset to put a box around the highlighted content without changing its layout. It would need testing a bit across screens though to ensure it didn't overlap other elements or go outside the viewport at any point.

The benefits of this approach:

– It doesn't affect the readability or contrast of the text at all. – It simplifies the code, we don't need to wrap all text in s in order for each line of text to be highlighted and works better with lists.