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

推荐订阅源

大猫的无限游戏
大猫的无限游戏
K
Kaspersky official blog
Apple Machine Learning Research
Apple Machine Learning Research
B
Blog
aimingoo的专栏
aimingoo的专栏
M
MIT News - Artificial intelligence
小众软件
小众软件
云风的 BLOG
云风的 BLOG
腾讯CDC
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Hugging Face - Blog
Hugging Face - Blog
S
SegmentFault 最新的问题
Stack Overflow Blog
Stack Overflow Blog
量子位
S
Secure Thoughts
G
GRAHAM CLULEY
C
CXSECURITY Database RSS Feed - CXSecurity.com
人人都是产品经理
人人都是产品经理
雷峰网
雷峰网
T
Threat Research - Cisco Blogs
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Cisco Talos Blog
Cisco Talos Blog
G
Google Developers Blog
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
有赞技术团队
有赞技术团队
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Martin Fowler
Martin Fowler
The GitHub Blog
The GitHub Blog
Google DeepMind News
Google DeepMind News
C
Cisco Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
博客园 - 聂微东
宝玉的分享
宝玉的分享
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
Netflix TechBlog - Medium
Forbes - Security
Forbes - Security
Engineering at Meta
Engineering at Meta
S
Security Affairs
Help Net Security
Help Net Security
博客园 - 三生石上(FineUI控件)
AWS News Blog
AWS News Blog
博客园 - 叶小钗
Recent Commits to openclaw:main
Recent Commits to openclaw:main
V2EX - 技术
V2EX - 技术
Hacker News: Ask HN
Hacker News: Ask HN
Project Zero
Project Zero
H
Heimdal Security Blog
W
WeLiveSecurity
C
Check Point 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: visible focus styles - 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: target sizes - TetraLogical
2022-12-20 · via TetraLogical Blog

Posted on by Joe Lamyman in Design and development

Tags: Foundations, WCAG

A target size is the area that can be activated in order to interact with an element. For people who have dexterity issues, the smaller a target size is, the more difficult it may be to use the website.

This post explores how to create usable, consistent, and well-spaced target sizes.

A person's ability to click or tap smaller controls may also be affected if they have a disability or a combination of disabilities that affect their dexterity and motor movements, or if they are moving while using a website, be it while walking or using transport.

There are many ways that people may interact with a device in order to operate it.

Beyond using a mouse, people may use alternative pointing devices such as a large trackball mouse, joystick, and eye or head pointer software that uses a camera to detect specific movements. These alternative devices all benefit people with different disabilities like arthritis, cerebral palsy, and tremors, for which the design of a typical mouse may be difficult to use.

It's also not only smartphones with touch screens that people may interact with by touch. Tablet devices, laptops, and monitors can all offer touch interactions, or the use of a stylus which works similarly.

A hand overlaid on top of a list of links, with the fingertip tapping a link which has an outline showing the target area

It's not possible to determine or predict exactly how a person may interact with the designs that we create. The way that a person uses a design may change throughout their usage. Recent additions to the web mean that we can try to detect how people may be interacting with their devices. However, assumptions about interaction methods can be problematic, as they may not be accurate and changes to the sites design made on incorrect assumptions can lead to a worse user experience.

The best solution is to create large and well-spaced target sizes so that people can easily click or tap the control they want and have a better experience regardless of how they use their devices.

A black and white photo of Steve, an older white man with thick white hair. He is standing facing into the camera while he holds his book or poetry and photos open in front of him
Steve would like to see better use of colour contrast and bigger font sizes in menus.

Creating usable target sizes

In the Web Content Accessibility Guidelines 2.1, the only requirement for target sizes and spacing is 2.5.5: Target Size, which is for AAA compliance. The guideline requires that a target size is no smaller than 44 pixels by 44 pixels. This success criterion applies to all pointer inputs, such as mouse, stylus, and touch.

Both Apple's design guidelines and Google's material design guidelines have similar recommendations. Apple's layout guidance recommends that components "maintain a minimum tappable area of 44×44 points for all controls". Material design recommends that target sizes are at least 48dp by 48dp. The icon for the control does not have to be the full size, but can use padding to increase the visual space, all of which can be clicked or tapped.

A series of controls where the icons are different sizes, such as 24dp and 40dp, but use padding around the icon to increase the target size to 48dp.
An example from the Material guidelines showing different sized icons all with a consistent 48dp by 48dp sized target area.

The WCAG guideline for a target size of 44 pixels by 44 pixels is the minimum required and depending on context of use, people may require larger target sizes. An example of this in practice can be found in Google's Design for Driving guidance, used for designing interfaces in cars. The Design for Driving sizing recommends a much larger minimum touch target size of 76dp by 76dp. The larger size is used "to be glanceable and easily selected by a driver while the car is in motion". The target area size has been made larger to better meet the needs of people using the controls by considering their situation and environment.

At the moment, it's not possible to create content that is sized using physical measurements like millimetres (mm). This is because different devices are sized differently and have different pixel densities and display resolutions. Physical measurements such as mm used in CSS are not guaranteed to be displayed accurately, as they are still anchored and defined in terms of CSS pixels. Because of this, you will notice that different platforms use different measurements for target sizes:

  • W3C provides guidance in terms of density-independent CSS pixels (px)
  • Apple provides sizes in points (pt)
  • Google in density-independent pixels (dp)

Follow the guidance for minimum recommended sizes and test them with people using your software and services, including people with disabilities, to ensure that they work for your target audiences and their varying needs.

Spacing between controls

As described earlier, often padding can be added around icons to make the target area bigger and easier to operate.

Spacing between controls can also affect how easy it is to click or tap the right control. Too little spacing means that people may accidentally activate a control that they did not mean to. In some cases, this may not be a problem, but in other cases accidental activation of controls can be problematic and lead to anxiety for people using the site.

A screenshot of a system where open and delete controls for a website are presented side-by-side, with very little space between them.
A delete button placed close to an open button, with very little space between the controls

The BBC's How to design for touch article builds on this and recognises that some controls may not meet their 44px by 44px tap target area size. If this is the case, spacing or "exclusion zones", can be added around a control to keep the space clear and make it easier to click or tap the right control.

Two examples of positioning controls. In the first example, controls have space between them, successfully separating their tap target areas. In the second example, the controls have no space between them and their tap target areas overlap.
An example from the BBC GEL guidelines demonstrating how exclusion zones can separate target areas.

When changing spacing, if controls are related, make sure that this visual relationship is not affected by implementing too much spacing. The Spacing article from the IBM Carbon Design System describes relationships and spacing as being closely related:

Elements in a design that are near each other are seen as being meaningfully related. As more space is added between elements, their perceived relationship weakens.

Consistent targets and spacing size

Once agreed on, spacing and target sizes can then be introduced into accessible design systems to ensure that all components are consistent. Similar to the way you would document focus states in a visual style guide, minimum target area sizes can also be documented and the spacing between components can be displayed to make it clear for developers how to implement patterns.

The "be consistent" Inclusive Design Principle describes how consistency can improve people's experience with your websites. Consistent patterns and components make it easier for people to understand how to interact with the site and to activate the controls that they want to. Consistency across all components and pages ensures that people do not have to relearn how to use your website.

If your target sizes are both consistent internally (across your website) and they match other guidance (like WCAG), people will be able to comfortably interact with the website and feel confident in doing so.

Check target sizes

You can check the target sizes during the design stage and during implementation.

When designing prototypes, tools such as Figma will display the dimensions of elements. Select the control to view its size. Ensure that you factor in any spacing between controls. Using Figma, on Mac press the Option key or on Windows press the Alt key, and then hover over another element to view the spacing between elements.

A button design with dimensions of 120 pixels by 37 pixels displayed below the button, with a spacing of 16 pixels to the adjacent button.
A button's dimensions and the spacing between buttons, displayed in Figma.

When implemented, you can check target sizes using your browser's development tools. Using Chrome as an example, either right click and select "Inspect", or in the settings menu, select "More Tools" and then "Development Tools". With the development tools panel open, you can navigate through the list of HTML elements, or select an element with the mouse. With an element selected, you'll be able to view the size of the control. Again, make sure to take into account any spacing between controls.

The TetraLogical site, with the Blog control highlighted, displaying that the element is an <a> element, sized 136.44 pixels wide, by 41.09 pixels tall.
A button's dimensions, displayed in Chrome using the development tools.

Tips for target size

  • Make sure that controls are appropriately sized and spaced
  • Test the size of controls with your audience, including people with disabilities
  • Implement spacing and target sizes consistently

Proposed success criterion

At the time of writing, there is a proposed WCAG 2.2 Level AA success criterion that relates to target areas: Target Size (Minimum).

In general, it requires that the target size for controls are at least 24 CSS pixels by 24 CSS pixels. However, it does allow for targets that are smaller, as long as their 'offset' (which the Success Criterion defines as the size of the target, plus its spacing to any adjacent targets) is at least 24 CSS pixels. There are also a handful of exceptions for where the minimum size does not apply, such as if the size of the target is determined by the user agent and has not been changed, or if the target is in a sentence or block of text.

However, this is not currently a W3C Recommendation and the inclusion of the criterion may change before release of WCAG 2.2.

Update: in the most recent (May 2023) editor's draft for the upcoming WCAG 2.2, the proposed Target Size (Minimum) has been considerably reworked. Instead of the original idea of 'target offset', the spacing exception now defines the minimum space between targets using circles:

Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target.

Ideally, targets should have dimensions of at least 24 by 24 CSS pixels. If they are smaller, there must be a "clearance" of at least 24 CSS pixels around the center of the target, where no other targets are present.

An illustration showing two rows: in the first row, we have a horizontal toolbar of icon-based controls, measuring 20 by 20 pixels, with 4 pixels of spacing between them. The controls are overlaid with circles, all with a 24 pixel diameter. These circles don't overlap, so this toolbar passes. In the second row, we have the same toolbar, but the 20 by 20 pixel controls are tightly packed together with no spacing. When placing 24 pixel diameter circles over these controls, all the circles overlap, failing the criterion.
For small targets, place a 24 CSS pixel diameter circle on each target – if any circles overlap, or if any circle intersects another target, the spacing exception is not satisfied and the targets fail the Success Criterion

Note that, as a result, the name of the Target Size (Minimum) criterion is perhaps misleading. It won't guarantee that there are no small targets. It defines an ideal minimum size, but also allows an exception for smaller targets with sufficient spacing. The intent of the criterion is not to make sure targets are large enough to be comfortably activated, but to avoid having targets that are too small clustered closely together, which would otherwise increase the likelihood of a person accidentally activating an adjacent target.

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.

Updated Monday 15 May 2023.