2.4.11 Focus Appearance adds more complexity to WCAG than we should want

Like many people, I have been monitoring the creation of WCAG 2.2, the upcoming new version of the Web Content Accessibility Guidelines. Nine new Sucess Criteria are proposed. One particularly worries me: 2.4.11: Focus Appearance.

Focus Appearance builds on two existing WCAG criteria that affect focus indicators: that users can see which element has focus (2.4.7), and that focus styles have sufficient contrast (1.4.11). Focus indication is essential for a wide range of users, including users who browse by keyboard or zoom in. For an introduction to why focus indication matters, see my post on indicating focus.

What's new about 2.4.11 is adds more requirements for what the indicator looks like:

  • an element with focus needs to have sufficient contrast with its non-focused state
  • an element with focus needs to have sufficient contrast with its surroundings
  • the focus indicator needs to either be a solid line (so not dotted or dashed), or have a certain level or thickness (in which it can be dotted or dashed)

It's a clever new criterion, that addresses important user needs that were previously unaddressed. The Working Group clearly put a lot of research and thought into it. This is hard to do, as co-chair Alastair Campbell mentions in a GitHub issue:

what makes a visible focus indicator is not particularly straightforward

This is the crux of why this isn't trivial to solve and I appreciate everyone's efforts on the proposed Success Criterion. I know the text has had revisions and improvements after people have flagged complexity issues. Still, I'm sorry the Success Criterion as it stands now has me worried.

“Focus Appearance” is “at risk” of being removed from the final version of WCAG 2.2. My vote would be to drastically change it (again) or remove it entirely. Firstly, the requirements are complex to apply or teach. Secondly, browsers, OSes or assistive technologies could guarantee focus appearance better (and I feel it would be easier to talk to them than to convince all of the world's web developers).

Why I hesitate about including 2.4.11

Complex to apply

I expect Focus Appearance would be hard to apply, because the Success Criterion text has a lot of complexity. It is full of clauses and sub clauses. It often includes “and” (8 times), “or” (7 times) and “non”/“not” (4 times). There are two ways to meet it (you can choose one or both), and there are two exceptions and three notes. All in all, it's a lot to grasp.

The wording requires knowledge of a lot of specialised terminology, especially in the “area of the focus indicator” part. It may be that I am a non-native English speaker, but I had to look up what a “perimeter” is. The Oxford Dictionary of English states:

the continuous line forming the boundary of a closed geometrical figure

WCAG 2.2 makes this definition more specific to the web by defining “perimeter” as ”continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest”.

In this, “minimum bounding box” has its own definition:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie

And because it is about web content, another clause is added:

For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line.

This is a lot to take in and it seems easy to misunderstand. There are so many sub definitions needed. One could easily misinterpret the concepts of a bounding box, the perimeter,“shared pixels”, “CSS pixels” (ok, that's already used in Reflow and Target Size) and apply the whole SC wrongly.

This makes 2.4.11 Focus Appearance very different from other criteria, like Non-Text Content or Keyboard. Accessibility specialists will know there are indeed lots of ways not to meet those requirements, but the general idea of how to comply is easier to grasp. Very few people will need to look up what a keyboard or text is.

Admittedly, there are easy ways to comply with the proposed Focus Appearance, too. One is to have a solid outline with a minimal offset of 1px that has sufficient contrast (3 : 1) with its background, as James Edwards explains in New Success Criteria in WCAG 2.2.

Complex to teach

As someone who sometimes teaches WCAG to teams, I also worry about the complexity of 2.4.11. I could teach the ‘easy way’ described above, that doesn't seem too complex to teach. But if I would try to teach the whole Success Criterion with all the requirements, exceptions and notes and also cover what the Understanding document explains, I fear I won't get it across.

“But teaching is your job, Hidde!”, you might say. Yes. And I could probably make it work, but it would take class time that I would like to spend on other barriers, and there is still the risk the information sticks with participants less because of the complexity. There will also be people trying to apply this Success Criterion on their own.

Leave it to browsers

We can't just leave all of our problems to browsers to fix. But if I had any say in it, browsers should fix any accessibility problems they are able to fix. That way, end users have to rely less on individual web developers to make good choices. I feel focus indication is a great example of that: the browser knows what has focus, users want to know it, web developers could fail to add a good indicator. So why rely on web developers?

In a discussion on relying on browsers for focus indication, the Working Group concluded that browsers don't do sufficient default focus indication today, so if we want accessible websites, we need to require it through WCAG. If browsers start to do it later, the requirement could be removed or moved to a different level then. A chicken and egg situation, basically, but with one of them more likely to materialise (I'm not super sure which, to be honest).

A second argument is that web designers are in a better position to design an appropriate indicator, one that fits well with the rest of the site's design. But it's unlikely those designers can take into account user needs as well as a browser could with settings. Some users may prefer an indicator they can see move from one element to another, some may want a very high contrast indicator, some may want it more subtle (see also Rain's comment mentioning high visible focus indicator from a COGA perspective). A browser could provide options. We wouldn't want individual websites to start offering focus indication choosers, right?

Forced focus indication already exists in various forms through OS settings, assistive technologies (like VoiceOver) and even some (buried away) browser settings (in Chrome). There is a bunch of browser plugins and bookmarklets that force focus indication, too. So we've got forced visibility. Forced “good appearance”, however, is not fully in browsers and harder to implement, of course. It would need to account for all the things 2.4.11 requires, like sufficient contrast with surroundings (the browser/add-on/plugin would need to make it work with any background) and sufficient contrast with non-focused state.

I get the idea of putting this on developers before full browser support exists, but it does feel a bit like solving all problems with one (conformance-shaped) hammer. It also doesn't apply when developers simply don't meet WCAG. Yes, there are human rights, ethics and laws, but we know they are violated a lot today. I fear this will only be more common when the requirements are too complex.

How to make it less complex

I know WCAG 2.2 is close to its last standardisation stages, so I'm sorry to bring this up now. I also don't want to just say ‘don't include 2.4.11’. Let me describe a possible way to make the situation less complex for developers, evaluators and teachers, by replacing Focus Appearance with multiple Success Criteria:

  • Focus Distance to require a minimum offset between the focused element and its outline
  • Focus Solid to require solid, unless a minimum thickness is used

These two on their own seem a lot less complex to apply, test and teach. As minimum contrast and visibility are already covered in other Success Criteria, these two criteria between them would make focus indication much better for low vision users, while not adding the complexity 2.4.11 adds.


The proposed Focus Appearance criterion does a great job at capturing which problems end users have around focus into requirements. But it lacks understandability for users of the standard: people who make websites, people who evaluate accessibility conformance, developers of testing tools, et cetera.

It may seem reasonable to say those understandability concerns are secondary to the ability of end users to use the web. Of course they are. But if there is too much complexity in WCAG wording and mathematics, I worry the web won't actually get better for end users. We'll lose the people who need follow the recommendations. This is already an issue with current requirements, as shown by the many “WCAG in plain words” derivatives and checklists that exist. The original source gets plenty of “appropriate requirements love”, it could use content design love.

I'm sorry, but I feel WCAG 2.2 is better off without 2.4.11. Even after some iterations, it (still) adds more complexity than we should want WCAG to have. It's difficult to apply and teach. It may end up like Terms and Conditions: factually correct, but commonly skipped over. That would be problematic in this case, and mean not considering important end user needs.

My ideal resolution would be (I know, easier said than done): sit down with browser makers and improve the focus indication game structurally together. Meanwhile, people who make websites can prioritise the 86 other WCAG Sucess Criteria (rather than implementing 2.4.11 until browsers are ready). Focus indicators are a core need web users have, it needs better appearance and likely choice in appearance, let's bring the research from AGWG into (browser) practice.

My explanation of 2.4.11 was partially based on TPGi's post on WCAG 2. Thanks to Kitty Giraudel for the terms and conditions analogy.

Comments, likes & shares (83)

It does look quite complicated and might offer room for interpretation. And I already hear from other peers that they find the WCAG is confusing or complicated.
WCAG is too complex as it is, and this proposed SC takes that complexity to a whole new level. The @w3c either needs to scale this SC back or cut it entirely. I fear this one is complicated to the level folks will just ignore it completely.
For the first time I find that I must disagree. Yeah terminology is a little annoying but many other success criteria are not that easy to grasp at first. And I obviously find teaching it not that difficult sarasoueidan.com/blog/focus-ind… 😋
I think there’s some odd things in there — inputs with thick but not conformant color contrast borders— but overall I am very happy that it’s finally addressing the complexities of technical products. We have needed this for a long time.
Good point, there are definitely others that are tricky to understand. But none have this many clauses + maths… this SC requires both language/logic skills and geometry skills.
I'll refer others to your explanation, great job!
To be fair, they did remove many of the math terminology in the second version of the SC. I distinctly remember because I had to edit the article afterwards. Also i'm still very confused by some SC that NEED Understanding docs to be, well, understandable.
I mean your article is de-facto the understanding needed to understand this SC. And if you create focus styles it feels straight forward. But testing each and every link and button and making the calculation with its many permutations seems overly complex.
Most of the testing is pretty easy once you simplify the requirements. I doubt anyone will need to actually do any math to test that the indicators are conforming. 🤔 for most UI elements & components, the requirements are simple & will probably be easy to visually check
if I do a report I need to be confident when I write down a requirement is met, so would need to check all the clauses… but if the indicator is solid and offsetted, like many are, it would be trivial, I guess that's what you mean?
Yeah. Even if it's not offsetted, then what you need to check is that it's >2px with enough contrast. You'll probably rarely have to check for ALL points cz it's just contrast + area; area for most elements depends on width/thickness of the outline (>2px, or >4x if it's a line)
I’m with you on wanting it to be a browser responsibility. That would also allow people’s settings to follow them across many sites, same as high contrast or resizing text at the platform level.
My plan for teaching it (if it stays in, in current wording) is similar to what I do for 1.4.13 - step through the complexity, then show how you can usually avoid all that work by choosing a simple, robust solution instead of trying to find loopholes.
But auditing it is going to be more work. Most sites don’t have just one, consistent focus style so we’ll end up testing repeatedly. I’m not *too* worried about that, because usually enough of the styles fail that our recommendation is “please design & use a consistent focus” 🙂
It’s quite easy to bypass all that complexity though with simple outline style. If you use 1px solid, with outline-offset, check 3:1 contrast against the background, you pass.
yes, I saw that in your post, liked it so much that I quoted it in mine… but feel WCAG would be better if the amount of complexity people will want to bypass is minimised
The thing is that actively specifying a good focus is as easy as you say. The issue is when it comes to testing, and there it is super complicated. No idea how to resolve this. Of course, what Hidde proposes would be even better: * { focus-style: you-do-the-right-thing; }
I agree. 2.4.11 & also the older 1.4.11 non-text, are following some unsupportable or questionable concepts, and do not consider important aspects of contrast perception, such as spatial frequency. Some of the difficulties in developing 2.4.11 stem from this failure.
"[Complexity] is already an issue with current requirements, as shown by the many “WCAG in plain words” derivatives and checklists that exist." I found this line very poignant.
Creating a better system is great, in theory. But people need to actually follow that system. I fear that this sort of complexity will turn away well-meaning developers. It's counter-productive
あーこれは同意。WCAG 2.2 CR にある新 SC 2.4.11 (Focus Appearance)は、現実問題として、コンテンツ制作現場での解読、咀嚼が難しい気がする。> 2.4.11 Focus Appearance adds more complexity to WCAG than we should want | hidde.blog hidde.blog/focus-appearan…
I think 2.4.11 is not *that* complex, but applying it to an existing design system and colour palette can be quite challenging.
あとで読む👀:2.4.11 Focus Appearance adds more complexity to WCAG than we should want | hidde.blog hidde.blog/focus-appearan…
It's not just me finding the WCAG 2.2 criteria for focus states complicated! Positive upgrade but could do with a plain language rewrite #a11y hidde.blog/focus-appearan…
@hdv Meanwhile on Youtube