Accessibility Guide for WCAG 2.0 (A)
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.
For multilingual screen reader users who would prefer a language other than the default, the HTML document element must have a valid lang
property or match to a valid lang
code.
The default language is chosen by users when setting up a screen reader. The screen reader uses the user’s default language preference when a webpage’s language is not specified. When people visit websites in more than one language and speak various languages, language settings become a problem. To ensure that website text is pronounced accurately, a language must be specified and validated.
Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the documents state which language(s) to read when, screen readers can effortlessly switch between these language libraries. The screen reader will read the page in the user’s default language if the language is not set, which will result in an odd accent. When screen readers are utilizing the incorrect language library, nothing can be understood.
What this Accessibility Rule Checks
Ensures that the lang
attribute is present in every HTML document.
For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang
attribute or correlate to a valid lang
code.
Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Language settings are a problem for users who speak different languages and visit websites in multiple languages. It is critical to declare a language and guarantee that it is valid in order for website text to be properly pronounced.
Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can readily switch between these language libraries, but only if the documents specify which language(s) they should read. If no language is supplied, the screen reader reads the content in the user’s default language, which results in a perplexing accent! When screen readers use the incorrect language library, it is difficult to understand anything.
What this Accessibility Rule Checks
Ensures that every HTML document contains a lang
or xml:lang
property with a valid value.
For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang
attribute or correlate to a valid lang
code. If included on the html
element, the xml:lang
property value must exactly duplicate the value of the lang
.
Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Users who speak and access websites in various languages have difficulties. For screen readers to function properly, a default language must be specified and ensured to be valid.
Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can simply switch between language libraries if documents specify which language(s) should be read. Screen readers view texts in the user’s default language if the language is not specified, resulting in distorted language. When screen readers use the incorrect language library, it can be difficult to understand anything.
What this Accessibility Rule Checks
Ensures that every HTML document includes a valid lang
attribute, and that the xml:lang
value, if present, replicates the lang value.
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.
Makes sure that people who can’t differentiate colors can tell when text is a link by checking that the link has either a distinct style that doesn’t depend on color or a contrast difference of more than 3:1, which tells you that manual testing is needed.
Some people with low vision have low contrast, which means there aren’t many bright or dark areas. Everything looks about the same brightness, which makes it hard to see details, edges, borders, and outlines. It can be hard to read text that is the same brightness as the background.
There are almost three times as many people with low vision as there are who are totally blind. One in twelve people, or about 8% of men and 0.4% of women in the US, has a color deficiency. People with low vision or color blindness can’t tell what the text is against a background that doesn’t have enough contrast.
When there isn’t a 3:1 color contrast between the color of the link text and the color of the text around it, people with low vision or low contrast can’t tell by looking that the text is meant to be a link.
What this Accessibility Rule Checks
Checks that all links in blocks of text have a color difference of at least 3:1 from the text around them, so that people who can’t tell the colors apart can still find the link.
This rule looks at some of the most common ways to tell a link from the text around it, such as underlining, font styling, a border, or a background. No rule has been broken if the link has its own style that doesn’t depend on color (pass). There is a violation if the link doesn’t have a clear style and the contrast is less than 3:1. (fail). When the link doesn’t have a distinct style and the contrast difference is 3:1 or higher, you must check that the link has a distinct style when you focus on it or hover over it. This can’t be reliably done by a computer, so you have to do it by hand.
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. Addtabindex="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.