Indicating focus to improve accessibility

Last month, I wrote about fixing common accessibility issues. That post seems to have resonated with people, so I have written up five more fixes you could do to your codebase today. Let's go!

I have tried to make these as hands-on as possible. For each, you'll find a description of what the issue problem, how fixing it helps end users and which team member can take the lead on it.

In my last post, the issues were what WebAIM described as the top 5 isuses in their WebAIM Million project. This time, I have looked into accessibility audit reports I wrote and combined that with what Deque wrote about coverage and the numbers that 200OK took from public data about common issues across the Dutch government websites (taken from the register of accessibility statements).

Missing focus states

If an element on a page is focusable, it needs a focus state. This goes for all interactive elements:

a (if the href attribute is present), audio (if the controls attribute is present), button, details, embed, iframe, img (if the usemap attribute is present), input (if the type attribute is not in the Hidden state), label, select, textarea, video (if the controls attribute is present)

(from: HTML, Interactive content)

It also goes for as well for divs or other elements that have click and keyboard events (but best use buttons in those cases while you're at it; see below).

For all of these, designers can come up with a focused state (ideally this is one thing, eg an outline, that is the same for all elements on the site, so that it's easy to spot when focus moves). Developers can remove any outline: nones from their stylesheets (if you must undo default outlines, because you're using some other CSS property for outlines, best use outline-color: transparent instead so that it doesn't break in High Contrast Mode).

Browsers can also ship with a feature that forces focus indication, some do. Users could also use user styles, though no website owner should expect they will, it requires CSS knowledge and a plugin in most browsers these days.

More: Indicating focus to improve accessibility

Missing captions and transcriptions

When you publish how-to videos, vlogs, podcasts, basically anything that has audio and/or video, the content should be available as text, too.

My friend Darice de Cuba has written about how to create podcasts transcripts. Part of this applies to video, too. Captions and transcripts are created for end users with disabilities. They also benefit users who are learning your language and users who want to catch your content but are in public without headphones. Transcripts and captions can even benefit your SEO strategy.

One of my own videos with captions turned on (It's the markup that matters on YouTube)

Writing out all recorded content isn't necessarily something you could do today as it can take a bit of time, especially if you have lots of content. I still felt I could include this common issue here, because most teams don't do this themselves and outsource the work to specialised agencies. These are costs you can budget for. If there is too much current content, you could consider starting with future or most popular content?

Project managers can make sure captioning and transcribing are part of any project that includes audio or video. Developers can ensure the CMS has fields for transcripts and captions. Designers can design the UI to allow for full transcript display. Social media managers can produce caption any videos for LinkedIn or Twitter.

Invalid HTML

There used to be a time when websites would proudly display a badge that showed the current page was composed of valid HTML. These badges have disappeared from most websites, but validation is still a sound accessibility strategy.

The HTML of web pages is parsed by lots of tools, like browsers and assistive technologies, if the HTML is invalid it can lead to unexpected bugs. Simon Pieters' Idiosyncrasies of the HTML parser is a great book about this, especially if you want a deep dive into what could possibly go wrong.

Since HTML5, error handling is specified as part of HTML, which should improve unexpected bugs due to invalid HTML, but there are still plenty of accessibility problems you can find by validating your HTML. Did you accidentally nest a <button> inside of a <a>? The validator will call it out and help you prevent the myriad of problems that could cause.

So… developers and test automation engineers can ensure HTML validation is included in tests.

More: validator.nu that allows inputting HTML by URL, file upload or pasting is (can run from command line per instructions in README)

Headings that don't describe their section

In HTML, headings (h1-h6 elements) exist in the context of a section, they are supposed to describe the content that follows them. When I say section, I don't mean specifically content in a <section> (or other “sectioning content”), I mean more generically content that forms a logical part of a page, regardless of which HTML element used.

Descriptive headings are useful, because some users access headings in a page as a table of contents. For example, your one page band website could have a “Discography”, “Tickets” and “Merchandise” headings. Your search application could have a filters section with a “Filters” heading. Some websites useheading tags (h1-h6) to mark up text that's “just” bigger or bolder, which will break the experience for people who navigate by headings, as it will add entries into their navigation that don't describe sections.

Content designers can ensure headings describe sections, and that things that don't describe sections aren't marked up as headings. developers can ensure that if there are headings in their front-end components, that they describe content and don't just exist for style reasons.

Can't do all things with just a keyboard

Accordions, tabs, ‘toggletip’ triggers… if your page or app has things that users can click on, they should also be usable with just a keyboard.

Fixing this issue is great for people who can only use a keyboard, and for users with numerous other devices that may or may not be keyboard like (there's some examples in How people with disabilities use the web).

Often, this issue occurs when clickable elements are divs with a click handler. Developers can make sure they use a button element whenever things can be clicked (or a if it navigates to somewhere). Yes, you need some CSS to change the styling to your liking, but this is do-able, it makes it easier for you to get all of the web platform's buttonness in one package and, most importantly, your users will thank you.

Wrapping up

So, that's five more common accessibility issue that you could fix in your codebase today. I hope this is helpful to some readers. Should you still have questions about any of these, please feel free to contact me on Twitter (@hdv) or via email.

Thanks to #accessibility in Fronteers Slack and Scott O'Hara for inspiration. Also, thanks to WCAG, which lists all five issues as success criteria.

Focus outlines are a great way to improve accessibility. They are traditionally set with the :focus pseudo class. That still works, but with :focus-visible we have a new way to only show focus styles when they make sense. How does that work?

The :focus-visible pseudo class has been in the works for over seven years and we recently got to a situation where it is now in stable versions of all modern browsers: Chrome/Edge (from 86), Safari (from 15.4) and Firefox (from 85).

What is focus-visible anyway?

The thing is, :focus-visible isn't a “indicate focus only to keyboard users” pseudo class, it is “indicate focus when the browser thinks it's right, based on some heuristics”.

“When it is right”, what does that even mean? Well, it has to do with when browsers decide to show their default outline. For example, most browsers show an outline when you press a button with a keyboard, but they don't when you click a button with a mouse. In other words, focus styles in browsers only show sometimes, in specific cases. The :focus-visible pseudo class is meant to match those cases.

This makes :focus-visible very different from :focus, which matches whatever the currently focused element is, regardless of whether it makes sense to highlight it or not. That's why you might see the styles you applied through :focus even if you click on something with a mouse, a behavior that could leave users confused and causes some developers to turn off highlights completely (but friends don't let friends do this, you would not do cursor: none either).

From CSS Selectors, Level 4, 9.4:

[:focus-visible allows] authors to change the appearance of the focus indicator without changing when a focus indicator appears.

So it lets you target the cases where browsers would normally apply focus styles, and, importantly, it excludes the cases where browsers don't paint their default outline, for instance when the user clicks on a thing with a mouse.

Consequently, browsers apply :focus-visible styles to more non-mouse cases than just keyboard users. Which cases are they?
There are lots of devices that are keyboard-like, as Eric Bailey explains in Focusing on focus styles:

Wands, sticks, switches, sip and puff devices, voice recognition, and eye tracking technology can all create input in a digital system. These devices will identify a content area and activate it. This is similar to how you can hit the tab key on a keyboard and the next cell in a spreadsheet will be highlighted, indicating that it has been moved to and is ready to be edited.

Some of these technologies present themselves as keyboards (like braille displays), they could fall under the focus-visible umbrella, others (like voice control) are more mouse-like and may not trigger these heuristics. Some assistive technologies also come with their own highlighting, like VoiceOver on iOS and the macOS Switch Control UI.

Pointers vs non-pointers

An example (non-normative) in the specification for :focus-visible suggests that :focus-visible should apply to interactions “via keyboard or some other non-pointing device”. This made me wonder what the exact difference is between a pointing device and a non-pointing device. The Pointer Events specification has some answers (thanks Bramus!).

Basically, there are input methods that can do mouse clicks and input methods that aren't really a mouse but can simulate mouse clicks, like touchscreens and pen input. Pointer Events tries to abstract all of those input methods into a new concept called “pointer”.

The definition of a pointer in that specification:

A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

I haven't found a definition for non-pointer devices, like keyboards, but my best bet at a description would be: non-pointing devices are devices that let you step between the different interactive parts of a user interface. Others also call it “sequential navigation”.

Examples of non-pointer or sequential navigation:

• TAB/shift + TAB or arrow keys when you use a keyboard
• gestures when using VoiceOver on iOS, you flick between the different elements
• item mode in switch control (see Milan Patel's switch control demo, item mode demo at 3:59, note switch control has a pointer mode too, which Milan mentions he finds easier)

For the sake of completeless, there is also the concept of “spatial navigation”. This is similar to sequential navigation, but you don't just go back and forward—you can go up and down too, like when you select something to watch on a streaming service on your TV.

Input methods differ and overlap

Even with this distinction between pointing devices and non-pointing devices, none of this is very binary. There are users who always use a keyboard or users who never do, but most people will be somewhere in between. They could be switching between a mouse and a keyboard in one browser session, or use devices that allow for multiple input methods. Someone could connect a bluetooth keyboard to until-then touch-only tablet. Switch Control in iOS has both a point mode and an item mode.

And even if you could detect every type of device, people are not the same. You likely have users who use a mouse, but still benefit from seeing what currently has focus: users with low vision and users with cognitive disabilities.

In a comment discussing focus-visible, Jonathan Avila shares how he switches between modalities:

I often switch between input modalities such as by clicking and dragging off a button to set focus somewhere then use the keyboard to navigate from there. I may click on a radio button and then use arrows to select other radio buttons. I will switch between touch, mouse, keyboard, and many other settings such as large text, screen reader, or zoom depending on the situation.

The cool thing about :focus-visible is that it allows browsers to be smart about when to show focus styles. Browsers won't just hop into visible focus mode when you press any key, it takes things like using command/control + key combos into account, as Alice Boxhall explains in a recent Igalia Chats episode. The heuristics develop over time, too.

Ok, so what now?

This post turned out a little longer than I intended, but what I've tried to capture is what I started with: that and why :focus-visible is more than a way to show focus styles just to keyboard users.

If you want to hear more about :focus-visible from people who worked on this, the aforementioned recent Igalia Chats episode with Brian Kardell, Alice Boxhall and Rob Dodson covers some of the history and evolution.

Thanks to Job van Achterberg, Roel Van Gils, Eric Eggert and Patrick H. Lauke for their feedback and input on earlier drafts.

Having focus styles for any interactive element is crucial on a website. Hidde de Vries:

Focus indicators make the difference between day and night for people who rely on them. […]

Focus outlines help users figure out where they are on a page. They show which form field is currently filled in, or which button is about to be pressed. People who use a mouse, might use their cursor for this, but not everyone uses a mouse. For instance, there are many keyboard users: a person with a baby on one arm, people with chronic diseases that prevent the use of a mouse, and of course… developers and other power users.

You don’t have to create your own :focus styles in CSS, although you can. By default, browsers apply their own styles to interactive elements. But if you don’t like that look, the temptation is to style your own. So if you do something like this, boom, we’ve got focus styles under our control:

button:focus {
  outline: 5px solid red;
}

(By the way, outline is a great friend to focus styles for reasons Manuel Matuzovic gets into.)

But by doing this, we’ve also done something else: we’ve made it so when you click (like with a mouse on a desktop computer, otherwise known as a fine pointer) those :focus styles apply to the element. This can be highly undesirable, leading to the CEO being all like why does the button change looks when I click it??? Fair enough, CEO, let’s fix it.

The trick is using :focus-visible which is relatively new but has pretty solid browser support. The whole point of it is applying focus styles that apply at all times an element takes focus, except when a fine pointer clicks it. Which is kinda perfect really. But if you’re nervous about going all-in on only using :focus-visible, a way to continue to use :focus styles too is to wrap them in an @supports block like:

@supports not selector(:focus-visible) {
    button:focus {
        
    }
}

Fortunately, the browser support for @supports and the selector() function is a bit better than :focus-visible, so this buys some additional browser support

.

Pen:

CodePen Embed Fallback

The post Tired of focus styles applying on mouse clicks? :focus-visible is the trick. appeared first on CodePen Blog.

Share this:

• Twitter
• Facebook
• LinkedIn
• Reddit
• Tumblr
• Pinterest
• More

• Print
• Pocket
• Telegram
• WhatsApp
• Skype

Related