Axe Core Guide
Styled <p> elements must not be used as headings
Since screen reader users cannot otherwise determine the structure of the document, styled p components must not be utilized to represent headings.
The fundamental goal of headers is to communicate the page’s organizational structure. Using varied text sizes allows sighted readers to see the structure. However, heading components must be marked up properly for screen reader users.
When header components are used correctly, both sighted and screen reader users will find it much simpler to traverse the page.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Headings serve to explain the organization of the webpage, not only to draw attention to key text. They must be succinct, distinct, and numbered h1 through h6 in hierarchical sequence. For screen reader users, headers are a useful tool because of all of these characteristics.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Due to the fact that search engines use headings when filtering, arranging, and showing results, headers offer advantages beyond just making a page more accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Verifies that paragraph components are not given the appearance of headers by using italic, bold, or font size.
Learn more:
Related Accessibility Rules
The visible label of interactive items labeled through their content must be included in their accessible name.
This rule applies to any element with the following attributes:
- a semantic role that is a widget that supports name from content,
- visible text, and
-
an
aria-labeloraria-labelledbyattribute.
button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, switch, tab, and treeitem are widget roles that support name from content.
The whole visible text content of the target element either matches its accessible name or is contained within it.
Leading and trailing whitespace and case sensitivity differences should be disregarded.
Users using speech input can interact with a web page by saying the visible text labels of menus, links, and buttons.
Voice input users are confused when they utter a visible text label, but the speech command does not work since the accessible (programmatic) name of the component does not match the visible label. When a user interface component contains a visible text label — whether the label is actual text or a picture of text — that text must also appear in the component’s accessible (programmatic) name. When the visual label and accessible (programmatic) name for interactive components are synchronized, users using speech input can engage with those components successfully.
What this Accessibility Rule Checks
For any user interface element with a visible text label, the accessible name must match (or include) the label’s visible text.
Markup for data tables can be tedious and perplexing. There are several capabilities in screen readers that make it easier to navigate tables, but for these features to function properly, tables must be precisely marked up. Instead than utilizing a caption element, some tables visually imply a caption by employing cells with the colspan element.
Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.
Screen reader users cannot understand the purpose of the table visually when tables are not marked up with an actual caption element but rather use a colspan element on cells to visually indicate a caption.
What this Accessibility Rule Checks
Verifies that data tables are identified with table cells that utilize a colspan element to visually convey a caption.
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.
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.
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.
Ensures that the aria-roledescription attribute is only applied to elements having explicit or implicit role values.
Inappropriate aria-roledescription attribute values that clash with an element’s implicit or explicit role value can impede the web page’s accessibility. A contradictory aria-roledescription attribute value may have no effect on the application’s accessibility and may trigger behavior that blocks accessibility for entire application sections.
When aria-roledescription attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, a semantic conflict may occur between the aria-roledescription value and the implicit or explicit element role value, resulting in assistive technology products reporting nonsensical user interface (UI) information that does not accurately represent the intended UI experience.
What this Accessibility Rule Checks
Use aria-roledescription values to adequately explain implicit or explicit element role values.
ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role values, and not be abstract roles in order to correctly display the element’s purpose.
Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.
When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.
What this Accessibility Rule Checks
Examines each element containing the WAI-ARIA role property to check that its value is valid.
Makes certain that each ARIA toggle field has an accessible name.
Ensures that any element having a semantic role has a name that is easily accessible.
Among the semantic roles are:
- checkbox
- menu
- menuitemcheckbox
- menuitemradio
- radio
- radiogroup
- switch
What this Accessibility Rule Checks
There is an accessible name for ARIA toggle fields.
Valid values must be present for ARIA properties that begin with aria-.
To fulfill the intended accessibility purpose, these values must be written correctly and relate to values that make sense for a certain property.
ARIA attributes (those beginning with aria-) must have legitimate values. For a given attribute to fulfill the intended accessibility function, these values must be written correctly and correlate to values that make sense.
A diverse range of values are accepted for many ARIA attributes. There must be permitted values, acceptable “undefined” values, and acceptable “default” values.
Content that does not adhere to the permitted values is inaccessible to users of assistive technology.
What this Accessibility Rule Checks
Verifies that the WAI-ARIA attributes’ values are correct for each element that contains them.
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.