Accessibility Checking for Large Sites

For screen reader users, buttons must include recognizable text that specifies the destination, purpose, function, or action.

Users of screen readers are unable to determine the function of elements with the roles role="link", role="button", and role="menuitem" that lack an accessible name.

What this Accessibility Rule Checks

Verifies that each button has a distinguishable, accessible label.

Each page must have a main landmark to allow users to rapidly traverse repetitive blocks of material or interface elements (such as the header and navigation) and get the primary content.

Due to the fact that websites frequently display secondary, repetitive content on several pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to a page’s principal content. This saves keystrokes and reduces physical discomfort.

It is more difficult and time-consuming for users who cannot use a mouse to navigate using the keyboard if the interface does not provide features to facilitate keyboard navigation. To activate a link in the middle of a web page, for instance, a keyboard user may have to browse through a significant number of links and buttons in the page’s header and primary navigation.

Extremely motor-impaired users may require several minutes to browse through all of these pieces, which can cause to tiredness and potential physical pain for some users. Even users with less severe limitations will require more time than users with a mouse, who can click on the desired link in less than a second.

What this Accessibility Rule Checks

Checks for the presence of at least one of the following features:

• an internal skip link
• a header
• a geographical landmark

Definition lists (dl) may only contain dt and dd groups, div, script, or template elements that are properly organized.

Screen readers have a particular method for reading definition lists. When such lists are not correctly marked up, screen reader output may be erroneous or confusing.

A list of definitions is used to explain the meaning of words or phrases. Using the dl element, the definition list is formatted. Within the list, each term is enclosed in its own dt element, and its definition is enclosed in the dd element that immediately follows.

What this Accessibility Rule Checks

Ensures that each dl element is correctly constructed.

To be valid, definition list items (dt and / or dd) must be enclosed by parent dl elements. This allows screen reader users to recognize the right hierarchy of the list’s information.

A definition list item is invalid if it is not surrounded by parent dl elements.

A definition list must adhere to a particular hierarchy. Using the dl element, a list is defined. It is followed by alternating sets of dt and dd elements, beginning with dt. dt elements define a term while dd elements denote a term’s description. Each group of dt components must be accompanied by a group of dd elements. In the definition list, only dt and dd items are permitted. If not followed, this hierarchy will render the list invalid.

What this Accessibility Rule Checks

Ensures that every child dd and dt element has a parent dl element.

The title element of the HTML document must not be empty in order to give users with an overview of its content.

Users using screen readers utilize page titles to obtain an overview of the page’s content. If a page lacks a title, navigating through it can soon become difficult and confusing for screen reader users. The title element of the page is the first item screen reader users hear when the page loads.

When they arrive at a page, screen reader users hear the page’s title first. If there is no title or if the title is not descriptive and unique, users of screen readers must read the page to discern its content and purpose.

What this Accessibility Rule Checks

Makes certain that each HTML document has a title tag associated with it.

The value supplied to active ID attributes on focusable elements must be unique to avoid assistive technology from overlooking the second instance. Active ID attributes may not be used more than once on focusable components inside the same document; assistive technology requires unique IDs for focusable active elements in order to differentiate between them.

Focusable components on a page are identified exclusively by the ID attribute. It is illogical to duplicate an active ID.

Duplicate active ID values compromise the accessibility of focusable elements, such as form labels, table header cells, and so on. Screen readers and client-side scripts will bypass all instances of repetition other than the first. Validating HTML files aids in preventing and eliminating potential sources of accessibility issues, so long as accessibility is not compromised.

Those who have expertise with client-side scripting are aware that when an active ID is reused, the only instance that is normally acted upon by the script is the first. Similarly, assistive technology may only appropriately reference the first active ID when mentioning it.

What this Accessibility Rule Checks

Ensures that each page element with an active ID and a focusable state has a unique value.

To avoid a second instance being missed by assistive technology, the value supplied to an id property used in ARIA or in form labels must be unique.

To put it another way, ID values used in ARIA and labels cannot be used more than once to distinguish one element from another in the same document.

Common validation problems like duplicate IDs can make labels, like ARIA elements, form fields, and table header cells, inaccessible.

Each element is distinguished from the others by a unique ID, which also prevents erroneous markup in which only the first instance is appropriately referenced by client-side scripting or assistive technology.

What this Accessibility Rule Checks

Assures the uniqueness of each ID used in ARIA attributes and the for property on a label.

To avoid assistive technology missing the second instance, the value supplied to an id property must be distinct. In other words, id attributes may not be used more than once to distinguish one element from another within the same document.

Elements on a page are uniquely identified via the ID attribute. It makes no sense to make a second id.

Duplicate ids can make labels for forms, table header cells, etc. inaccessible since screen readers and client-side scripts pass over the second iteration. They are typical markup validation mistakes that, if they do not damage accessibility, can reduce potential causes of accessibility issues.

Those who are familiar with client-side scripting are aware that when an ID is reused, the script normally only reacts to the first instance of that id use. Similar to this, assistive technology might only appropriately reference the first id when referencing an id.

What this Accessibility Rule Checks

Makes certain that every element on the page with an id attribute has a distinct value for the id attribute.

It is a best practice to make sure each heading element, denoted by the tags <h1> through <h6>, contains text.

Users of screen readers are informed when a heading tag is present. Users may become confused or even unable to access information on the page’s structure if the headline is blank or the text cannot be accessible.

Users of this technology won’t be able to hear the content of a header if the text inside it is inaccessible to a screen reader. Users using screen readers must be able to access the contents since headings reveal the structure of a webpage.

Applying header markup (<h1> through <h6>) is a quick approach to make content stand out, but doing so will make it more difficult for those using assistive technology to navigate a website.

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.

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.

What this Accessibility Rule Checks

Ensures that headings have content and that a screen reader can access that content.

Whether native HTML or a custom widget, user input elements need to play the right roles in order to make their meaning clear to screen reader users when they are focused on and landed on. If a custom widget, the element’s function must be correctly exposed by using appropriate ARIA role values rather than abstract roles.

In order for screen reader technology to convey information to users, elements in the focus order must play a function appropriate for interactive content.

If interactive content elements do not have the proper roles, the developer’s planned accessibility function cannot be carried out by the role.

When screen readers and other assistive technologies cannot communicate to the user the proper role of each element on the web page, they are unable to interact with it sensibly. Assistive technology cannot communicate with an HTML element’s set of features, properties, and ways of communicating information to and/or from the user when the value for a role is invalid.

What this Accessibility Rule Checks

Verifies that the role attribute value is accurate and suitable for all interactive components in the focus order, regardless of whether they are native HTML or customized ARIA widgets.