Accessibility Guide for Deque Best Practice
A document’s accesskey attribute values must all be distinct. Or, to put it another way, accesskeys must not be used more than once to protect keyboard users from unpleasant surprises.
When a document’s accesskey attribute value is supplied, users can quickly activate or switch the focus to a particular element by hitting the designated key (often in tandem with the alt key). The page becomes less accessible as a result of duplicating the values for the accesskey attribute.
Make sure the value of each defined accesskey is distinct and does not interfere with any screen reader or default browser shortcut keys.
Users who must use alternative keyboards or input devices serving as keyboard emulators, users who have problems tracking a pointer, or users who are blind or have low eyesight and cannot employ eye-hand coordination-required devices like mice, cannot operate the content.
What this Accessibility Rule Checks
Makes certain that every element on the page with an accesskey attribute has a different value.
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.
For screen reader users, Aria dialog items must include intelligible language that specifies the destination, purpose, function, or action in detail.
Elements with role="dialog" or role="alertdialog" that lack an accessible name cannot be understood by screen reader users.
What this Accessibility Rule Checks
Verifies that all objects with the role="dialog" or role="alertdialog" attribute have a clear, understandable name.
No focusable children are allowed on elements with the role="text" attribute.
When a text node is split by markup (for example, <h1>Good morning, <span>friend</span></h1>)
VoiceOver will treat it as two distinct phrases rather than one. Adding role="text" to the elements circumvents the issue.
In addition, it overrides the role of the element and its descendants, treating them as text nodes. If one of the descendant items is also focusable, an empty tab stop will be generated. That is, you might tab to the element but VoiceOver would not announce its name, role, or value.
What this Accessibility Rule Checks
Checks each element with the role="text" attribute to guarantee that none of its children are focusable.
The destination, purpose, function, or action of an Aria treeitem element must be made clear in the element’s understandable text for screen reader users.
Users of screen readers are unable to determine the function of items with the role treeitem that lack an accessible name.
What this Accessibility Rule Checks
Ensures that all objects with the role treeitem have a clear, understandable name.
It is a best practice to make sure each heading element, denoted by the tags <h1> through <h6>, contains text.
Users of screen readers are informed when a heading tag is present. Users may become confused or even unable to access information on the page’s structure if the headline is blank or the text cannot be accessible.
Users of this technology won’t be able to hear the content of a header if the text inside it is inaccessible to a screen reader. Users using screen readers must be able to access the contents since headings reveal the structure of a webpage.
Applying header markup (<h1> through <h6>) is a quick approach to make content stand out, but doing so will make it more difficult for those using assistive technology to navigate a website.
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.
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.
What this Accessibility Rule Checks
Ensures that headings have content and that a screen reader can access that content.
The text in table header components should be visible. Make sure screen reader users can access the table header. It is preferable to mark up an element with a td if it is not a header.
Both sighted users and screen reader users should be able to comprehend the visible text that explains the purpose of the row or column in table header components.
What this Accessibility Rule Checks
Verifies that each table header element has a visible text.
Whether native HTML or a custom widget, user input elements need to play the right roles in order to make their meaning clear to screen reader users when they are focused on and landed on. If a custom widget, the element’s function must be correctly exposed by using appropriate ARIA role values rather than abstract roles.
In order for screen reader technology to convey information to users, elements in the focus order must play a function appropriate for interactive content.
If interactive content elements do not have the proper roles, the developer’s planned accessibility function cannot be carried out by the role.
When screen readers and other assistive technologies cannot communicate to the user the proper role of each element on the web page, they are unable to interact with it sensibly. Assistive technology cannot communicate with an HTML element’s set of features, properties, and ways of communicating information to and/or from the user when the value for a role is invalid.
What this Accessibility Rule Checks
Verifies that the role attribute value is accurate and suitable for all interactive components in the focus order, regardless of whether they are native HTML or customized ARIA widgets.
Tests with axe-core are required for frames.
The tool cannot do violation testing on numerous levels of nested iframes without the axe-core script.
What this Accessibility Rule Checks
Axe is instructed to run within iframes when the iframes property is set to true. This checks for the axe-core script to deliver a “review item” result using both frame and iframe selectors.
The h1 through h6 element tags must be in a sequentially-descending order for headings to be in a correct logical order.
The fundamental goal of headers is to communicate the page’s organizational structure. The same goal is served by employing various font sizes for sighted users.
For screen reader users, however, text size is useless because a screen reader can only recognize a header if it is correctly marked up. 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 ought to be succinct, distinct, and accompanied by h1 through h6 components used in hierarchical order. Headings are useful tools for screen reader users because of all of these characteristics. Screen reader users can move among headings in a manner akin to how sighted readers can quickly scan a page and get a sense of its content. Screen readers can save time and stress by using headings that are clearly written and arranged.
Since search engines employ headings when filtering, arranging, and showing results, headings offer other advantages outside just making the page more easily accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Ensures the semantic accuracy of the headings’ order.
Notifies users of content that is hidden and unable to be checked for accessibility issues.
It is impossible to automatically check hidden content for accessibility rules breaches.
Screen reader users and sighted people must both be able to view visually hidden content. When content needs to be hidden from seeing users for a compelling reason, it is typically also necessary to hide it from blind users for the same reason. Making the content accessible to blind users makes sense when it is already available to sighted users.
When the CSS values display: none or visibility: hidden are used, content will be hidden from screen reader users (and all sighted users as well). The items become accessible to screen reader users when CSS properties are changed to display: block, display: inline, or other display values.
What this Accessibility Rule Checks
Checks for the presence of the hidden item content CSS style property values of display: none and visibility: hidden, and notifies users of their presence.
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.
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.
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.
Make 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.
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%
To enable screen reader users to navigate the heading structure with keyboard shortcuts rather than wasting time listening to more of the website to understand its structure, make sure the page, or at least one of its frames, contains a h1 element that appears before the start of the main content.
Users of screen readers can utilize keyboard keys to move straight to the first h1, which should, in theory, let them access the web page’s main content. Screen reader users must listen to more of the website in order to understand its structure if there is no h1 or if it appears elsewhere other than at the start of the main material, wasting significant time.
Keep in mind that unlike a visual user, a blind user cannot just glance at a web page and comprehend its layout. Without reading the entire material, visual users can learn a lot about the website layout. Users who are blind do not have such option. Unless there is another convenient way to gain a “glimpse,” screen readers read sequentially, which requires listening to the entire web page. It turns out that one method to do that is to use headers. Keyboard shortcuts can be used by screen reader users to move around a document’s heading hierarchy.
What this Accessibility Rule Checks
This rule locates every element that matches the subsequent selector and confirms that there is at least one of them: h1:not([role]), [role="heading"][aria-level="1"]
Checks to make sure elements selected for removal from the accessibility tree are really deleted.
In some circumstances, an element having a semantic role of none or presentation does not resolve to none or presentation (respectively).
This prevents the element from being eliminated from the accessibility tree, as would be expected, and allows screen readers to interact with it.
You shouldn’t focus the element or give it any global ARIA attributes in order to keep the element out of the accessibility tree.
What this Accessibility Rule Checks
Checks every element with role=“none” or role=“presentation” to ensure they do not have a global ARIA attribute and are not focusable.