Accessibility Guide for deafblind

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 alternative text for each of the distinct clickable parts, as well as for the larger image itself.

In the absence of alternative 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 alternative text.

Not all ARIA role-attribute combinations are valid. This rule ensures that each role has the required qualities.

Using ARIA attributes in roles where they are not permitted can impair web page accessibility. Using an improper role-attribute combination will have no effect on application accessibility at best and may trigger behavior that blocks accessibility for entire areas of an application at worst.

When ARIA attributes are used on HTML elements that do not conform to WAI-ARIA 1.1, they interfere with the semantics of the elements, causing assistive technology products to display nonsensical user interface (UI) information that does not represent the document’s true UI.

What this Accessibility Rule Checks

Checks that each element with an ARIA role is using only the ARIA attributes that are permitted for that role.

WAI-ARIA role attribute values must be correct. This means that values must be written correctly, correlate to existing ARIA role values, and not be abstract roles in order to properly display the element’s purpose.

When an assigned WAI-ARIA role value for the parent element is invalid, a developer’s intended accessible technology activity is disabled.

When screen readers and other assistive devices do not understand the job of each element on a web page, they cannot interact with it intelligently or explain the role to the user. When the value for a role is invalid, assistive technologies are unable to communicate the element’s features, properties, and methods. Applying role="table" to a <ul>, for example, effectively hijacks the default semantics associated with the <ul> element in a way that screenreaders do not expect, resulting in unexpected behavior.

What this Accessibility Rule Checks

Check all elements with WAI-ARIA role attribute values to confirm the role value is correct. The role value must be appropriate for the element in the context of the document.

aria-braille attributes must have a non-braille equivalent.

WAI-ARIA requires that the aria-braillelabel attribute is only ever used on elements with an accessible name, such as from aria-label. Similarly, aria-brailleroledescription is required to only ever be used on elements with aria-roledescription.

ARIA braille attributes were introduced to allow adjusting how labels and role descriptions are rendered on a braille display. They cannot be the only attribute providing a label, or a role description. When used without a corresponding label or role description ARIA says to ignore these attributes, although this may not happen consistently in screen readers and other assistive technologies.

How to Fix this Issue

• The aria-braillelabel or aria-brailleroledescription attribute may have been placed on the wrong element, such as a parent or child of the correct element. The attribute should be put on a different element.
• The element with aria-braillelabel attribute needs an aria-label attribute or other attribute that gives it an accessible name.
• The element with aria-brailleroledescription attribute needs a aria-roledescription attribute.
• The aria-braillelabel or aria-brailleroledescription attribute serves no function and should be removed.

What this Accessibility Rule Checks

Checks that aria-braillelabel is only used on elements with a non-empty label, and that aria-brailleroledescription is only used on elements with a non-empty aria-roledescription.

ARIA attributes must be used as specified for the element’s role.

Using ARIA attributes on elements where they are not expected can result in unpredictable behavior for assistive technologies. This can lead to a poor user experience for people with disabilities who rely on these technologies. It is important to follow the ARIA specification to ensure that assistive technologies can properly interpret and communicate the intended meaning of the content.

Some ARIA attributes are only allowed on an element under certain conditions. Different attributes have different limitations to them:

aria-checked: This should not be used on an HTML input element with type=”checkbox”. Such elements have a checked state determined by the browser. Browsers should ignore aria-checked in this scenario. Because browsers do this inconsistently, a difference between the native checkbox state and the aria-checked value will result in differences between screen readers and other assistive technologies.

The aria-posinset, aria-setsize, aria-expanded, and aria-level attributes are conditional when used on a row. This can be either tr element, or an element with role="row". These attributes can only be used when the row is part of treegrid. When used inside a table or grid, these attributes have no function, and could result in unpredictable behavior from screen readers and other assistive technologies.

What this Accessibility Rule Checks

Check that ARIA attributes are not used in a way that their role describes authors should not, or must not do. I.e the use of this ARIA attribute is conditional.

Values assigned to ARIA role values must not be deprecated.

Using deprecated WAI-ARIA roles is bad for accessibility. They will not be recognized or correctly processed by screen readers and other assistive technologies. Using these means not everyone will be able to access essential information.

Ensure all values assigned to role="" correspond to WAI-ARIA roles that are not deprecated, or abstract. The following list indicates for each deprecated role a potential alternative that is better supported by assistive technologies:

• directory: Consider using section, list, or tree instead. Which is most appropriate depends on how directory was used.

What this Accessibility Rule Checks

Check all elements containing WAI-ARIA role attribute to ensure that the role is not deprecated in the latest version of the WAI-ARIA specification.

Elements with aria-hidden must not contain focusable elements.

Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.

aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.

If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.

Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.

The rule applies to any element whose aria-hidden attribute value is true.

By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element. This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.

A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.

What this Accessibility Rule Checks

For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.

Ensures every ARIA input field has an accessible name.

This rule ensures that each ARIA input field has a name that is accessible.

There must be accessible names for the following input field roles:

• combobox
• listbox
• searchbox
• slider
• spinbutton
• textbox

What this Accessibility Rule Checks

The names of ARIA input fields must be accessible.

Not all ARIA role-attribute combinations are valid. Elements must only use permitted ARIA attributes.

Using ARIA attributes in roles where they are prohibited can mean that important information is not communicated to users of assistive technologies. Assistive technologies may also attempt to compensate for the issue, resulting in inconsistent and confusing behavior of these tools.

This Rule checks that noe of the attributes used with a particular role are listed as “prohibited” for that role in the latest version of WAI-ARIA.

The aria-label and aria-labelledby attributes are prohibited on presentation and none roles, as well as on text-like roles such as code, insertion, strong, etc.

What this Accessibility Rule Checks

Checks that each ARIA attribute used is not described as prohibited for that element’s role in the WAI-ARIA specification.

ARIA widget roles must contain attributes describing the widget’s state or properties.

ARIA widget roles necessitate additional properties describing the widget’s state. If a needed attribute is missing, the widget’s status is not conveyed to users of screen readers.

Some roles function as composite user interface widgets. As such, they serve as containers that manage the widgets they contain. When an object inherits from several ancestors and one ancestor indicates support for a property and another says the property is required, the property becomes required on the inheriting object. In some circumstances, default values are sufficient to meet ARIA attribute requirements.

When required state and property attributes for specific roles (and subclass roles) are missing, screen readers may be unable to communicate the element’s role definition to the user.

What this Accessibility Rule Checks

Checks all elements with the role attribute to ensure that all necessary attributes are defined.

Some ARIA role values in parent elements must contain specific child elements and role values in order to execute the intended accessibility function.

WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. ARIA roles lacking needed child roles will not be able to execute the desired accessibility functions.

The user’s context must be communicated by assistive technology. In a treeitem, for instance, it is essential to know the parent (container), item, and siblings in the folder. This is possible in two ways:

• Code order or DOM: The context required is frequently evident from the code order or DOM.
• ARIA: ARIA (such as aria-owns) can be used to provide relationships when the hierarchy differs from the code structure or the DOM tree.

What this Accessibility Rule Checks

Checks each element containing a WAI-ARIA role for the presence of all requisite child roles.

Certain ARIA roles must be enclosed by specific parent roles in order to carry out their intended accessibility functions.

WAI-ARIA outlines specifically, for each role, which child and parent roles are permitted and/or required. Elements with ARIA role values that lack needed parent element role values will prevent assistive technology from functioning as the developer intended.

When it is necessary to convey context to a 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, it is impossible to provide relationship information without using ARIA role parent elements.

What this Accessibility Rule Checks

Checks each WAI-ARIA role-containing element to confirm that all required parent roles are present.

Ensures that the aria-roledescription attribute is only applied to elements having explicit or implicit role values.

Inappropriate aria-roledescription attribute values that clash with an element’s implicit or explicit role value can impede the web page’s accessibility. A contradictory aria-roledescription attribute value may have no effect on the application’s accessibility and may trigger behavior that blocks accessibility for entire application sections.

When aria-roledescription attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, a semantic conflict may occur between the aria-roledescription value and the implicit or explicit element role value, resulting in assistive technology products reporting nonsensical user interface (UI) information that does not accurately represent the intended UI experience.

What this Accessibility Rule Checks

Use aria-roledescription values to adequately explain implicit or explicit element role values.

ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role values, and not be abstract roles in order to correctly display the element’s purpose.

Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.

When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.

What this Accessibility Rule Checks

Examines each element containing the WAI-ARIA role property to check that its value is valid.

Makes certain that each ARIA toggle field has an accessible name.

Ensures that any element having a semantic role has a name that is easily accessible.

Among the semantic roles are:

• checkbox
• menu
• menuitemcheckbox
• menuitemradio
• radio
• radiogroup
• switch

What this Accessibility Rule Checks

There is an accessible name for ARIA toggle fields.

Valid values must be present for ARIA properties that begin with aria-.

To fulfill the intended accessibility purpose, these values must be written correctly and relate to values that make sense for a certain property.

ARIA attributes (those beginning with aria-) must have legitimate values. For a given attribute to fulfill the intended accessibility function, these values must be written correctly and correlate to values that make sense.

A diverse range of values are accepted for many ARIA attributes. There must be permitted values, acceptable “undefined” values, and acceptable “default” values.

Content that does not adhere to the permitted values is inaccessible to users of assistive technology.

What this Accessibility Rule Checks

Verifies that the WAI-ARIA attributes’ values are correct for each element that contains them.

The names of ARIA attributes beginning with “aria-“ must be correct.

A reference to an invalid attribute or an attribute that doesn’t exist will result in a violation of this rule.

The accessibility function intended by the developer will not be fulfilled if the developer uses an invalid or misspelled ARIA attribute.

User interface components meant to increase the accessibility and interoperability of web and application content must adhere to properly worded and up-to-date ARIA properties in order for assistive technology to provide suitable information to people with disabilities.

Insufficient usage of the WAI-ARIA 1.1 W3C Recommendation’s attributes prevents developers from correctly communicating user interface actions and structural information to assistive technology in document-level markup.

What this Accessibility Rule Checks

Verifies that all elements that contain WAI-ARIA attributes have those attributes and that they are legitimate attributes.

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.

The list of 53 Input Purposes for User Interface Components are used as the basis for the programmatic definition of the purpose for each common input field that collects user data.

For screen readers to work properly, the autocomplete attribute values must be true and applied correctly.

Inaccessible content stems from missing autocomplete values in form fields. In the absence of the necessary autocomplete attribute values, screen readers will not read the identified autocomplete form fields.

When screen readers are unable to adequately notify users about the requirements for form field interaction, users cannot successfully navigate forms.

What this Accessibility Rule Checks

The purpose of each user-information-collecting input field can be established programmatically when:

• The input field fulfills a purpose specified in the Input Purposes for User Interface Components section, and
• The content is implemented using technologies that provide support for determining the desired meaning of form input data.

Ensure that the text spacing specified by style attributes is modifiable using custom stylesheets.

When lines of text are single-spaced, many people with cognitive difficulties have difficulty following them. Providing spacing between 1.5 and 2 makes it easier for them to begin a new line after finishing the previous one.

What this Accessibility Rule Checks

Text line spacing must be modifiable by custom stylesheets.

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.