Axe Core Guide
Delayed refresh must not be used
Remove the http-equiv="refresh" attribute from each meta element in which it is present.
Example of invalid code:
<meta http-equiv="refresh" content="60" url="http://example.com/index.html">Automatic page refreshing can be disorienting for users since they do not anticipate it. Moreover, refreshing the page causes the focus to reset to the top of the page, resulting in user frustration.
Redirection and page refreshing using the <meta> element can cause issues for users with disabilities. The primary reason for this is the lack of user control over the timing of the redirection or refresh. If the goal of the <meta> element is to redirect users to a new location, server-side methods should be used instead of client-side methods. Moving or updating content can present challenges for users who struggle to read stationary text quickly or track moving objects, and it can also cause difficulties for screen readers.
If the intention of the <meta> element is to refresh the page, it is recommended to handle it using JavaScript. Additionally, incorporate additional scripting to provide users with options to pause the refresh, increase the time between refreshes, or disable the refresh entirely.
What this Accessibility Rule Checks
Checks for the presence of the http-equiv=”refresh” attribute on the meta elements.
Learn more:
Related Accessibility Rules
Check that all links with the same accessible name fulfill the same function.
This guideline is significant since the goal is to assist viewers in understanding the purpose of each link in the material so they may determine whether or not to follow it. Links with the same destination should have the same descriptions, but links with different purposes and destinations should have different descriptions (see also Success Criterion 3.2.4), which calls for consistency in identifying components with the same functionality). Links can be understood when they are out of context, such as when the user agent presents a list of all the links on a page, because the purpose of a link can be inferred from its link text.
What this Accessibility Rule Checks
This rule’s algorithm yields:
-
Undefined for a native link with the
hrefattribute but no visible name. - Undefined when there is no accessible name for an ARIA link.
- Undefined when the accessible name of an ARIA link is merely a collection of unicode (emoji, punctuation, nonBmp) characters.
-
True for native links with an accessible name and a
hrefattribute value. -
True for ARIA links with accessible names (for example, a
areawithmapused in aimageelement). -
True for native links having
hrefattribute values and a name that can be found (that also has emoji, nonBmp and punctuation characters).
An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternative text for each of the distinct clickable parts, as well as for the larger image itself.
In the absence of alternative text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.
What this Accessibility Rule Checks
Ensures that image map area elements have alternative text.
Not all ARIA role-attribute combinations are valid. This rule ensures that each role has the required qualities.
Using ARIA attributes in roles where they are not permitted can impair web page accessibility. Using an improper role-attribute combination will have no effect on application accessibility at best and may trigger behavior that blocks accessibility for entire areas of an application at worst.
When ARIA attributes are used on HTML elements that do not conform to WAI-ARIA 1.1, they interfere with the semantics of the elements, causing assistive technology products to display nonsensical user interface (UI) information that does not represent the document’s true UI.
What this Accessibility Rule Checks
Checks that each element with an ARIA role is using only the ARIA attributes that are permitted for that role.
WAI-ARIA role attribute values must be correct. This means that values must be written correctly, correlate to existing ARIA role values, and not be abstract roles in order to properly display the element’s purpose.
When an assigned WAI-ARIA role value for the parent element is invalid, a developer’s intended accessible technology activity is disabled.
When screen readers and other assistive devices do not understand the job of each element on a web page, they cannot interact with it intelligently or explain the role to the user. When the value for a role is invalid, assistive technologies are unable to communicate the element’s features, properties, and methods. Applying role="table" to a <ul>, for example, effectively hijacks the default semantics associated with the <ul> element in a way that screenreaders do not expect, resulting in unexpected behavior.
What this Accessibility Rule Checks
Check all elements with WAI-ARIA role attribute values to confirm the role value is correct. The role value must be appropriate for the element in the context of the document.
aria-braille attributes must have a non-braille equivalent.
WAI-ARIA requires that the aria-braillelabel attribute is only ever used on elements with an accessible name, such as from aria-label. Similarly, aria-brailleroledescription is required to only ever be used on elements with aria-roledescription.
ARIA braille attributes were introduced to allow adjusting how labels and role descriptions are rendered on a braille display. They cannot be the only attribute providing a label, or a role description. When used without a corresponding label or role description ARIA says to ignore these attributes, although this may not happen consistently in screen readers and other assistive technologies.
How to Fix this Issue
-
The
aria-braillelabeloraria-brailleroledescriptionattribute may have been placed on the wrong element, such as a parent or child of the correct element. The attribute should be put on a different element. -
The element with
aria-braillelabelattribute needs anaria-labelattribute or other attribute that gives it an accessible name. -
The element with
aria-brailleroledescriptionattribute needs aaria-roledescriptionattribute. -
The
aria-braillelabeloraria-brailleroledescriptionattribute serves no function and should be removed.
What this Accessibility Rule Checks
Checks that aria-braillelabel is only used on elements with a non-empty label, and that aria-brailleroledescription is only used on elements with a non-empty aria-roledescription.
ARIA attributes must be used as specified for the element’s role.
Using ARIA attributes on elements where they are not expected can result in unpredictable behavior for assistive technologies. This can lead to a poor user experience for people with disabilities who rely on these technologies. It is important to follow the ARIA specification to ensure that assistive technologies can properly interpret and communicate the intended meaning of the content.
Some ARIA attributes are only allowed on an element under certain conditions. Different attributes have different limitations to them:
aria-checked: This should not be used on an HTML input element with type=”checkbox”. Such elements have a checked state determined by the browser. Browsers should ignore aria-checked in this scenario. Because browsers do this inconsistently, a difference between the native checkbox state and the aria-checked value will result in differences between screen readers and other assistive technologies.
The aria-posinset, aria-setsize, aria-expanded, and aria-level attributes are conditional when used on a row. This can be either tr element, or an element with role="row". These attributes can only be used when the row is part of treegrid. When used inside a table or grid, these attributes have no function, and could result in unpredictable behavior from screen readers and other assistive technologies.
What this Accessibility Rule Checks
Check that ARIA attributes are not used in a way that their role describes authors should not, or must not do. I.e the use of this ARIA attribute is conditional.
Values assigned to ARIA role values must not be deprecated.
Using deprecated WAI-ARIA roles is bad for accessibility. They will not be recognized or correctly processed by screen readers and other assistive technologies. Using these means not everyone will be able to access essential information.
Ensure all values assigned to role="" correspond to WAI-ARIA roles that are not deprecated, or abstract. The following list indicates for each deprecated role a potential alternative that is better supported by assistive technologies:
-
directory: Consider using
section,list, ortreeinstead. Which is most appropriate depends on how directory was used.
What this Accessibility Rule Checks
Check all elements containing WAI-ARIA role attribute to ensure that the role is not deprecated in the latest version of the WAI-ARIA specification.
Elements with aria-hidden must not 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.
Ensures every ARIA input field has an accessible name.
This rule ensures that each ARIA input field has a name that is accessible.
There must be accessible names for the following input field roles:
- combobox
- listbox
- searchbox
- slider
- spinbutton
- textbox
What this Accessibility Rule Checks
The names of ARIA input fields must be accessible.
Not all ARIA role-attribute combinations are valid. Elements must only use permitted ARIA attributes.
Using ARIA attributes in roles where they are prohibited can mean that important information is not communicated to users of assistive technologies. Assistive technologies may also attempt to compensate for the issue, resulting in inconsistent and confusing behavior of these tools.
This Rule checks that noe of the attributes used with a particular role are listed as “prohibited” for that role in the latest version of WAI-ARIA.
The aria-label and aria-labelledby attributes are prohibited on presentation and none roles, as well as on text-like roles such as code, insertion, strong, etc.
What this Accessibility Rule Checks
Checks that each ARIA attribute used is not described as prohibited for that element’s role in the WAI-ARIA specification.