Accessibility Guide

Check that all links with the same accessible name fulfill the same function.

This guideline is significant since the goal is to assist viewers in understanding the purpose of each link in the material so they may determine whether or not to follow it. Links with the same destination should have the same descriptions, but links with different purposes and destinations should have different descriptions (see also Success Criterion 3.2.4), which calls for consistency in identifying components with the same functionality). Links can be understood when they are out of context, such as when the user agent presents a list of all the links on a page, because the purpose of a link can be inferred from its link text.

What this Accessibility Rule Checks

This rule’s algorithm yields:

• Undefined for a native link with the href attribute but no visible name.
• Undefined when there is no accessible name for an ARIA link.
• Undefined when the accessible name of an ARIA link is merely a collection of unicode (emoji, punctuation, nonBmp) characters.
• True for native links with an accessible name and a href attribute value.
• True for ARIA links with accessible names (for example, a area with map used in a image element).
• True for native links having href attribute values and a name that can be found (that also has emoji, nonBmp and punctuation characters).

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 or aria-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.

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. Add tabindex="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.

Elements of type <marquee> are prohibited because they are deprecated, add difficulty for users with limited dexterity, and distract users with cognitive or attention problems.

The marquee element produces difficult-to-read and-click-on scrolling text. Furthermore, it can be disturbing to viewers, particularly those with low eyesight, cognitive impairments, or concentration difficulties.

People with attention difficulties or cognitive impairments may be distracted by scrolling content. People with inadequate fine motor skills may not be able to precisely click on links inside scrolling content. Users with visual impairments may not be able to read the content of the scrolling text with sufficient clarity.

What this Accessibility Rule Checks

Prevents the use of the deprecated marquee element.

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.

The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.

The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.

The maximum-scale setting restricts the user’s ability to zoom. This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.

Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. If the user maximizes the browser on a high-resolution display, the viewport’s focus area is expansive and may encompass the entire online page.

If the browser window is small, only a small portion of the web page is visible in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to build pages to enable resizing up to 200%; nevertheless, it is considered best practice to demand a 5x zoom.

What this Accessibility Rule Checks

Ensures that the user-scalable="no" parameter is absent from the <meta name="viewport"> element, and that the maximum-scale parameter is greater than or equal to 500%