Skip to content

Accessibility: WCAG-compliant focus indicators, and <dl> semantics

  • In WCAG 2.2, two success criteria were added to define how accessible a focus indicator is depending on both its color and area:

    Both of these new criteria aim to ensure that a keyboard focus indicator is clearly visible and discernible, and they provide the conditions to ensure that. These criteria specify the minimum area required for the focus indicator to be considered visible, taking into account its color contrast ratio—relative to its initial color as well as adjacent colors within the focused component. [...]

    2.4.12 is the AAA level of 2.4.11—it sets a higher bar and it builds upon it. It aims to ensure the focus indicator is highly visible by defining an even higher level of visibility requirements. [...]

  • [...] With these requirements in mind, we now know that Firefox’s current button focus indicator (that we saw earlier) fails the minimum contrasting area requirement. Chrome and Edge’s current focus indicators would fail the adjacent contrast requirement if your button has a background color that clashes with the outline’s color. And Safari’s focus indicator will also fail the minimum contrast ratio requirements also depending on the colors you use inside and outside the button.

    These browsers may also apply different focus indicators to different interactive elements, which may (and are likely to) also fail at least one of the accessibility requirements, depending on your color palette.

    So I highly recommend overriding the default focus indicators with custom, more accessible ones. This also gives you the creative freedom to design focus indicators that look nicer on your components than the ones provided by the browser. [...]

  • So theses are the four accessibility requirements for focus indicators to pass WCAG:

    1. There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states. This is the focus indicator’s contrasting area.
    2. The contrasting area needs to be at least as large as:
      • the area of a 1px thick perimeter of the component, or
      • the area of a 4px thick line along the shortest side of the component’s minimum bounding box (and no thinner than 2px)
    3. The contrasting area has a contrast ratio of at least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2px
    4. The item with focus is not entirely hidden or obscured by other content

    Both success criteria 2.4.11 and 2.4.12 measure color contrast, minimum area, adjacent contrast, and visibility. In relation to 2.4.11, 2.4.12 (Level AAA):

    • expands the minimum area to be at least double the area of a 1px thick perimeter (for example, a 2px thick outline),
    • increases the change of contrast in the contrasting area to 4.5:1, and
    • does not allow for any part of the element to be obscured by other content.
  • [...] When determining whether a semantic element might be appropriate for a given pattern, I find it helpful to ask, "What benefits — even theoretical — could we get if computers could recognize this pattern?" In this case, what lift could we get if browsers could somehow recognize a list of name–value groups?

    Answers to that question will be varied. I tend to spend a lot of time advocating for web accessibility, so my first thought tends to be how screenreaders could interpret the pattern. Off the top of my head, I can think of a couple of benefits screenreader users could get from their screenreaders recognizing this pattern:

    1. The screenreader could tell the user how many name–value groups are in the list.
    2. The screenreader could tell the user how far into the list they are.
    3. The screenreader could treat the list as one block that the user could skip over if they're uninterested in it.

    All of these could make the list more usable than a series of nested <div>s, which would treat each name and value in the list as nothing more than a standalone text node.

    If you can come up with a couple of even theoretical lifts from the user's device recognizing a pattern, then there's a good chance that the pattern is a strong candidate for having some associated semantics.

    For what it's worth, these screenreader experiences aren't hypothetical — they're benefits that screenreader users really get from using <dl> in most browser/screenreader combinations. Admittedly, however, support for the <dl> element is not yet universal. You may decide that screenreaders' fallback experience — treating the list as standalone text nodes — isn't sufficient for your use case, and instead opt for something like a <ul> until support improves.