Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.3,
which currently checks 95 accessibility rules, into an automated web site scanner.
<dt> and <dd> elements must be contained by a <dl>
Definition list items (
dtand/ordd) must be wrapped in parentdlelements 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
dlelements, otherwise it will be invalid.A definition list must follow a specific hierarchy. A list is defined using the
dlelement. What follows are alternating sets ofdtandddelements, starting with thedtelement.dtelements define a term whileddelements denote a term's description. Each set ofdtelements must have a corresponding set ofddelements. Onlydtandddelements are allowed in definition list. If this hierarchy is not followed, the list will be invalid.
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 roles missing required child roles 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 roles 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 lists (dl) must contain only properly-ordered dt and dd groups, script or template 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 separate dt element, and its definition goes in the dd element directly following it.
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.