Accessibility Checking for Large Sites
Rocket Validator integrates
axe-core version 4.4,
which currently checks 96
accessibility rules, into an automated web site scanner.
<dl> elements must only directly contain properly-ordered <dt> and <dd> groups, <script>, or <template> elements
Definition lists (
dl
) must contain only properly-ordereddt
anddd
groups,div
,script
, ortemplate
elements.Screen readers have a specific way of announcing definition lists. When such lists are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.
A definition list is used to provide the definitions of words or phrases. The Definition List is marked up using the
dl
element. Within the list, each term is put in a separatedt
element, and its definition goes in thedd
element directly following it.
Learn more about this accessibility rule at Deque University >>
Other WCAG: 1.3.1 accessibility rules checked by Rocket Validator
Some ARIA parent role
values applied to elements must contain specific child elements and role
values to perform intended accessibility function.
For each role, WAI-ARIA explicitly defines which child and parent roles are allowable and/or required. ARIA role
s missing required child role
s will not be able to perform the accessibility functions intended by the developer.
Assistive technology needs to convey the context to the user. For example, in a treeitem
, it is important to know the parent (container), item, or siblings in the folder. This can be done in two ways:
- Code order or DOM: The necessary context is often clear from the code order or DOM.
- ARIA: ARIA (such as
aria-owns
) can be used provide the relationships when the hierarchy is not the same as the code structure or DOM tree.
Certain ARIA roles must be contained by particular parent role
s in order to perform the intended accessibility functions.
For each role, WAI-ARIA explicitly defines which child and parent roles are allowable and/or required. Elements containing ARIA role
values missing required parent element role
values will not enable assistive technology to function as intended by the developer.
When it is necessary to convey context to the user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, there is no way to provide the relationship information without the use of ARIA role parent elements.
Definition list items (dt
and/or dd
) must be wrapped in parent dl
elements to be valid. This enables screen reader users to understand the proper hierarchy of information in the list.
A definition list item must be wrapped in parent dl
elements, otherwise it will be invalid.
A definition list must follow a specific hierarchy. A list is defined using the dl
element. What follows are alternating sets of dt
and dd
elements, starting with the dt
element. dt
elements define a term while dd
elements denote a term's description. Each set of dt
elements must have a corresponding set of dd
elements. Only dt
and dd
elements are allowed in definition list. If this hierarchy is not followed, the list will be invalid.
Table header elements should have visible text. Ensure that the table header can be used by screen reader users. If the element is not a header, marking it up with a `td` is more appropriate.
Table header elements should have visible text that describes the purpose of the row or column to both sighted users and screen reader users.
Lists must be marked up correctly, meaning they must not contain content elements other than li
elements.
Screen readers have a specific way of announcing lists. This feature makes lists clearer to understand, but will only work if lists are properly structured.
When content elements other than list items are contained within a set of list elements, screen readers cannot inform the listener that they are listening to items within the list.
For a list to be valid, it must have both parent elements (a set of ul
elements or a set of ol
elements) and child elements (declared inside of these tags using the li
element), and any other content elements are invalid.
Although some non-content elements such as script, template, style, meta, link, map, area, and datalist are permitted within lists, content elements other than li
are not permitted.
All list items (li
) must be contained within ul
or ol
parent elements.
For a list to be valid, it must have both parent and child elements. Parent elements can either be a set of ul
tags or a set of ol
tags. Child elements must be declared inside of these tags using the li
tag.
Screen readers notify users when they come to a list, and tell them how many items are in a list. Announcing the number of items in a list and the current list item helps listeners know what they are listening to, and what to expect as they listen to it.
If you don't mark up a list using proper semantic markup in a hierarchy, list items cannot inform the listener that they are listening to a list when no parent is indicating the presence of a list and the type of list.
Styled p
elements must not be used to represent headings because the structure of the document cannot otherwise be determined by screen reader users.
The underlying purpose of headers is to convey the structure of the page. Sighted users can see structure by using different sizes of text. Screen reader users, though, require heading elements to be marked up explicitly. When heading elements are properly applied the page becomes much easier to navigate for screen reader users and sighted users alike.
In the same way that sighted users can glance at a page and get a sense of its contents, users of screen readers can do the same by navigating through headings. Well written and properly ordered headings can save users, especially those who use screen readers, a lot of time and frustration.
The purpose of headings is to describe the structure of the webpage, not just highlight important text. They should be brief, clear, unique, and marked with h1
through h6
elements in hierarchical order. All of these qualities make headings are a valuable tool for users of screen readers. In the same way that sighted users can glance at a page and get a sense of its contents, users of screen readers can do the same by navigating through headings. Well written and properly ordered headings can save users, especially those who use screen readers, a lot of time and frustration.
In addition to making the page more accessible, headings have other benefits, since search engines use headings when filtering, ordering, and displaying results. Improving the accessibility of your site can also have the effect of making your page more findable.
Data table markup can be tedious and confusing. Screen readers have some features to ease table navigation, but tables must be marked up accurately for these features to work correctly. Some tables use cells with a colspan
element to visually indicate a caption, instead of using an actual caption element.
Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.
When tables are not marked up with an actual caption element instead of using a colspan
element on cells to visually indicate a caption, screen reader users cannot correctly perceive the purpose of the table visually.
Data table markup can be tedious and confusing. Tables must be marked up done semantically and with the correct header structure. Screen readers have features to ease table navigation, but tables must be marked up accurately for these features to work correctly.
Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.
When tables are not marked up semantically and do not have the correct header structure, screen reader users cannot correctly perceive the relationships between the cells and their contents visually.
Data table markup can be tedious and confusing. Markup tables semantically and with the correct header structure. Screen readers have features to ease table navigation, but tables must be marked up accurately for these features to work correctly.
Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.
Sighted users can usually tell at a glance what the table's headers are and what their relationship to the data is. For non-sighted users this must be done in the markup.
When a data table is designed with accessibility in mind, the user enters into table navigation mode, which allows the user to navigate from cell to cell within the table while hearing the screen reader announce the corresponding table headers for the data cells. Hearing the table headers is especially helpful when navigating through large data tables, or when cells contain similar-sounding data that could be easily confused.
Table navigation mode is not useful, though, if the table lacks accessibility features.
Data table markup can be tedious and confusing. Markup tables semantically and with the correct header structure. Screen readers have features to ease table navigation, but tables must be marked up accurately for these features to work correctly.
Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.
When tables are not marked up semantically and do not have the correct header structure, screen reader users cannot correctly perceive the relationships between the cells and their contents visually.