Trusting the browser

I’ve been thinking about how we approach accessibility in web development. Particularly about trusting the browser to implement things in an accessible way.

It’s a bit of a dilemma. Browsers get accessibility wrong quite often, but if you don’t know much about it yourself, your “fixes” might make things worse.

Losing trust

It feels absolutely amazing to use built-in HTML elements like <dialog>, <details> or useful features like display: contents. It’s also great how many, often invisible, features are included in the browser’s implementations of the basics of HTML and CSS to make them accessible.

Instead of building our own custom solutions and having to remember implementing things like keyboard navigation, landmarks, focus management or screen reader announcements ourselves, we can just lean back. Or can we?

Over the years, browsers shipped many features that were supposed to be accessible but ended up being not ^❶ .

Safari and dialogs

Safari currently implements the <dialog> element with a visible focus outline on the first element inside (often the close button).

Alternative text description of the video A Safari window, showing a white page with an “Open” button in the top left corner. A cursor hesitantly moves towards the button, clicking it. An unstyled dialog appears in the center, with a visible focus outline around the close button. Shocked, the cursor removes the outline by clicking besides it. The outline is gone. Clicking on the button, the dialog disappears. The cursor tries again. Surely the browser knows we’re navigating with a cursor now. Upon opening the dialog again, the focus outline is back. Thick and blue, the outline looks menacing. The user uses the tab and shift tab shortcuts on their keyboard to toggle the outline. Finally clicking besides the button again, and then closing the dialog. The cursor moves away, disappointed.

Now what’s so bad about it? Aren’t focus outlines a good thing? Yes, they are! They are fundamental to accessibility and I’ve written a long article about them.

The problem is that the outline is always visible, even when the user is navigating with a mouse. I’ve had many clients and designers report this issue to me. “What’s this border around the close button doing there?”.

Now you could solve this by slapping outline: none on the close button, removing the outline for everyone. Asking a LLM about it will give you exactly that (I’ve tried the latest Claude, ChatGPT, and Gemini models), not realising that this is a huge accessibility issue for keyboard users.

What makes this seemingly small detail so frustrating to me is the history of focus outlines in browsers and how we’re still dealing with the consequences of it.

Focus outlines on every click

For many years, browsers would show a visible focus outline whenever a user clicked on an interactive element. Not just when navigating with a keyboard but also when clicking with a mouse. In theory that’s ideal because you always know which element is focused, no matter how you navigate. You could switch back and forth between mouse and keyboard without losing track of it.

Alternative text description of the video There are two big, mostly unstyled buttons in the middle of a white page. Suddenly, a huge cursor appears, moving in from the top. After clicking on the first button, a black outline is drawn around it. Hastily clicking on the second button, the cursor makes the outline move to the second button. The user panics and uses the keyboard, as shown by a keyboard visualiser overlay. Moving the focus to the first button by pressing shift and tab, then moving it back and forth a few times, the anonymous user seems relieved to see the outline moving with the focus. Now the cursor starts to move again, clicking outside the buttons. The outline is gone. The cursor moves over the first button again. And they click. The outline is back, making the cursor flee in fear.

People hated it, so a lot of them removed these outlines altogether.

Why? Because they thought of the outlines as unnecessary. As a mouse user you don’t need to know where the focus is, right? Most didn’t understand anything about the why or how.

As WebAIM documented in 2008, this quickly became such a widespread problem they called it The plague of outline:0.

Removing them was a terrible idea, that’s for sure.

Who is to blame?

So we have the browser developers building something I would call an “accessibility-first” feature: focus outlines on every click. On the other side we have developers of websites, designers and their clients who don’t understand this decision and simply want the outline gone.

I started off as a designer, so I can understand both sides. While a missing outline surely has a bigger impact, an unexpected outline can also confuse users. An ideal solution would be to have a visible focus outline for keyboard users and no outline for mouse users.

15 years later: a solution

The solution, focus-visible, which makes a difference between keyboard and cursor navigation, took years to arrive in all browsers. Firefox was the first in 2011, followed by most others in 2020 and finally Safari took the longest and implemented it in 2022 according to Can I Use, almost 15 years after the “plague”.

Alternative text description of the video Once again, there are two big, mostly unstyled buttons in the middle of a white page. The huge cursor from before appears again, subtly shaking in fear. They click on the first button. No outline. Nothing. A puzzled cursor. They click on the second button. Still no outline. Clicking on the first button again, the cursor seemingly understands. Switching to the keyboard, the user presses tab and the second button gets a visible outline. Switching back and forth between the two buttons, the outline moves with the focus. After a final click on the first button, removing the visible focus outline, the cursor moves away, relieved. It probably continues to tell its cursor friends about this experience.

This behaviour is now the default in browsers. You can overwrite it by setting :focus (and I sometimes see that done on websites), but the default is to show a focus outline only for keyboard users.

I love the way they solved this. It’s accessible in an invisible kind of way. We did it!

Lasting impact

Unfortunately, the damage was done. I still regularly encounter websites with outlines hidden in their (reset) stylesheet, even though you don’t need to do that anymore.

Ask an LLM to style a button, and there’s a good chance it’ll still suggest outline: 0 or outline: none from the 15 years of training data.

button {
    border: none;
    background: none;
    font: inherit;
    color: inherit;
    cursor: pointer;
    outline: none; /* this was suggested by Copilot! */
}

An accessible web

Here’s the thing: everyone can build websites. That’s one of my favourite features of the web. It’s very accessible in this sense, as everyone has a voice here. You just need to write some HTML and some CSS.

But this kind of “accessibility” also means not everyone has the knowledge or skill to build perfectly accessible, barrier-free websites. For most developers, using flawed native browser features is probably better than building custom solutions without any accessibility knowledge at all. I’d even say we must trust the browser with how they implement features to a certain degree and we should not try to fix bugs that may be a feature.

Browser companies

The bigger issue is that we’re essentially at the mercy of a few massive companies. Recent browser benchmarks show Chrome with about 65% market share and Safari with around 20%, meaning these two companies control 85% of web browsing. As the political climate in the US changes, their business priorities don’t always align with accessibility needs. I mean, what is this Liquid Glass thing? I could write a whole article about this:

So what now?

Unfortunately I don’t have a solution. Browser vendors will keep making imperfect decisions. AI will keep suggesting ⁠to remove focus outlines. We won’t get a good browser company anytime soon.

This article has been in my drafts for a while now and the content and structure changed many times. I might have to remove some stuff again. It started off as a short rant about Safari’s <dialog> implementation.

While writing it, I stumbled over Hide de Vries’ talk at JSHeroes: Built-in accessibility: blessing or curse?. Among other things, he talks about our expectations as developers when it comes to built-in accessibility of browser features. That video prompted me to change quite a lot of things here, so you might want to watch it yourself, too.