惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Martin Fowler
Martin Fowler
L
LINUX DO - 最新话题
P
Proofpoint News Feed
Cyberwarzone
Cyberwarzone
Know Your Adversary
Know Your Adversary
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
L
Lohrmann on Cybersecurity
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Security Latest
Security Latest
T
The Exploit Database - CXSecurity.com
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
P
Privacy & Cybersecurity Law Blog
K
Kaspersky official blog
The Last Watchdog
The Last Watchdog
Webroot Blog
Webroot Blog
Scott Helme
Scott Helme
T
Threat Research - Cisco Blogs
C
Cyber Attacks, Cyber Crime and Cyber Security
WordPress大学
WordPress大学
L
LINUX DO - 热门话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - Franky
V
Visual Studio Blog
O
OpenAI News
AI
AI
Hacker News: Ask HN
Hacker News: Ask HN
V2EX - 技术
V2EX - 技术
GbyAI
GbyAI
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Simon Willison's Weblog
Simon Willison's Weblog
S
Schneier on Security
Spread Privacy
Spread Privacy
Y
Y Combinator Blog
I
InfoQ
H
Hackread – Cybersecurity News, Data Breaches, AI and More
T
Threatpost
C
Cybersecurity and Infrastructure Security Agency CISA
F
Fortinet All Blogs
C
CERT Recently Published Vulnerability Notes
T
The Blog of Author Tim Ferriss
C
Check Point Blog
Apple Machine Learning Research
Apple Machine Learning Research
有赞技术团队
有赞技术团队
人人都是产品经理
人人都是产品经理
N
News and Events Feed by Topic
Project Zero
Project Zero
小众软件
小众软件
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
B
Blog
G
Google Developers Blog

TetraLogical Blog

Designing for people with reading disabilities - TetraLogical Designing for people who are D/deaf - TetraLogical Designing accessible documents - TetraLogical Introduction to creating accessible documents - TetraLogical Inclusive user research: vulnerable people - TetraLogical Designing for people who are blind - TetraLogical Designing for people with low vision - TetraLogical Meet the team: Niamh Madden - TetraLogical Designing for people with anxiety - TetraLogical Designing for people with disabilities - TetraLogical Accessible building blocks for the web videos - TetraLogical Common accessibility misconceptions - TetraLogical Common misconceptions about testing accessibility - TetraLogical Common misconceptions about implementing accessibility - TetraLogical Common misconceptions about WCAG - TetraLogical Common misconceptions about disability - TetraLogical Meet the team: Grace Snow - TetraLogical Sustainable accessibility in complex organisations: strategic foundations - TetraLogical Sustainable accessibility in complex organisations: organisational realities - TetraLogical Sustainable accessibility in complex organisations: external factors - TetraLogical Common misconceptions about screen readers - TetraLogical Guide to the Inclusive Design Principles - TetraLogical Meet the team: Ian Lloyd - TetraLogical Annotating designs using common language - TetraLogical Meet the team: Catriona Morrison - TetraLogical Championing inclusive language - TetraLogical Press release: TetraLogical launches accessible self-led training courses to help digital teams build confidence in accessibility - TetraLogical Why inclusive products are green products - TetraLogical Accessible Recruitment - TetraLogical Accessibility and the agentic web - TetraLogical Meet the team: Craig Abbott - TetraLogical Foundations: types of assistive technology and adaptive strategies - TetraLogical European Accessibility Act (EAA) FAQ - TetraLogical Screen reader HTML support tables - TetraLogical Interview with Lola Odelola - TetraLogical Understanding EN 17161 Design for All - TetraLogical Inclusive user research: building rapport - TetraLogical Foundations: Keyboard accessibility - TetraLogical Can generative AI write contextual text descriptions? - TetraLogical Understanding the European Accessibility Act (EAA) - TetraLogical Meet Josh: a sportsman who has spinal muscular atrophy - TetraLogical Meet Jonathan: a photographer who has ADHD - TetraLogical Foundations: grouping forms with `<fieldset>` and `<legend>` - TetraLogical XR Accessibility: for people with moving disabilities - TetraLogical Meet Andre: a music producer and blind screen reader user - TetraLogical Foundations: types of disability - TetraLogical Meet Lauren: a film editor who has ADHD - TetraLogical Meet Steve: a photographer who is deaf and low vision - TetraLogical Foundations: form validation and error messages - TetraLogical Meet Hasmukh: a blind cricketer and screen reader user - TetraLogical XR Accessibility: for people with hearing disabilities - TetraLogical XR Accessibility: for people with thinking disabilities - TetraLogical XR Accessibility: for people with seeing disabilities - TetraLogical Introduction to XR Accessibility - TetraLogical Foundations: labelling text fields with input and label - TetraLogical Design patterns and WCAG - TetraLogical Does WCAG 2.2 apply to native apps - TetraLogical Why are my live regions not working? - TetraLogical Building a culture of accessibility - TetraLogical When to use tabindex= Accessibility foundations - TetraLogical Meet the team: Demelza Feltham - TetraLogical Can generative AI help write accessible code? - TetraLogical Meet the team: Steve Faulkner - TetraLogical Meet the team: Gez Lemon - TetraLogical Keyboard accessibility myths and WCAG - TetraLogical Amendment to the Public Sector Accessibility Regulations - TetraLogical What Considerations for TV user interface accessibility - TetraLogical Meet the team: Alistair Duggin - TetraLogical Sticky content: focus in view - TetraLogical The only accessibility specialist in the room - TetraLogical Meet the team: Ian Pouncey - TetraLogical Meet the team: Dean Holden - TetraLogical Meeting WCAG Level AAA - TetraLogical Foundations: accessible names and descriptions - TetraLogical Inclusive XR: accessible augmented reality experiences - TetraLogical Foundations: pointer gestures - TetraLogical Meet the team: Graeme Coleman - TetraLogical Adding sign language to videos - TetraLogical Foundations: introduction to WAI-ARIA - TetraLogical Meet the team: Joe Lamyman - TetraLogical Inclusive XR: accessible 3D experiences - TetraLogical Foundations: target sizes - TetraLogical Meet the team: Henny Swan - TetraLogical Meet the team: Ela Gorla - TetraLogical Foundations: native versus custom components - TetraLogical Foundations: HTML semantics - TetraLogical Accessibility and supporting Internet Explorer - TetraLogical Meet the team: Felicity Miners-Jones - TetraLogical Accessibility and QR codes - TetraLogical Inclusive user research: recruiting participants - TetraLogical Research insight: accessibility of images - TetraLogical Meet the team: Léonie Watson - TetraLogical Android accessibility: roles and TalkBack - TetraLogical Accessible design systems - TetraLogical Meet the team: Patrick H. Lauke - TetraLogical Inclusive user research: analysing findings - TetraLogical How to write user stories for accessibility - TetraLogical Triaging WCAG 2.1 Level AAA - TetraLogical
Foundations: visible focus styles - TetraLogical
2023-01-13 · via TetraLogical Blog

Posted on by Joe Lamyman in Design and development

Tags: Foundations, Code, WCAG

Visible focus styles help us to understand which part of a web page we're interacting with. You may have seen visible focus styles appear as an outline around a link or a button for example.

For people who only use a keyboard to navigate the web, visible focus styles may be one of the few ways to understand where they are in a page and what it is that they are interacting with.

Understanding visible focus styles

When browsing with a keyboard, you navigate between the focusable elements on the page using the Tab key. By default, web browsers (such as Chrome, Firefox, and Safari) will highlight focused elements.

Text containing a link with a blue underline and a blue focus outline indicator around it.
Default focus style in Chrome

You must make sure that focus styles are always included in your websites, as without them, a person using only a keyboard may not be able to understand where they are in a web page and may not be able to use the site. As browsers will automatically provide focus styles with sufficient contrast, you can use these, as long as they aren't suppressed. Alternatively, you may wish to use focus styles that better suit the rest of your website or application's identity, but this still needs to be clearly visible and have sufficient contrast.

Focus styles aren't just limited to links and buttons. Any control that receives focus and can be used with a keyboard must have a visible focus style. This includes custom components that your site may use.

Check focus styles haven't been suppressed

As mentioned earlier, web browsers will provide visible focus styles for interactive elements by default. A good place to start is by checking that focus styles have not been suppressed.

Any CSS that uses the :focus selector will make changes to the visible focus styles. Make sure that styles have not been suppressed without providing an alternative. The following code is an example of CSS code that will suppress focus styles:

a:focus {
  outline: none;
}

If focus styles have been suppressed, they must be replaced with an alternative that will still allow people to understand where they are in the page.

The TetraLogical home page with a custom outline around the Blog link and a filled-in circle following it, to make it clear which element has focus.
A custom focus style on the TetraLogical website

Designing usable focus styles

When designing visible focus styles, ensure they are consistently designed and accounted for on all interactive elements, so that wherever people are on your website, they can always clearly identify which element has focus.

If you have an accessible design system, you should document the focus styles. This will ensure that even when different parts of the website are managed by separate teams, the focus styles will be consistent.

It may be that a dark purple outline works for all elements across your website, or you may find that certain elements need slightly different styling to make the focus state more obvious. Styles should be consistent, but this doesn't mean that they have to be exactly the same. Depending on the context of use, changing the colour, to achieve greater contrast, or size of the focus style may improve the usability of the system.

The GOV.UK design system's focus state styles make focussed links have a yellow background and a black underline, while focussed text fields have a yellow outline and a thick black border. While these styles are not identical, they are consistent and easy to identify. This aligns with the Inclusive Design Principles' "Be consistent" principle, allowing people to build familiarity and understanding in the way that your website works.

A link on a white background with a yellow background and thick black underline alongside a text input with a thick black border and yellow outline focus styles
GOV.UK link and text input focus styles

Providing good contrast between custom focus styles and any adjacent background colours is important, as people need to be able to easily see focus indicators.

If your website uses lots of different colours, having a single colour for your visible focus state may not work; people may not always be able to see it. To resolve this, using two different coloured outlines can help to provide contrast.

Chrome, Edge, and Firefox all use default focus indicator that has an outer white outline and an inner blue outline. These different colours can provide contrast when the controls appear on different colour backgrounds.

A link on a white background with the inner blue focus indicator clearly visible followed by a link on a black background with the outer white focus indicator clearly visible
The double focus outline means the same focus state is visible on dark and light backgrounds

This technique of using two outlines works particularly well if the controls are placed on top of images with lots of different colours in them, or on top of dynamic content such as videos, where you cannot guarantee what the background colour will be. A great starting point that ensures contrast would be to have both a white and a black outline. If there is darker coloured content in the background, the white outline will provide sufficient contrast. If there is lighter coloured content in the background, the black outline will provide sufficient contrast.

A TetraLogical video of Léonie, with a button overlaid demonstrating a visible focus indicator with both a white and a black outline.

One way that this can be achieved is by applying a box-shadow attribute and applying two different coloured shadows to create the double border. The following code sample adds a white inner border and a black outer border.

*:focus {
  outline: none;
  box-shadow: 0 0 0 0.2em #fff, 0 0 0 0.4em #000;
}

Because this approach uses the box-shadow property, people who use Windows' high contrast, or other forced colour modes, will not be able to see the focus styles. This is because forced colours reset the box-shadow property, so the styles will be lost.

To resolve this, you can use a media query that will add in an outline for people using forced colour modes, ensuring that it works for as many people as possible.

*:focus {
  outline: none;
  box-shadow: 0 0 0 0.2em #fff, 0 0 0 0.4em #000;
}
@media (forced-colors: active) {
  *:focus {
    outline: 0.2em solid;
  }
}

Creating focus styles just for keyboard interactions

Using the :focus selector, the focus styles will be applied regardless of how people are interacting with content. If you use a mouse and click a button that has been styled using :focus, you'll see the styles take effect. This may be confusing for some people and may cause developers to suppress focus, as they don't see the need for focus styles when a user has already targeted the element either with a mouse or touch device.

The :focus-visible selector allows the browser to take into account a handful of different factors to decide whether to show focus, such as:

  • whether visible focus styles have been explicitly requested
  • whether a keyboard or non-touch device is being used
  • whether scripting has been used to focus on other elements

This means that when using the :focus-visible selector, a user using a mouse or touch device would not see the focus styles when selecting a button, as the browser has determined that it may not be helpful. This approach can be used to provide visible focus styles, when most helpful to the user, without distracting them when they are already selecting an element.

The following code sample uses the same double border approach discussed earlier, with the :focus-visible selector.

*:focus-visible {
  outline: none;
  box-shadow: 0 0 0 0.2em #fff, 0 0 0 0.4em #000;
}
@media (forced-colors: active) {
  *:focus-visible {
    outline: 0.2em solid;
  }
}

The only exception to this is that for any elements that support keyboard input, such as a text field using the <input> element, focus will be shown regardless.

Tips for visible focus styles

  • View the content in different conditions to make sure that the focus state is still easily visible
  • Keep the design of visible focus styles consistent across all interactive components
  • If your site contains different coloured backgrounds or dynamic content, use a double outline for the visible focus styles to ensure there is always sufficient contrast

More information

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.