Accessibility Checking for Large Sites

When used as links, link text and alternative text for images must be recognizable by screen readers, have no duplicate labels, and be focusable.

• Accessibility is hindered by inaccessible link components, as they are a crucial component of a website.
• Users who traverse a webpage using only the keyboard (and no mouse) can only click on links that can gain programmed emphasis. Inaccessible to these users is any link that cannot gain programmatic focus.
• Similar to sighted people, screen reader users must know where a link leads. This information is provided via inner link text, albeit it will not be utilized if a screen reader cannot access it.
• Only the links and form components that can get programmatic focus can be activated by keyboard users, including those with visual impairments or those who cannot use a mouse. Keyboard users cannot access events activated only by other sorts of focus, such as onmouseover events that depend on the mouse hover focus. By default, only links and form elements receive keyboard emphasis. Add tabindex="0" to items that are not links or form components to make them focusable.

What this Accessibility Rule Checks

Ensures that each link’s name is accessible.

To be read out to screen reader users, all embedded objects must have text alternatives.

There is no mechanism for screen readers to convert non-text items into text that is announced to users. They read aloud the alternative text instead. There must be brief, descriptive alternative text in embedded “object” components allowing screen reader users to access the information.

An embedded object in a document is defined by the “object” element. It is used to incorporate another web page or multimedia (audio, video, applets, etc.) into the document. There must be a text alternative for the object element in order for screen reader users to understand what the object contains.

When creating alternative text, keep in mind that its goal is to inform blind users about the information included in and intended usage of the image. Blind users should be able to derive the same amount of information from alternative text as a sighted user does from the image. The image’s objective, purpose, and significance should be explained in the alternative text.

The following considerations are beneficial to bear in mind when creating alternative text:

• Why is this page featuring non-text content?
• What data is it displaying?
• What function does it serve?
• What words would I use to communicate the same information or purpose if I couldn’t use the non-text content?

Make sure this attribute’s entire text is relevant. Generally speaking, terms like “chart”, “picture”, “diagram”, or image file names are not very helpful.

What this Accessibility Rule Checks

Ensures that each object element has an alternative text.

Ensures that components with the label role="img" have an alternate text.

Even if an image merely contains text, screen readers are unable to convert it into words that the user can hear. As a result, alternative language for images must be brief, descriptive, and easily understandable so that screen reader users may understand the image’s contents and intended application.

Without an accessible text alternative that screen readers can translate into sound or braille, all visual information, including images, is utterly useless if you can’t see. Accessible alternate text is also necessary to variable degrees for people with low vision or color blindness problems.

If an image does not have a text alternative that is accessible, screen readers cannot translate the information in the image to voice or braille.

What this Accessibility Rule Checks

Elements with the property value role="img" must additionally have markup that specifies accessible alternative text for the image.

A label element with a programmatic association must be included for each select element.

To make forms accessible, they must have clear form labels. Even if a form element isn’t programmatically named, sighted users can usually tell what it’s for when they see checkboxes, radio buttons, input fields, etc. To identify form fields, screen reader users need clear form labels. All form elements should have labels to remove confusion and make the product more accessible.

Screen reader users are in the dark about the expected input data when form elements lack labels. Without a defined label connection (or redundant text acting as a label), screen readers cannot automatically determine information about input items.

What this Accessibility Rule Checks

ensures that each select element has a label that is associated with it programmatically.

An image map that is server-side rather than client-side is present in the page.

Server-side image maps can’t be used with a keyboard since mouse clicks are needed to access the links they contain, rendering them unavailable to users who only use keyboards.

The server-side software used to process the image map receives the locations of the mouse click from server side image maps. They are not keyboard accessible since they rely on mouse clicks, although client-side image mappings are. Additionally, unlike the regions of a client-side picture map, actionable areas of a server-side image map cannot be provided with text alternatives.

What this Accessibility Rule Checks

Makes sure that server-side image maps are not used.

Ensures that SVG elements with the roles img, graphics-document or graphics-symbol have a text alternative that is accessible.

In order to make information provided by non-text material (including SVG graphics) accessible, Success Criterion 1.1.1 requires the usage of a text alternative. Because they can be portrayed through any sensory modality (for example, visual, auditory, or tactile) to suit the user’s needs, text alternatives are a fundamental method of making information accessible. By including text alternatives, a wider range of user agents can present the content in different ways.

For instance, a person who is blind can request that the text equivalent of an image be read out using synthetic speech. An audio file’s text alternative can be presented for people who cannot hear it, allowing them to read it. Text alternatives will eventually make it simpler to translate information into sign language or a more basic version of the same language.

What this Accessibility Rule Checks

The algorithm for this rule returns:

• True if the element has a <title>code child

<svg id="target"><title>Time II: Party</title></svg>

• True if the <title> child has text nested in another element.

<svg id="target"><title><g>Time II: Party</g></title></svg>

• False if the element has no <title> child.

<svg id="target"></svg>

• False if the <title> child is empty.

<svg id="target"><title></title></svg>

• False if the <title> is a grandchild.

<svg id="target"><circle><title>Time II: Party</title></circle></svg>

• False if the <title> child has only whitespace.

<svg id="target"><title> \t\r\n </title></svg>

• False if there are multiple titles and the first is empty.

<svg id="target"><title></title><title>Time II: Party</title></svg>

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.

Markup for data tables can be tedious and perplexing. Tables should be marked up correctly in terms of header format and semantics. 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.

Sighted people can typically identify the table’s headers and their relevance to the data at a glance. This needs to be done in the markup for non-sighted users.

When a data table is created with accessibility in mind, the user can go from cell to cell while hearing the screen reader proclaim the matching table headers for the data cells. This is known as table navigation mode. When navigating through huge data tables or when cells include similar-sounding data that could be easily misconstrued, hearing the table headers is extremely useful.

But if the table lacks accessibility features, the table navigation method is useless.

What this Accessibility Rule Checks

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

Markup for data tables can be tedious and perplexing. Tables should be marked up correctly in terms of header format and semantics. 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 that each header cell is referred to as a header of a column or row in data tables by checking their markup.