Accessibility Guide for sighted keyboard users
The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.
Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.
What this Accessibility Rule Checks
Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.
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.
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.
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.
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.
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.
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"]