Accessibility Checking for Large Sites

An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternate text for each of the distinct clickable parts, as well as for the larger image itself.

In the absence of alternate text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.

What this Accessibility Rule Checks

Ensures that image map area elements have alternate text.

Make sure that the kind attribute in the track element is set to captions. Also, verify that the text content of the captions adequately communicates all relevant information from the audio element, including speaker identification, dialogue transcripts, musical cues, and sound effects.

Below is an example code that demonstrates the addition of two tracks, one in English and another in Spanish.

<audio>
   <source src="conversation.mp3" type="audio/mp3">
   <track src="captions_en.vtt" kind="captions" srclang="en" label="english_captions">
   <track src="captions_es.vtt" kind="captions" srclang="es" label="spanish_captions">
</audio>

What this Accessibility Rule Checks

Checks the use of all HTML5 <audio> elements to ensure each contains a <track> element with the kind attribute value captions.

This rule demands the absence of any blink elements. Blinking items might be challenging to activate, and flashing writing can be challenging to read.

The blink tag causes information to blink, as the name implies. Although you might enjoy the appearance, blinking text and objects (such as links and buttons) might be challenging to read and operate, especially for people with poor hand-eye coordination or limited dexterity.

For those who have visual or cognitive impairments, reading blinking letters can be quite challenging. Text that blinks can be annoying, especially for people who have cognitive difficulties. Some people may find it challenging to understand. The blink element should never be used due to these reasons.

What this Accessibility Rule Checks

Verifies that the blink element is never utilized.

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

When used in a document, the frame or iframe element’s title attribute must not be empty in order to provide context for users of screen reader software.

Users of screen readers depend on the title of a frame to describe its contents. If the HTML for a frame or iframe element lacks a title attribute, navigating within the element can be a frustrating and time-consuming experience for users of this technology.

Users of screen readers can see a list of the frames on a page and their respective titles. Providing each frame with a distinct, descriptive label facilitates easy navigation. Without titles, it’s easy to get lost trying to jump from one frame to the next. Screen readers will instead provide information like “frame,” “JavaScript,” the filename, or the URL if no title is provided. This data is unlikely to be useful in most situations.

What this Accessibility Rule Checks

Make sure the title attribute of every iframe and frame element is both distinct and not empty.

To express their purpose and meaning to screen reader users, all images must include alternate text.

Even if the image just contains text, screen readers have no way of translating it into words that are read to the user. As a result, photos must have concise, descriptive alt text so that screen reader users grasp the image’s contents and purpose.

If you can’t see, all visual information, such as photographs, is meaningless unless a digital text equivalent is provided so that screen readers may translate that text into either sound or braille. People with limited eyesight or colorblindness experience the same phenomenon to varied degrees.

Screen readers cannot translate an image into speech or braille to make it available by sound or touch if you do not provide a suitable alternative that works for their available sensory modalities, such as making an image accessible by providing a digital text description.

What this Accessibility Rule Checks

Ensures that all <image> elements have alternative text and either role="presentation" or role="none" (ARIA 1.1).

Ensures that input buttons have legible text.

Without an accessible name, screen reader users cannot determine the purpose of a input type="button".

Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.

What this Accessibility Rule Checks

The text on input buttons must be readable.

Makes certain that <input type="image"> elements have alternate text.

Screen reader users will not understand the function of a <input type="image"> button unless equivalent wording is provided. Even if the image merely contains text, alternate text is required because a screen reader cannot interpret images of words into output.

Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.

Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.

What this Accessibility Rule Checks

Ensures that each <input type="image"> has a name that can be found.

Each form element must have a label element attached with it programmatically.

Forms must have effective form labels in order to be accessible. Form elements like as checkboxes, radio buttons, input fields, etc. are frequently self-explanatory to sighted users, even if they are not programmatically labeled. Users with screen readers require descriptive form labels to identify form fields. Adding labels to all form elements removes uncertainty and makes the product more accessible.

When form elements lack labels, screen reader users are unaware of the expected data input. Screen readers cannot determine information about input items programmatically in the absence of an established label association (or redundant text functioning as a label).

Since clicking the label activates the control, people with weak motor control do not benefit from a bigger clickable area for the control.

What this Accessibility Rule Checks

Ensures that each form element has a label associated with it programmatically.