Axe Core Guide
All touch targets must be 24px large, or leave sufficient space
Touch targets must have a minimum dimension of 24 by 24 CSS pixels. The greatest unobscured area of the touch target is used to calculate size. The target must be at least 24 CSS pixels distant from any other touch target if its size is insufficient.
To be easily engaged without mistakenly triggering an adjacent target, touch targets need to be large enough and spaced apart. Users have trouble activating touch targets that are either too small or too close together.
All users who might find it challenging to confidently target or operate small controls can benefit from having targets with suitable size, or in the absence of that, sufficient target spacing. The following users gain, but are not restricted to:
- People who use a mobile device where touching the screen is the main form of interaction.
- Those who use a mouse, stylus, or touch input but have mobility issues like hand tremors.
- Those who use a device in environments where they are exposed to shaking, like on public transportation.
- Those who use a mouse but have trouble with fine motor movements; those who use a device with just one hand.
- Those who have large fingers or are using the device with just one hand.
What this Accessibility Rule Checks
Verify the touch target’s unobscured size and distance from other touch targets.
Learn more:
Related Accessibility Rules
A document’s accesskey attribute values must all be distinct. Or, to put it another way, accesskeys must not be used more than once to protect keyboard users from unpleasant surprises.
When a document’s accesskey attribute value is supplied, users can quickly activate or switch the focus to a particular element by hitting the designated key (often in tandem with the alt key). The page becomes less accessible as a result of duplicating the values for the accesskey attribute.
Make sure the value of each defined accesskey is distinct and does not interfere with any screen reader or default browser shortcut keys.
Users who must use alternative keyboards or input devices serving as keyboard emulators, users who have problems tracking a pointer, or users who are blind or have low eyesight and cannot employ eye-hand coordination-required devices like mice, cannot operate the content.
What this Accessibility Rule Checks
Makes certain that every element on the page with an accesskey attribute has a different value.
The destination, purpose, function, or action of an ARIA command element must be made clear in understandable text for screen reader users.
The function of items with the roles link, button, or menuitem that lack an accessible name cannot be understood by screen reader users.
What this Accessibility Rule Checks
Verifies that all elements with the roles link, button, or menuitem have a clear, understandable name.
For screen reader users, Aria dialog items must include intelligible language that specifies the destination, purpose, function, or action in detail.
Elements with role="dialog" or role="alertdialog" that lack an accessible name cannot be understood by screen reader users.
What this Accessibility Rule Checks
Verifies that all objects with the role="dialog" or role="alertdialog" attribute have a clear, understandable name.
This rule determines whether or not aria-hidden elements contain focusable elements.
Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.
aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.
If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.
Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.
The rule applies to any element whose aria-hidden attribute value is true.
By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element.
This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.
A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.
What this Accessibility Rule Checks
For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.
For screen reader users, aria meter elements must have legible language that defines the destination, function, or action.
Users of screen readers are unable to determine the function of items with role="meter" but no accessible name.
What this Accessibility Rule Checks
Checks that all items with role="meter" have a distinguishable, accessible name.
For screen reader users, Aria progressbar items must include understandable language that specifies the destination, purpose, or action.
Users of screen readers are unable to determine the purpose of items with the role="progressbar" attribute that lack an accessible name.
What this Accessibility Rule Checks
Checks that all items with role="progressbar" have a distinguishable, accessible name.
Screen reader users are required to have access to understandable text within Aria tooltip elements. This text must define the destination, purpose, function, or action in a clear and concise manner.
Users of screen readers are unable to understand the function of elements that have the role of tooltip but do not have accessible names.
What this Accessibility Rule Checks
Performs a check on all elements that have the role tooltip to ensure that they have a name that can be understood and is accessible.
The destination, purpose, function, or action of an Aria treeitem element must be made clear in the element’s understandable text for screen reader users.
Users of screen readers are unable to determine the function of items with the role treeitem that lack an accessible name.
What this Accessibility Rule Checks
Ensures that all objects with the role treeitem have a clear, understandable name.
The list of 53 Input Purposes for User Interface Components are used as the basis for the programmatic definition of the purpose for each common input field that collects user data.
For screen readers to work properly, the autocomplete attribute values must be true and applied correctly.
Inaccessible content stems from missing autocomplete values in form fields. In the absence of the necessary autocomplete attribute values, screen readers will not read the identified autocomplete form fields.
When screen readers are unable to adequately notify users about the requirements for form field interaction, users cannot successfully navigate forms.
What this Accessibility Rule Checks
The purpose of each user-information-collecting input field can be established programmatically when:
- The input field fulfills a purpose specified in the Input Purposes for User Interface Components section, and
- The content is implemented using technologies that provide support for determining the desired meaning of form input data.
Ensure that the text spacing specified by style attributes is modifiable using custom stylesheets.
When lines of text are single-spaced, many people with cognitive difficulties have difficulty following them. Providing spacing between 1.5 and 2 makes it easier for them to begin a new line after finishing the previous one.
What this Accessibility Rule Checks
Text line spacing must be modifiable by custom stylesheets.