2.4.13: Focus Appearance (WCAG 2.2)

[Febakke]

As a part of working with #997 we should change our focus styling so we dont break the new requirements for focus in WCAG 2.2

New requirements found in 2.4.13: Focus Appearance AAA

When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:

• is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
• has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

Our current version have a yellow border outside of the component and a dark border over the excisting border. The contrast between the unfocused component border and the focus border needs to be 3:1. This probably means we have to move 2px of the dark border outside. So that it meets the contrast to the (often) white background.

Problem with todays focus appearance

We need a contrast of more than 3:1 one between unfocused and focused components. Today we add a dark border on top of our components. Not around it. So we need to measure the contrast between the unfocused color on the component and the focus color. With the blue color we use on buttons we get a contrast of 2.36:1 and i guess it is worse on other unput components that use a darker color like radio and inputfield.

We can solve this for button using the Gov.uk and Brreg way of styling buttons, but that wont solve it for our other components. Below are an example on how Brreg has solved this. In this case with a secondary button the yellow focus color do not have enough contrast to the unfocused pixels. But the focus border has a 3px width and good enough contrast on 2px. On primary buttons this would reversed. Meaning that the yellow focus would have good enough contrast but the border might not.

This might work for buttons, but we also need something that can work on our other components. This applies to all our components whitch have solid border that is 2px or more before focus. (Radio and checkbox are examples of this)

One solution might be to alway put a solid black outline outside the component (when possible) ensuring that there are a bigger difference when focusing. Using our surface tokens you should not have a background that wont comply with our text colour and since we use the same color on both text and focus we should not have an issue contrast.

While trying this out in practice i recognize its not an elegant solution. Some of the components just look weird 🤔

• Check if I understand the new requirements correctly?
• Create a suggestion on how to solve this in figma
• Test on all components in Figma

[mimarz]

We need to involve @Camulos on this :)

[tvs-brreg]

Looking over this I wanted to expand on what Lasse has presented and build on the Brreg's concept of chaning the background colour. Following the same logic as the buttons you end up with the following:

Disregarding the visual vibe this creates I am unsure if this actually meet s the criteria. Technically it does since the orignal border changes to yellow together with the background and the dark border is an "outer border" so that border changes to dark from whatever the background colour was, which I think we can assume is light in this particular case. I think it is counter productive creating a "focus" state that works on both light and dark mode since we still need to hit the "general" contrast criteria as well. The dark border should still provide plenty of contrast in cards as long as you can still utilize dark text inside of them. That said, I could argue that the new "inner border" fails on the "general" contrast criteria since it has no contrast to the new background. But maybe this could be looked past since the actual perceived and experienced contrast as a whole should be well within reason.

Just to see where combining the spirit of the above and the current designsystem i fiddled with some inner and outer border colour changes:

Downside is that it suffers from a similar issue explained above since the inner border now just becomes thicker and it gains an outer yellow border. So really same-same but different.

I think both of these option (although not visually striking) do provide enough "total" or "experienced" contrast to fulfill the intention behind the requirement, which after all, is to remove all uncertainty of what interactive component you are about to interact with.

[Camulos]

Summary of the rules and things that we should think about for contrast:

WCAG 2.2: 2.4.13 Focus Appearance (AAA)
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

WCAG 2.1: 1.4.6 Contrast (Minimum) (AA) (UU)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1

WCAG 2.1: 1.4.6 Contrast (Enhanced) (AAA)
The visual presentation of text and images of text has a contrast ratio of at least 7:1

WCAG 2.1: 1.4.11 Non-text Contrast (AA) (UU)
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author - have a contrast ratio of at least 3:1 against adjecent colors

WCAG 2.1: 2.4.7 Focus Visible (AA) (UU)
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

WCAG 3.0: 2.X.X Color and contrast (kan ha flere krav)
Visual contrast of text (Silver): Provide sufficient contrast between foreground text and its background. (APCA kontrastverdier oppfyller kontrastmatrise)

WCAG 3.0: 2.X.X Control and focus appearance (kan ha flere krav)
? Ukjent

Dark mode
Må også fungere med dark mode og andre brukerpreferanser

[Camulos]

The components that I find most difficult is Accordion and "jump to content" (but that is mostly because of small text in relation to the WCAG 3 contrast method), and also small variants that has smaller text seem to be a problem for future rules (WCAG 3).
Some of my tests can be seen here: https://www.figma.com/file/dFlIoEP3UdoB6D5YfIt96I/Kontraster?type=design&node-id=26%3A15905&mode=design&t=L4ySWqQJ9DasRgBp-1

For WCAG 2.2: 2.4.13 I think the issue can be solved by using the button (and button-like components) focus from us (BR) and moving the border to be on the "inside", for other components I do not see the same issue. However there might be an issue if the component is used on a dark surface or in dark mode.

[Camulos]

A bit more on 2.4.13 Focus Appearance:

Partially contrasting indicators
It is not necessary for the entire focus indicator to have a 3:1 change of contrast. [...]
w3 article on understanding focus-appearance

From the article we are told that if you have multiple indicators, it will be enough if one have the needed contrast from the same normal-state pixels. Having both yellow and dark/black as our focus colours should make it easier to create highly-visible focus states.

[Camulos]

The text-link is an interesting case:

The area is 133 x 31 pixels, to figure out what the needed area for the focus-indicator we use the calculation method described by w3, we end up with 656px2 as the requirement.

(135x33) - (131x29) = 656px2

If we only look at the line at the bottom the area is only 199px2.

(133 x 3) - (2 x 100) = 199px2

That is the new underline area minus the default underline.

This would not meet the requirements, but because the same pixels contrast requirement does not need to be met by the whole focus-indicator, we are probably alright in this case.

However I would like others thoughts on this as well.

[Febakke]

⚠️ This is a work in progress, will continue to write on it later ⚠️
I guess im gonna play the devils advocate here.

Lets first just think about how we are going to solve the WCAG guidelines @Camulos summarized above. The most common way to solve focus is in my experience outside border.

A couple of design systems with high focus on accessibility that has this solution.

• Nav Aksel
• Fælles designsystem (dk)

Example with focus and no focus states

Pros

• Its flexible. Meaning it will work on most components
• It makes the components bigger. Making it stand out among similar components. This is something I think some of the yellow focus indicator designs lack.
• Its easy to follow the focus indicator when it behaves the same across all components
• If we use the same color as our texts we should have good contrast on all surface colors in our palette
• It is easier to design for, making major changes within the component in focus state will be harder to do consistent and correctly over time. And might come in conflict with other states like active (?)
• With 3px outside-border we would always have a large enough focus indicator to pass 2.4.13
• Wont interfere with text contrast. Yellow background color will have a tradeof where you would loose some contrast to text elements in the component.
• Yellow is used as a warning color in our and most design systems. Having it as a fill color on focus will come with a risk (?)

Cons

• It could overlap other content depending on how large the outline is.
• We need to create some logic to change out the color in darkmode or just on dark surfaces. But this is a common approach to focus states.
• It looses the visibility effect that the yellow color has. It clearly makes it easy to see where the marker is.
• If you dont have an ofset, it will not be as visible on dark filled components like primary button.

I would argue that this is a good aproach across most of our components. So is there a way we could combine this solution and keep the effect of the yellow color? Best of both worlds? The main issue is that as I understand its hard to fix have two outside borders with offset at the same time. But lets ignore real world issues for now.

The second example presented by @Camulos below was what I was going to present here. 👇 Its pretty similar to the way we have it today, but by having the light color on the inside we loose issues where the component is filled with a dark color. One downside to this is that some components can look kind of strange. In my opinion this is most glaring on radio and checkbox. But in the context of using tab navigation I suspect it wont be an issue.

⚠️ Under construction - Will finish later ⚠️

[Camulos]

Two methods building on the border outside concept, one replaces any border already on the component (first image) and the other just adds additional borders outside (second image).

Same two concepts on other components (Link text and a few labels have additional styles.


Edit: iste bilde oppdatert grunnet for tynn ramme på 2 første komponenter

[Febakke]

We will do a short meeting on this (21.02)

• Gather all methods and find the most viable method
• Find a way forward

Will summarize the meeting here

[Febakke]

Summary disscusion 21.02

• We will go forward with dark border with ofset as a baseline. This should cover all WCAG Guidelines and be consistent across all components.
  • Some components might need special treatment: radio, checkbox, links, switch, accordion, tabs, toggle group and skip link.
• Second color as a token. This could be transparent (You need to handle darker backgrounds yourself) Or you could set it to yellow or similar colors to handle all backgrounds.
  • We need some guidelines on how this should work in practise.

Tasks

•  Create prototype to test the new focus indicator on multiple components in context. (With multiple colors)

[benteSSB]

Ta gjerne ein kikk på SSB sitt designsystem òg, i tilfellet det finst noko der som ein kan la seg inspirera av: https://design.ssb.no/#/components

[anderssonsaja]

Hei :) Skriver noen tanker her:
En fokusmarkering som kun bytter ut selve rammen rundt komponenten krever kanskje som regel mer dramatiske farger for at det skal bli tydelig nok hvilken komponent som er i fokus (kontrast).
Derav fordelen med kontur (outline) hvor det et avstand mellom fokusmarkering og selve komponenten. Det som man kaller for box-shadow slik som dere har her med en “ekstra kantlinje” blir jo også en fordel med at dere kan ha flere farger, og dermed også få større mulighet til å få god nok kontrast ved ulike bakgrunnsfarger, eller ved dark mode. Men dersom dere går for kun en outline og ikke box-shadow så kan man fortsatt definere ulike farger for fokus både for light og dark mode, så det er dermed ikke nødvendig med begge deler i det perspektivet.
Å ha altfor ulike fokusmarkeringer er heller ikke foretrukket. Blir det for store forskjeller mellom markeringen (bytter mye mellom hverandre), så vil det også være vanskeligere å holde oversikt over hva som faktisk er i fokus og ikke. Det vil si at det på noen bytter bakgrunnsfarge, mens på andre blir det en ramme, og andre blir det et understrek.
For f. eks sjekkbokser o.l ville jeg kanskje heller vurdert å kun bruke fokus på selve komponenten, eller alternativt ha en ramme rundt hele, inkludert ledeteksten, slik som vist i eksempelet her.

[benteSSB]

[like] Hole, Bente reacted to your message:

…

________________________________ From: anderssonsaja ***@***.***> Sent: Thursday, February 29, 2024 9:05:04 AM To: digdir/designsystemet ***@***.***> Cc: Hole, Bente ***@***.***>; Comment ***@***.***> Subject: Re: [digdir/designsystemet] 2.4.13: Focus Appearance (WCAG 2.2) (Issue #1409) Hei :) Skriver noen tanker her: En fokusmarkering som kun bytter ut selve rammen rundt komponenten krever kanskje som regel mer dramatiske farger for at det skal bli tydelig nok hvilken komponent som er i fokus (kontrast). Derav fordelen med kontur (outline) hvor det et avstand mellom fokusmarkering og selve komponenten. Det som man kaller for box-shadow slik som dere har her med en “ekstra kantlinje” blir jo også en fordel med at dere kan ha flere farger, og dermed også få større mulighet til å få god nok kontrast ved ulike bakgrunnsfarger, eller ved dark mode. Men dersom dere går for kun en outline og ikke box-shadow så kan man fortsatt definere ulike farger for fokus både for light og dark mode, så det er dermed ikke nødvendig med begge deler i det perspektivet. Å ha altfor ulike fokusmarkeringer er heller ikke foretrukket. Blir det for store forskjeller mellom markeringen (bytter mye mellom hverandre), så vil det også være vanskeligere å holde oversikt over hva som faktisk er i fokus og ikke. Det vil si at det på noen bytter bakgrunnsfarge, mens på andre blir det en ramme, og andre blir det et understrek. For f. eks sjekkbokser o.l ville jeg kanskje heller vurdert å kun bruke fokus på selve komponenten, eller alternativt ha en ramme rundt hele, inkludert ledeteksten, slik som vist i eksempelet her. focus-mark.png (view on web)<https://github.com/digdir/designsystemet/assets/161617180/893dea3a-b9af-4519-b45a-3e3847921f0f> — Reply to this email directly, view it on GitHub<#1409 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASRPQKECHDLPGMUXVVLYZWTYV3XMBAVCNFSM6AAAAABCEZUGVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQG4YDAOBSGM>. You are receiving this because you commented.Message ID: ***@***.***>

[Febakke]

Note: Im only using checkbox as an example. We have not landed how the focus indicator should wrap around this component yet

Im thinking about giving up on the universal focus indicator and here is why. We started looking at this to support the same functionality as the one we have been using. (Gov.uk focus style) and this guide for styling accessible focus indicators by Sara Soueidan.

Having a universal focus indicator is a good idea. It should be able to handle all bakgroundcolors and you will no accidentally have an invisible focus indicator when you change a background without changing the focus indicator. You have two indicators in one, the problem is that one of them is better then the other one. Here are some examples using a dark border with a white shadow/offset:

NB: The offset in this example is only 2px. We could bring that up to 3px to make it a little fairer.

With our current focus indicator we had seen some issues on our primary button. Where the dark focus indicator was next to the button and with low contrast to the fill color of the button. The yellow outline has low contrast to the white background and the dark focus part blends a little into the button. Not the best. We were talking about making changes because of this. And by designing our universal focus indicator in a similar way I fear that we will have similar problems in dark mode. Illustrated in the examples above.

I think we would get a better focus indicator if we changed the outside border based on the background color. If we use tokens to change between dark and light background we could change token for the outside border and have a better indicator overall. It wont be as bulletproof, but it will be a better indicator and pretty safe.

[Camulos]

I think checkboxes and radios need to be considered with the label as part of the focusable area of the component, as the component can be triggered by activating the label and these components are probably among the smallest components.

One problem with this approach (above post) is that the focus-color is a color already used a lot in the same page, if all text is white and other components have light almost white graphics, a white focus seem to "blend in", rather than "highlight" as intended? But is still in a direction that might work with a few tweaks. (and user tests.)

[Febakke]

The checkboxes was only ment as an example to highlight the issue. I would like to look at the suggestion from @anderssonsaja and use the same focus indicator around the label. Perhaps one issue will be radiobuttons with descriptions. I will do some testing to see how it would look.

Edited this to make it sensible 🙈
Yes, I think we could use whatever color on the "offset" part, but it wont solve my problems with the current design as the yellow (if we choose that color on the offset)border would still have low contrast to the light border of the component in dark mode.

As i described above I think it would be better to always change the outer border ensuring that you have some space between the focus and the indicator.

I made a terrible example with our yellow highlight color. This dident work as well as i thought.

Then it might be better to just use the yellow color in those cases? If we decide on yellow as a highlight color.

Heres an example where we include label and checkbox within the focus indicator. Im also testing different colors instead of white.

[Febakke]

Update
We have continued to work on the focus indicator on all components. Some changes have been made.

• Instead of 3px border we sized it up to 4px.
  • Why? On small components the focus indicator became quite small. (Switch, checkbox and radio) With a wider borderwidth we get a chunkier look that I think will enhance the focusindicator.
• Offset 2 or 3px? We are considering stepping up the offset as well.
  • Why? On normal light colored backgrounds, 2px are enough to get a clear border around the component. But when we are testing it on typical dark mode scenarios we are noticing that light and dark pixels are rendered differently. With a dark background the offset is hard to see. It becomes a little clearer with 3px. The irradiation illusion might also be playing a role here.
• Use the same focusindicator across all components.
  • Why? We want the indicator to be consistent so its easy to follow around the interface. We also dont want to change the component itself. This could crash or alter the intended meaning behind states and add to the complexity around the WCAG guidelines we are trying to follow.
  • Link is the only component that has a different design when focused. A border would not work very well for links in textblocks. So we change the background color on links, but keep the underline so that it is still clear that it is a link.

You can play around with the focus here: Figma prototype
We will add a better prototype later where you actually can test with tabbing.

For a quick look, this is how it looks on almost all of our components

Work to be done

• Are the indicator on radio, check and switch good enough or should we wrap the label with the focusindicator
• Look into if we need a different color on the indicator that contrast more with the rest of the interface
  • One option is to change the main focus color, if we do this we have to be certain that it covers all backgroundcolors we use.
  • The other is to fill the offset with a different color. We would get some styling issues where some components will have 3 borders. The downside is that it might look weird or off.

[mimarz]

Specify if its needed to have a color token for the inside of the offset.

[mrosvik]

Discussion 08.04.24: Should inverted outline be only 3px instead of 4px?

[Febakke]

Small change. When components are close together it gets quite messy with a transparent offset. To make it cleaner we changed it too a white border between the component and the focus indicator.

[mimarz]

On hold until we fix new token changes #1727

[anderssonsaja]

Using the same focus indicator on the label as well makes the indicator even more clear and visible, so I would highly recommend that :) Fra: Lasse Febakke Straum ***@***.***> Dato: tirsdag, 5. mars 2024 kl. 15:58 Til: digdir/designsystemet ***@***.***> Kopi: Saja Andersson ***@***.***>, Mention ***@***.***> Emne: Re: [digdir/designsystemet] 2.4.13: Focus Appearance (WCAG 2.2) (Issue #1409) The checkboxes was only ment as an example to highlight the issue. I would like to look at the suggestion from @anderssonsaja<https://github.com/anderssonsaja> and use the same focus indicator around the label. Perhaps one issue will be radiobuttons with descriptions. I will do some testing to see how it would look. Yes, I think we could use whatever color on the "offset" part, but we cant use it wont solve my problems with the current design as the yellow/white part would still have low contrast to the light version of the component. Skjermbilde.2024-03-05.kl.15.57.05.png (view on web)<https://github.com/digdir/designsystemet/assets/33222679/a79921a5-9f33-46e6-add4-e30c556d0f28> — Reply to this email directly, view it on GitHub<#1409 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGRBKHGNG32BWCXVACKGPITYWXMSVAVCNFSM6AAAAABCEZUGVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZYHE3DINJYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrosvik]

The new Figma Community File V1 Release Candidate was published 28.05.24 with the new focus state. https://www.figma.com/design/vpM9dqqQPHqU6ogfKp5tlr/Designsystemet---Core-UI-Kit?m=auto&node-id=34967-5356&t=18PwfSbusUj0Uk4s-1

[Febakke]

For documentation purposes.
We scaled down our focusindicator from 4px to 3px. The reason it was 4px was to minimize some visuall bugs we had observed. But when implementing this we felt it went to close to other elements in components. We felt it was better to ignore the visuall bugs that sometimes occured (Might just be my screen or the browser used at that time) then for it to make some components less readable.

Screenshot of how it looks now:

[Febakke]

For checkbox, radio and switch the focusindicator will include label/description inside the indicator as show in the screenshot.

This will give it a larger area and more visablity than just around the input.

[anderssonsaja]

[like] Saja Andersson reacted to your message:

…

________________________________ From: Lasse Febakke Straum ***@***.***> Sent: Friday, June 7, 2024 10:38:38 AM To: digdir/designsystemet ***@***.***> Cc: Saja Andersson ***@***.***>; Mention ***@***.***> Subject: Re: [digdir/designsystemet] 2.4.13: Focus Appearance (WCAG 2.2) (Issue #1409) For checkbox, radio and switch the focusindicator will include label/description inside the indicator as show in the screenshot. This will give it a larger area and more visablity than just around the input. Skjermbilde.2024-06-07.kl.12.36.11.png (view on web)<https://github.com/digdir/designsystemet/assets/33222679/ca50a261-15d2-46a1-8ace-5eac2089ec08> — Reply to this email directly, view it on GitHub<#1409 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGRBKHF3XQL7YPQO6O5HTYDZGGES5AVCNFSM6AAAAABCEZUGVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJUGU3DSMZZGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>