Accessibility Guide for WCAG 2.0 (A)
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. 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.
A track element with the property set to kind="captions" is required for an HTML5 video element. For deaf viewers, the captions must include all audible cues from the video, such as dialogue, musical cues, sound effects, and other pertinent information.
Users who are hard of hearing have limited or no access to a video’s content if it lacks a caption. Even if there is a captioning track, make sure it includes all of the video’s important content and not just the dialogue.
Without captions, deaf viewers are able to see everything in the video but are unable to hear anything. The dialogue, narration, and other crucial sounds that are not spoken by people—such as “dramatic instrumental music,” clapping, screaming, or other sounds that create the scene, provide context, or otherwise give meaning to the video—are not audible to deaf viewers without a caption track.
What this Accessibility Rule Checks
Makes sure all video elements have captions.