Accessibility Guide for blind
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).
When button and link text in an alt
property value repeats, screen reader users hear the same information twice, rendering the alt text worthless and confusing.
It is redundant and potentially misleading to have alternate text for a link or image repeated in text adjacent to the link or image because a screen reader would read it twice.
Because image buttons employ alt
attributes for labels, the labels should not repeat the text next to the button. Screen readers announce the text to the user twice when there is duplicate alternative text for an image or link in the text adjacent to that image or link.
What this Accessibility Rule Checks
Make certain that the button and link text are not repeated as picture alternatives.
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.
The visible label of interactive items labeled through their content must be included in their accessible name.
This rule applies to any element with the following attributes:
- a semantic role that is a widget that supports name from content,
- visible text, and
-
an
aria-label
oraria-labelledby
attribute.
button
, checkbox
, gridcell
, link
, menuitem
, menuitemcheckbox
, menuitemradio
, option
, radio
, searchbox
, switch
, tab
, and treeitem
are widget roles that support name from content.
The whole visible text content of the target element either matches its accessible name or is contained within it.
Leading and trailing whitespace and case sensitivity differences should be disregarded.
Users using speech input can interact with a web page by saying the visible text labels of menus, links, and buttons.
Voice input users are confused when they utter a visible text label, but the speech command does not work since the accessible (programmatic) name of the component does not match the visible label. When a user interface component contains a visible text label — whether the label is actual text or a picture of text — that text must also appear in the component’s accessible (programmatic) name. When the visual label and accessible (programmatic) name for interactive components are synchronized, users using speech input can engage with those components successfully.
What this Accessibility Rule Checks
For any user interface element with a visible text label, the accessible name must match (or include) the label’s visible text.
Using the title
or aria-describedby
properties, form <input>
elements may be given titles (but not both).
The purpose of these qualities is to convey more information, such as a tip.
These properties are used to convey additional information, such as a hint. Hints are exposed differently to accessibility APIs than labels, which can cause issues with assistive technologies.
When form inputs such as text entry fields, radio buttons, check boxes, and select menus do not have labels other than the title
and aria-describedby
attribute values, screen readers perceive the material as advisory only. The labels provided by the title
and aria-describedby
attributes are insufficient to create a real label that can be inferred programmatically from the input form element’s code.
What this Accessibility Rule Checks
Ensures that every <input>
that requires a label has a label other than title
or aria-describedby
.
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.
Banner landmark cannot be nested within another landmark.
If the banner landmark is not the top-level landmark (and is located within another landmark), it does not effectively designate the pre-defined header area of the layout, preventing screen reader users from navigating the layout with ease.
Landmarks are utilized to denote areas of the overall page layout and design. Utilizing headings to identify parts within the article.
What this Accessibility Rule Checks
This rule identifies (banner / contentinfo) landmarks and walks up the document’s structure to ensure that no more landmark roles are met before reaching the body.
Ensures the complementary landmark or aside is at top level.
Complementary content is content that supports the primary idea of a page or document. Users of screen readers have the option to bypass supplemental content that shows at the accessibility API’s top level. Embedding an <aside>
element within another landmark may prevent the ability for screen reader users to browse through supplemental content.
What this Accessibility Rule Checks
Do not insert <aside>
elements or elements containing role="complementary"
inside landmark-marked content.
The contentinfo
landmark must be at top level.
Placement of the contentinfo
landmark within another landmark can contradict its purpose by preventing blind screen reader users from rapidly locating and navigating to the intended landmark.
It defeats the purpose of an existing contentinfo
landmark when screen reader users must wade through too much extra information to discover what they seek, such as not being able to quickly determine which landmark provides the content information they seek.
What this Accessibility Rule Checks
This rule locates the components corresponding to the footer:not([role])
and [role="contentinfo"]
selectors, and then tests whether the landmark has a body context.
Best practice dictates that the primary landmark should not be enclosed within another landmark. All content must be contained within discrete areas, such as the header (role="banner"
), body (role="main"
), and footer (role="contentinfo"
).
Screen reader users can navigate a website much more easily if the content is divided into several high-level categories. It is difficult to locate content outside of these categories, and its purpose may be obscure.
Historically, HTML lacked essential semantic markers, such as the ability to define page sections as the header, navigation, primary content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered an excellent practice, but as browser compatibility improves, HTML regions will likely become more popular in the future.
HTML Living Standard says “A hierarchically correct main element is one whose ancestor elements are limited to <html>
, <body>
, <div>
, <form>
without an accessible name, and autonomous custom elements. Each main element must be a hierarchically correct main element”. This may be a “recommended practice” according to W3C validation.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
Ensures there is only one banner landmark at most on the page.
Landmarks enable blind people to navigate and rapidly locate content. In the absence of landmarks, screen reader users must wade through too much unnecessary information to locate anything.
JAWS, NVDA, and VoiceOver all support using ARIA landmarks to navigate to specific portions of a web page. Landmarks offer a more elegant answer to the challenge of offering a way for readers to bypass the page’s main content. There is no visible change to the website’s layout, making it inconspicuous and undetectable. Obviously, the fact that this technique is invisible is advantageous for users of screen readers, but not for sighted keyboard users or users of screen magnifiers with impaired eyesight. In this sense, HTML 5 regions and ARIA landmarks cannot replace the conventional “skip navigation” links just yet.
There is presently no method built into browsers to alert users when HTML 5 regions or ARIA landmarks are available. Users of screen readers are the only ones who can benefit from them. There is a Firefox ARIA landmark extension that provides landmark navigation to Firefox, however this is not a native browser capability.
What this Accessibility Rule Checks
This rule locates all banner landmarks, filters out those that do not correspond to their job, and checks that there is only one.
Makes sure there is only one contentinfo
landmark on the page.
You should keep the overall number of landmarks reasonably limited because one of their key functions is to help blind users locate and navigate to the proper landmark fast. Screen reader users will have to sift through too much unnecessary information if you don’t in order to find what they need.
Despite all the discussion about utilizing proper semantic structure for accessibility, HTML historically lacked some essential semantic markers, such as the ability to designate areas of the page as the header, navigation, main content, and footer. These designations are now feasible with HTML5 thanks to the new elements header
, nav
, main
, and footer
. The ARIA (Accessible Rich Internet Application) properties role="banner"
, role="navigation"
, role="main"
, and role="contentinfo"
all provide similar capabilities.
ARIA landmarks can be used to navigate to specific web page areas in JAWS, NVDA, and VoiceOver. The issue of giving consumers an option to skip to the website’s primary material is addressed more tastefully by landmarks. The web design has not changed noticeably, making it invisible and undetectable. The fact that this method is invisible is obviously good for blind screen reader users, but it’s not so great for sighted keyboard users or people with impaired vision who use screen enlargers. In this sense, the traditional “skip navigation” links cannot yet be replaced with HTML 5 regions and ARIA landmarks.
Users are still unable to receive notifications from browsers that HTML 5 regions or ARIA landmarks are present. Only those who use screen readers can benefit from them. It is not a built-in capability of the browser, but there is a Firefox ARIA landmark extension that provides the ability to navigate by landmarks in Firefox.
What this Accessibility Rule Checks
This rule locates every contentinfo
landmark, eliminates any that do not map their role, and confirms that there is only one.
The core content of the page should only have one main landmark, and if the page contains iframe
components, each one should either have no landmarks or just one. This is considered best practice.
If all of the content is divided up into one or more high-level divisions, screen reader users will have much easier time navigating a website. Outside of these categories, information can be hard to access and has an uncertain purpose.
Some essential semantic markers, such the ability to designate portions of the page as the header, navigation, primary content, and footer, have historically been absent from HTML. Although it’s recommended to combine HTML5 elements with ARIA markers in a single element, HTML regions will eventually prevail as browser support grows.
What this Accessibility Rule Checks
Makes sure there is just one primary landmark in the document.
A best practice is to guarantee that there is only one primary landmark for navigating to the page’s principal content, and if the page has iframe
components, each should contain either no landmarks or a single landmark.
If a website’s material is divided into one or more high-level parts, screen reader users will find it much easier to navigate. It is difficult to locate content outside of these categories, and its purpose may be obscure.
Historically, HTML lacked essential semantic markers, such as the ability to define page sections as the header, navigation, primary content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is a best practice, but as browser support grows, the future will favor HTML areas.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
Landmarks must have an unique role or role/label/title (i.e. accessible name) combination.
landmark-unique
is a new best practice rule ensuring that landmarks have an unique role or accessible name (i.e. role, label, title) combination.
What this Accessibility Rule Checks
Ensures landmarks are unique.
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.
Lists must be correctly marked up, which means they cannot contain content components other than li
elements.
Lists are read aloud in a specific manner by screen readers. This feature makes lists easier to comprehend, but it will only function if the lists are correctly organized.
When content elements other than list items are contained within a set of list elements, screen readers are unable to indicate to the user that they are listening to list items.
Any other content elements are invalid.
Although non-content elements such as script
, template
, style
, meta
, link
, map
, area
, and datalist
are allowed in lists, content elements other than li
are not.
What this Accessibility Rule Checks
Ensures that lists are properly constructed.
All list items (li
) must have ul
or ol
parent elements.
To be considered valid, a list must have both parent and child entries. Element parents may consist of either a set of ul
or ol
tags. Within these tags, child elements must be declared using the li
tag.
Screen readers alert users when they arrive at a list and inform them of its length. Announcing the number of items in a list and the current item helps listeners understand what they are hearing and what to anticipate as they continue to listen.
If you do not mark up a list with the correct semantic markup in a hierarchy, list elements cannot alert the listener that they are listening to a list if no parent indicates the presence of a list and its type.
What this Accessibility Rule Checks
Ensures li
elements are used in a semantic way.
Remove the http-equiv="refresh"
attribute from each meta
element in which it is present.
Example of invalid code:
<meta http-equiv="refresh" content="60" url="http://example.com/index.html">
Automatic page refreshing can be disorienting for users since they do not anticipate it. Moreover, refreshing the page causes the focus to reset to the top of the page, resulting in user frustration.
Redirection and page refreshing using the <meta>
element can cause issues for users with disabilities. The primary reason for this is the lack of user control over the timing of the redirection or refresh. If the goal of the <meta>
element is to redirect users to a new location, server-side methods should be used instead of client-side methods. Moving or updating content can present challenges for users who struggle to read stationary text quickly or track moving objects, and it can also cause difficulties for screen readers.
If the intention of the <meta>
element is to refresh the page, it is recommended to handle it using JavaScript. Additionally, incorporate additional scripting to provide users with options to pause the refresh, increase the time between refreshes, or disable the refresh entirely.
What this Accessibility Rule Checks
Checks for the presence of the http-equiv=”refresh” attribute on the meta elements.
The document must not use <meta http-equiv="refresh">
with a refresh time of less than 20 hours, as this could prohibit users with disabilities from controlling when the page is refreshed.
Since consumers do not anticipate a page to immediately reload, this behavior might be unsettling. Reloading also returns the programmatic emphasis to the page’s top, away from where the user had it. Such resets are irritating to users.
Redirection and page refresh via the <meta>
element are problematic for users with impairments in a number of ways. Redirects and refreshes are problematic for the primary reason that the user has no control over when they occur. If the objective of the <meta>
element is to redirect the user to a new location, server-side rather than client-side procedures should be implemented. Moving or auto-updating content might be a hindrance for those who have problems reading stationary material fast and for those who have trouble monitoring moving objects. It can also present difficulties for screen readers.
What this Accessibility Rule Checks
Examines whether the http-equiv="refresh"
attribute is present on meta
elements with a content
value of less than 20 hours.
Screen readers do not announce nested interactive controls.
Screen readers do not notify focusable components with interactive control ancestors (any element that accepts user input, such as buttons or anchor elements) and they produce an empty tab stop. In other words, even if you tab to the element, the screen reader won’t say its name, function, or status.
What this Accessibility Rule Checks
Ensure that no focusable child elements are present in any interactive controls.
Ensures that video
or audio
elements don’t have autoplay audio that lasts more than three seconds without a way to silence it.
When using screen reading software, people who are blind or have low vision may have trouble hearing the screen reader’s spoken output if other audio is playing at the same time.
If automatically playing audio continues for more than three seconds, it must be possible to pause, stop, or adjust the level using a well placed, easily accessible mechanism.
Users of screen readers can hear the screen reader without any other sounds playing thanks to an audio control.
A screen reader user’s ability to find the stop button may be hampered if audio starts playing immediately when they land on a page. This is because they navigate by listening, and automatically starting sounds may obstruct that navigation.
Therefore, we oppose the practice of automatically starting sounds (especially if they run longer than three seconds) and encourage users to start the sound themselves once they arrive at the page rather than expecting them to stop the sound themselves once they have reached the page.
What this Accessibility Rule Checks
The algorithm for this rule returns:
-
Undefined when
<audio>
has no source (duration cannot be interpreted). -
Undefined when
<video>
has no source (duration cannot be interpreted). -
False when
<audio>
can autoplay and has no controls mechanism. -
False when
<video>
can autoplay and has no controls mechanism -
False when
<audio>
plays less than three seconds but loops. -
True when
<video>
can autoplay and duration is less than three seconds (by passing options). -
True when
<video>
can autoplay and duration is below allowed duration (by setting playback range). -
True when
<audio>
can autoplay but has controls mechanism. -
True when
<video>
can autoplay and has controls mechanism.
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.
Since screen reader users cannot otherwise determine the structure of the document, styled p
components must not be utilized to represent headings.
The fundamental goal of headers is to communicate the page’s organizational structure. Using varied text sizes allows sighted readers to see the structure. However, heading components must be marked up properly for screen reader users.
When header components are used correctly, both sighted and screen reader users will find it much simpler to traverse the page.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Headings serve to explain the organization of the webpage, not only to draw attention to key text. They must be succinct, distinct, and numbered h1
through h6
in hierarchical sequence. For screen reader users, headers are a useful tool because of all of these characteristics.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Due to the fact that search engines use headings when filtering, arranging, and showing results, headers offer advantages beyond just making a page more accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Verifies that paragraph components are not given the appearance of headers by using italic, bold, or font size.