Andy Barnes

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book


If you asked most grandparents how to deal with grandchildren, they would probably suggest letting them do whatever they want, and then filling them with sugar about 20 minutes before bedtime. Whilst as their child, you sit there thinking how unjust this is, since all they offered you as a child was vegetables and discipline.

In contrast, when looking at [**B**lock **E**lement **M**odifier](https://en.bem.info/methodology/) (BEM), the blocks treat their grandchildren (and deeper nested elements) in exactly the same way they treat their children.

## The problem

Easily the most common question I’m asked with BEM, is how to name deeply nested (2+ levels) elements in the blocks. So taking the example block below, once we get to the `<li>` and the `<a>` elements, how do we assign selectors to those?

```html
<nav class="navigation">
  <ul class="navigation__list">
    <li>
      <a href="">One</a>
    </li>
    <li>
      <a href="">two</a>
    </li>
    <li>
      <a href="">three</a>
    </li>
  </ul>
</nav>
```

## The wrong way

A common wrong approach to this, is to keep adding double underscores the deeper you go. Something like the following:

```html
<nav class="navigation">
  <ul class="navigation__list">
    <li class="navigation__list__item">
      <a class="navigation__list__item__link" href="">One</a>
    </li>
    <li class="navigation__list__item">
      <a class="navigation__list__item__link" href="">two</a>
    </li>
    <li class="navigation__list__item">
      <a class="navigation__list__item__link" href="">three</a>
    </li>
  </ul>
</nav>
```

BEM gets a lot of bad press for looking messy. I think you’ll agree that this approach chucks a fair bit of fuel on those flames! Things start to get messy quicker than usual with this approach, and readability drops significantly.

I want to be quickly identifying the block I’m in (**navigation**`__`list), and the element I’m looking at (navigation`__`**list**). This approach slows down identification and adds bloat to your code.

It’s also inflexible. Say we wanted to add a new element in the tree, you’d need to rewrite all its child selector names to accommodate for the new namespace.

## The right way

The common misconception - that we need to chain our element names like this - is probably born from how we would traditionally think about their relationships to the elements directly above them. However, to get on the right track we need to start making sure that our elements only ever have two underscores in them (`__`), and that the naming shouldn’t care about how deeply nested you are in a block.

Let’s take a look at what the navigation block will look like with the correct approach:

```html
<nav class="navigation">
  <ul class="navigation__list">
    <li class="navigation__item">
      <a class="navigation__link" href="">One</a>
    </li>
    <li class="navigation__item">
      <a class="navigation__link" href="">two</a>
    </li>
    <li class="navigation__item">
      <a class="navigation__link" href="">three</a>
    </li>
  </ul>
</nav>
```

This immediately cleans things up, and it becomes a lot easier to identify what the elements are. A couple of benefits from this approach:

- You can move elements around within the block, assuming it keeps it semantic.
- You start consistently naming things, which speeds up implementation. And this becomes powerful when working in a team.

## Duplicated element types

If you code long enough, at some point you will run into a situation where you will have common elements that you want to style differently. So if your block has two `<ul>` in, how do you differentiate them?

Ideally, there will be some sort of unique factor that you could use to add to one of the elements. So in the example below, we are treating the second list as a “secondary” list. Which allows us to prefix the element name with the word "secondary" and then cascade that through the child elements.

```html
<div class="navigation">
  <ul class="navigation__list">
    <li class="navigation__item">
      <a class="navigation__link" href="">One</a>
    </li>
    <li class="navigation__item">
      <a class="navigation__link" href="">two</a>
    </li>
    <li class="navigation__item">
      <a class="navigation__link" href="">three</a>
    </li>
  </ul>
  <ul class="navigation__secondary-list">
    <li class="navigation__secondary-item">
      <a class="navigation__secondary-link" href="">A</a>
    </li>
    <li class="navigation__secondary-item">
      <a class="navigation__secondary-link" href="">B</a>
    </li>
    <li class="navigation__secondary-item">
      <a class="navigation__secondary-link" href="">C</a>
    </li>
  </ul>
</div>
```

At some point, you will need to determine whether it actually makes sense to split deeply nested elements out in to their own blocks. This very much depends on context and whether it will be reused. And as such, means that there’s no blanket rule to go by.

## Summary

When creating your blocks, always avoid chaining your selector names, and stick to a flat structure.

- Good: `nav__link`
- Bad: `nav__list__item__link`

Your future self will thank you!



If you asked most grandparents how to deal with grandchildren, they would probably suggest letting them do whatever they want,

BEM CSS Tip: Dealing with grandchild elements


_Before we start, I’d like to apologise in advance… I’m based in the UK, so the the flipping between colour/color in this article is real!_

When asking if something is accessible, common feedback will be around contrast ratios. This article aims to outline what contrast ratios are - in context to accessibility, what the requirements are, and how you can check you are meeting those requirements.

## What is WCAG

Get ready for some acronyms! The **Web Content Accessibility Guidelines** (WCAG) are a set of accessibility guidelines, published by the [**Web Accessibility Initiative**](https://en.wikipedia.org/wiki/Web_Accessibility_Initiative) (WAI). [**The World Wide Web Consortium**](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium) (W3C) launched the WAI in 1997, with a goal to improve the accessibility of the web to users with disabilities.

The actual WCAG technical documents are created by the [**Accessibility Guidelines Working Group**](https://www.w3.org/WAI/GL/) (AG WG), which are part of the WAI.

![Photo by Nathan Dumlao on Unsplash](/posts/wcag-colour1.jpg)

## A, AA and, AAA

The WCAG requirements come in three levels; A, AA and, AAA. To be clear, these are levels of conformance to accessibility, not battery sizes.

The higher levels encompass lower ones. So to meet a conformity level of AA, you’ll need to have met all the level A and level AA success criteria.

- Level A is the minimum set of conformance.
- Level AA is generally the level that most sites are aiming to meet. It can often be a level that is a legal requirement.
- Level AAA is the strictest level, and can introduce significant design challenges given the nature of the success criteria. It is considered the gold standard level of accessibility.

## What is contrast ratio

It’s probably worth giving a brief outline of what contrast ratio actually means.

The WCAG contrast measure essentially measures the difference in brightness (luminance) between two colours. It ranges from 1:1 (white on white) to 21:1 (black on white).

Comparing different colours, will provide mixed results. For accessibility in isolation, the higher the left hand number the better.

## Contrast criteria

WCAG has three main requirements that are related to contrast. It’s worth noting that incidental elements (which we’ll look at below) and logos have no contrast requirements.

- [1.4.3 Contrast (Minimum)](https://www.w3.org/TR/WCAG21/#contrast-minimum)
- [1.4.6 Contrast (Enhanced)](https://www.w3.org/TR/WCAG21/#contrast-enhanced)
- [1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG21/#non-text-contrast)

Contrast is also called out in the following requirement, when differentiating links in text by colour alone.

- [1.4.1: Use of Color](https://www.w3.org/TR/WCAG21/#use-of-color)

We’ll look at each one individually:

### 1.4.3 Contrast (Minimum) — Level AA

This is the classic contrast check that most developers hold themselves accountable to.

The main [success criterion](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) is as follows:

> The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
>
> **Large Text**: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

The large text part is interesting. 14pt and 18pt are equivalent to approximately 18.5px and 24px. So large text is generically defined as 18.5px bold text or larger, or 24px or larger regular weight text. Your fonts may vary!

**Examples of colour combinations for 1.4.3 Contrast (Minimum)**
![Three boxes giving examples of 1.4.3 Contrast (Minimum)](/posts/wcag-colour2.png)

Large text can have a lower contrast ratio, since it is already easier to read. From the image above, you can see a basic example of what that means in reality, a failing ratio for normal text, passes at the larger size.

### 1.4.6 Contrast (Enhanced) — Level AAA

To get the triple A badge of honour, you’ll need to go one step further.

The main [success criterion](https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html) of 1.4.6 is as follows:

> The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:
>
> **Large Text**: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;

This essentially just means to get to level AAA, the bar is set higher.

**Examples of combinations for 1.4.6 Contrast (Enhanced)**
![Three boxes giving examples of 1.4.6 Contrast (Enhanced)](/posts/wcag-colour3.png)

The enhanced contrast requirement can cause headaches for designers, when trying to balance aesthetics with belts and braces accessibility. As scary as this seems, it shouldn’t be totally disregarded. Where possible, level AAA should be targeted. If it feels too much of a compromise, one option is to have a high contrast mode that can be enabled.

**Microsoft Teams theme selection**
![Microsoft Teams three themes: Default, Dark, and High Contrast](/posts/wcag-colour4.png)

### 1.4.11 Non-text Contrast — Level AA

Non-text contrast is looking at other parts of the meaningful user interface. Things like icons, graphs, and controls. It looks at the contrast ratio with the component vs its adjacent colours.

The main [success criterion](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) of 1.4.6 is as follows:

> The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
>
> **User Interface Components:** 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;
>
> **Graphical Objects:** Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

The contrast ratio is lower in general for non-text. Set at 3:1.

**Examples of colour combinations for 1.4.11 Non-text Contrast**
![Two examples showing non-text contrast](/posts/wcag-colour5.png)

### 1.4.1 Use of Color — Level A

I think if you ask someone if a design is accessible or not, generally the first thing that will be called out, is to avoid using colour to differentiate visual elements.

> Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
> [WCAG guidance](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html)

Interestingly (probably not interestingly), there is sub guidance around [acceptable contrast levels to differentiate links in text](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G183) if using colour alone. It’s called out as being 3:1, and they provide some good [examples of this in action](https://www.w3.org/WAI/WCAG20/Techniques/working-examples/G183/link-contrast.html). Sadly, and awkwardly, [my own website](https://github.com/andrewbarnesweb/andrew-barnes-portfolio/issues/40) is falling foul of this.

Meeting this criteria can become a real balancing act, to get the contrast level right between the text and links, whilst also making sure they both have enough contrast with their background. It is still best practice - and recommended - to use underlines when using links in text.

![Examples of links being differentiated only by colour, and by colour and an underline](/posts/wcag-colour6.png)

## Incidental content

Two of the requirements (1.4.3 and 1.4.6) mention that incidental content is out of scope. Incidental is called out as the following:

> Text or images of text that are part of an [inactive user interface component](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast7.html#user-interface-componentdef), that are [pure decoration](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast7.html#puredecdef), that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

In my experience this can be open to a lot of differing of opinions. A good example is a disabled submit button.

![Disabled submit button with very low contrast](/posts/wcag-colour7.png)

Users with no visual impairments will be able to see the button is there, and immediately benefit from knowing that they need to do something to enable that button. Users with visual impairments will not.

You can certainly argue that the rest of the UI should be doing the work to highlight to the user with visual impairments that there is work to be done. Bringing the contrast levels up on inactive content will also soon get troublesome. With how you’d do that, while still getting the message across that it’s inactive.

## Checking contrast ratio

Thankfully, there are a number of ways you can check contrast, whether it’s manually checking individual colours, whole pages, or in a development pipeline.

### Manual contrast ratio checking

There are a number (great number) of websites online that allow you to punch in two numbers and get some WCAG AA/AAA results out.

- [https://color.review/](https://color.review/): As well as highlighting the passes and fails, shows an example page with content in to get an idea on how well the colours work together.
- [https://colourcontrast.cc/](https://color.review/): Allows you to try out different fonts, quickly save combinations, and includes Back to the Future quotes. What’s not to like?
- [https://webaim.org/resources/linkcontrastchecker/](https://webaim.org/resources/linkcontrastchecker/): Useful for when you’re being stubborn, and refuse to underline your links!

### Manual page contrast ratio checking

Sometimes the ship has already left the harbour. Or you want to check all the colours in context of their usage in a full page. There are a number of browser plugins and tools that can be used to achieve this. These tools check more than just contrast ratios, so they really do add value when checking pages.

- [Lighthouse](https://developers.google.com/web/tools/lighthouse): Perhaps the most well known check, Google’s own open-source tool can be run in developer tools (right click -> Inspect -> etc). Running the accessibility segment will give you any errors it can detect, and highlight those in the page.
  ![Lighthouse report](/posts/wcag-colour8.png)
- [WAVE](https://wave.webaim.org/extension/): This browser plugin does a similar thing to Lighthouse. It will immediately highlight any contrast ratio errors it discovers (to AA level).
  ![WAVE report](/posts/wcag-colour9.png)

### Continuous integration (CI) checks

When developing, it is always a good bet to be constantly checking for violations. Manual checks will only catch so much. Often a change will be made to one file, that impacts a number of files.

At this stage, we really want to be checking the whole application/website before we merge the changes and push it live, this is where CI checks come in. As with the manual page checks above, these tools check for more than just contrast ratios.

- [Pa11y CI](https://github.com/pa11y/pa11y-ci): Pa11y publishes a number of free and open source tools to check for accessibility. Pa11y CI is great to run against a sitemap and highlight any non conformances. If it finds any contrast issues, it will even suggest a colour to use that will pass the checks.
- [Axe and Cypress](https://www.npmjs.com/package/cypress-axe): If you are using Cypress to run end to end tests, it makes sense to add cypress-axe. This allows you run accessibility checks given certain scenarios - like expanding a section on the page - and not just on initial load.
  ![cypress-axe report](/posts/wcag-colour10.png)

## Summary

Given the hard rules for meeting the WCAG contrast ratio requirements, it’s easy to test against, from the initial design phase, right through to the development pipeline.

Although there are few nuances when you get right into the details, contrast ratio is something that is relatively easy to manage and can be at the forefront of your mind throughout the whole design and development cycle.



Before we start, I’d like to apologise in advance… I’m based in the UK, so the the flipping between colour/color

WCAG: Accessible colour and contrast ratios


Have you ever got back from IKEA, full of anticipation and excitement at the thought of constructing a cupboard yourself? Only to be left questioning your life choices two hours later, when you realise you’ve put two of the panels on upside down.

This can be a similar experience when application designs are handed over to developers. Often a sizeable amount of guesswork goes into translating design documents into code. Enter design tokens. They’ll do absolutely nothing to help your wonky cupboard doors, but can greatly help designers and developers create consistent user interfaces.

It wasn’t that long ago that services like [InVision’s Inspect](https://www.invisionapp.com/feature/inspect/) and [Zeplin](https://zeplin.io/) started to make the design to developer handover a thing that could be taken seriously. These solutions provide a well needed bridge between design and development, doing away with the painful concept of manual [redlining](https://www.uxbeginner.com/glossary/redlining/). It still often leaves a lot open to interpretation. Design tokens hope to help with this interpretation, and get everyone talking in the same language.

## What are design tokens?

At their core, design tokens are tiny bits of styling information that are tech agnostic. They are design decisions, translated into design variables that are made available in different coding languages.

The tokens are things like colours, sizes, spacing — which on their own might be fairly meaningless — but used together and with some guidelines, can enable developers to create applications that are fully consistent with the design system.

The tokens also live in one place, which is where it starts to get really powerful. If the CEO suddenly has a change of heart, and wants to change the brand’s primary colour from blue to purple (that would never happen, right?), the colour can be updated centrally, and every consumer will get the updated token in their application.

## Benefits

- **Avoids code duplication**: As with anything in code, when you can avoid repeating yourself, you should. Duplication is error prone. Not to mention, when you have multiple teams implementing similar but different solutions to the same problems, it becomes even more costly to the business. Having the default text colour defined in one place is the best option, and indeed, the safest option.
- **Free updates**: As mentioned above, when design decisions are made, and tokens might be tweaked. For the large part, consumers can get those updates for free. If the large font size is increased by 2px, the variable name doesn’t change, and the design system remains in tact, with very little work.
- **Common language**: The more the tokens are used, the more familiar everyone will be when referencing them. So when a designer suggests changing a button to color-palette-secondary, the developers will know exactly what they mean. Historically, this would have probably ended with the developer asking for the hex value 😬.
- **Tech agnostic**: What happens when you want to move from SASS to CSS in JS? You’ve abstracted much of the fundamentals and it’s easier to migrate.
- **Design/UX ownership**: Historically there would be a large onus on a development team to implement a design system into their stack. Using design tokens gives more of that responsibility to the design team.

## How to create design tokens

_Depending on the tool set you are using, your mileage may vary. For this example, we’ll be looking at [Adobe XD](https://www.adobe.com/products/xd.html) and [Style Dictionary](https://amzn.github.io/style-dictionary/)._

The workflow will look something like this, and we’ll go into slightly more detail below.

![Image representing XD colours moving through Style Dictionary as JSON and then being used in a web application](/posts/tokens1.png)

### Adobe XD

Behind every token, there is a design decision. Once these decisions start to be made, they can be validated alongside the rest of the design system to make sure everything still looks and feels right. [Adobe XD announced this week, that it now supports design tokens (CSS Variables)](https://www.youtube.com/watch?v=-ifl1tl-SuE). This means that designers can start to label up certain things like colours with the same names that the developers will be using.

![Adobe XD showing its inspector, including colour token name](/posts/tokens2.png)

Once the tokens have been validated they can start to be created.

### Style Dictionary

One of the core selling points of design tokens, is the fact that they are tech agnostic. This means that the tokens are written in a generic language (JSON in this instance) that allows it to be translated into the right formats for consumers. We want to avoid just coding the tokens straight into SASS.

Style Dictionary allows just this, and it also has a really deep level of configuration to get the tokens doing exactly what you want.

The tokens are authored in the format below:

```json
{
  "color": {
    "palette": {
      "primary": {
        "value": "#bd10e0"
      },
      "secondary": {
        "value": "#00c9c1"
      }
    },
    "text": {
      "heading": {
        "value": "#ffffff"
      }
    }
  }
}
```

Once built, Style Dictionary will provide the variables in files that can be used by consumers.

**Example of the SASS variables that are generated**:

```sass
$color-palette-primary: #bd10e0;
$color-palette-secondary: #00c9c1;
$color-text-heading: #ffffff;
```

**Example of the Swift variables that are generated**:

```swift
public enum StyleDictionaryColor {
  public static let palettePrimary = UIColor(red: 0.741, green: 0.063, blue: 0.878, alpha:1)
  public static let paletteSecondary = UIColor(red: 0.000, green: 0.788, blue: 0.757, alpha:1)
  public static let textHeading = UIColor(red: 1.000, green: 1.000, blue: 1.000, alpha:1)
}
```

These outputs can then be bundled into an NPM package, which will allow you to do meaningful releases with release notes. This means that if a design decision is made to remove a token, then it can be called out in the release notes. It then won’t be a shock to consumers when they need to make changes to their code.

## The future

Allowing designers to manage the design tokens, ensures consistency right from the start. It puts the right people in control of what they specialise in. That being said, it’s still not a seamless experience for designers to actually use the tokens in their own workflows.

The concept of design tokens has been around for a few years now, and it’s slowly becoming common place. Hopefully, with increased usage, the features will start to improve with design tools like Sketch, Adobe XD and Figma, and designers will be able to consume their own tokens in a native and fully featured way.



Have you ever got back from IKEA, full of anticipation and excitement at the thought of constructing a cupboard yourself?

Design Tokens: An Introduction


Stuff that keeps me awake at night: my phone, my batting average in 2004, and worrying about accessibility. What if I’ve built a component that not everyone can use? We now all know that accessibility isn’t just a nice to have.

I wanted to go over my current approach for accessible focus indicators, and the journey I took to get there.

## Leaving it up to the browser

Do we even need to bother, or should we just leave the browsers to it?

So the [official line](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast) is that if you leave the browsers to it and don’t change the default focus indicators in any way, then you are being compliant.

> Where the focus style of the user-agent is not adjusted on interactive controls (such as links, form fields or buttons), the default focus style is sufficient.

The reality is that some browsers just don’t to do a good enough job for this to be relied upon. Take Safari for example. This is their focus indicator for text inputs, which is not even close to the specified 3:1 non text contrast guideline.

![Two inputs styled like Safari, one without focus and one with focus. Demonstrating that it is not accessible against 3:1 contrast guideline](/posts/accessible-focus1.png)

Other browsers do better, but they all have their own versions, with their own quirks, and it’s just not consistent. So you can never be sure that the browser defaults will compliment your design or indeed be accessible for your users.

## Cutting our own

So, if we don’t trust the browsers, what options do we have? Other than committing the biggest accessibility sin this side of using tables for layout - by adding `outline: none` and going home - we are left with one option: Doing it ourselves!

Whilst a daunting prospect, it does mean that we control our own destiny and can work on getting the focus indicators to compliment our design and not fight against it.

## W3C Guidance

Before we look at solutions, what do our friends over at the World Wide Web Consortium say on the matter?

> ...the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, except where the appearance of the component is determined by the user agent and not modified by the author.
>
> If the focus indicator is styled by the author, it must meet the 3:1 contrast ratio.
> This for me is where a lot of confusion seems to be introduced. W3C specify that the contrast should be against the background.

If we take a look at GOV.UK’s implementation (my usual go-to for great examples of accessible components). The yellow focus indicator has great contrast with the border of the text input, but nowhere near 3:1 against the background.

![Example of GOV.UK's input focus, showing that it partially passes the W3C guidance](/posts/accessible-focus2.png "GOV.UK Design System")

On the examples on W3C’s own page, it’s the other way around. The blue focus indicator is nowhere near a 3:1 contrast ratio with the input’s border. Whereas the ratio against the background is compliant.

![Demo of the non-text contrast example in the W3C guidelines](/posts/accessible-focus3.png)

The W3C stance feels clear to me; the focus indicator should be contrast compliant against the background, but not so much with the border itself.

Both solutions feel half hearted. If it’s important for 3:1 contrast ratios to determine different states, then it feels like we’d need some sort of mythical acceptable contrast for the focus indicator against both the input border and the background.

- With the W3C example, it seems to be just relying on the fact that the border, plus the focus indicator, has a bigger footprint.
- With the GOV.UK example, where do you stop if the focus indicator doesn’t have enough contrast with the background? You could edge further towards white and have incredible contrast against the input border, but it’d be essentially invisible!

## Outline vs Box-shadow

There are a couple of CSS properties to help us out with custom styling:

- **Outline**: This property is as it sounds. Adding an outline to an element. It is drawn outside the elements border, isn’t included in the element’s width, and can overlap other elements. The well known caveat with using `outline` is that if your element has `border-radius` then the outline will still have squared corners, which is less than ideal.
- **Box-shadow**: The `box-shadow` property is the cool kid on the block, everyone uses it. It gives you more styling options, and the major benefit is unlike `outline` if you have border radius on your elements, then `box-shadow` will hug the corners! Do be aware though that using this property has [accessibility issues](https://accessabilly.com/accessibility-issues-concerning-windows-high-contrast-mode/) with Windows High Contrast mode.

![Demonstrating outline vs box-shadow. Showing that outline does not hug rounded corners, whilst the box shadow does](/posts/accessible-focus4.png)

Again, the focus indicator colours above are contract accessible against the border colour, but not against the background colour.

## What if we offset the focus indicator?

So onto `outline`'s secret weapon, the ability to offset the outline. If we add some white space between the borders and the focus indicator, we can then just focus (pun intended) on the contrast ratio against the background.

It’s a double edged sword. You can more easily compliment your styles, because you have more control over using a colour that only needs to be accessible against its background. However, it does mean that you really need squared off elements. I believe that the benefits outweigh the negatives here, but obviously it’s something you need to consider.

![Two inputs demonstrating that outline offset gives some clarity to exactly where the focus is](/posts/accessible-focus5.png)

The above is an accessible focus indicator that meets the 3:1 contrast ratio requirements, whilst also not suffering the affliction of merging into the border.

**It’s worth noting that `outline-offset` is not supported in IE11. Internet Explorer, every web developer’s best friend. There are [workarounds](https://stackoverflow.com/questions/25624934/outline-offset-substitute-on-ie).**

## Summary

I’ve never been satisfied by most approaches to focus indicators, especially given the W3C guidelines. They either blend into the border, or don’t have enough contrast with the background.

Offsetting the indicator allows us have the best of both worlds, albeit with some considerations around browser support and border radius.


WCAG: Accessible colour and contrast ratios

Design Tokens: An Introduction

Accessible custom focus indicators