Accessibility Guide for WCAG 2.1 Experimental

The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.

Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.

What this Accessibility Rule Checks

Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.

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-label or aria-labelledby attribute.

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.

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.

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.

Markup for data tables can be tedious and perplexing. Tables must be semantically marked up and have the proper header structure. Table navigation is made easier by features in screen readers, but for these capabilities to function properly, the tables must be precisely marked up.

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 are unable to correctly understand the relationships between the cells and their contents visually when tables are not adequately structured and marked up semantically.

What this Accessibility Rule Checks

Verifies the correct header structure and semantic markup of data tables.