Accessibility Checking for Large Sites

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.

The recommended practice is to keep all content, excluding skip links, in designated areas such the header, nav, main, and footer.

If the content is divided into several high-level divisions, screen reader users can navigate a website much more easily. Finding content that isn’t in parts can be challenging, and the item’s intent sometimes isn’t evident.

Some essential semantic markers, such as the ability to designate portions of the page as the header, navigation, primary content, and footer, were formerly absent from HTML. It is recommended to combine HTML5 elements with ARIA landmarks in a single element, but as browser support for HTML5 grows, using native HTML5 element regions will become more common.

What Checks This Accessibility Rule?

Ensures that a landmark region contains all of the content on a page.

For screen reader users to efficiently navigate tables, the scope element must be utilized correctly on tables in accordance with either HTML4 or HTML5 specifications.

If utilized properly, the scope feature greatly simplifies table navigation for screen reader users. When misused, scope can make table navigation far more difficult and ineffective.

The assumption made by a screen reader is that a table has a header that identifies a scope. Having an accurate header makes viewing a table for those who use screen readers far more accessible and effective due to the way the devices work.

What this Accessibility Rule Checks

Ensures that tables are correctly using the scope attribute.

In order to save viewers time, the website must contain a link at the top before the navigation that directs them directly to the page’s core content.

As it appears in the HTML file, screen readers read the text sequentially.

This has the effect of reading out to users of assistive technology the content at the top of the page, which normally includes the full navigation, before they can access any of the primary content. When a user is primarily interested in the main material, it might be time-consuming to listen to or navigate through all of the text at the top of the page because it is frequently very long.

Users who are blind, have low eyesight, or only use the mouse will benefit from an HTML website having a skip link.

What this Accessibility Rule Checks

Ensures that programmers adhere to the best practice of placing a skip link as the page’s very first link.

To avoid an unexpected tab order that would appear to miss some components entirely, a tabindex attribute must never have a value greater than 0.

tabindex usage with a value larger than 0 can lead to just as many issues as it fixes. The unusual tab order makes the website less logical and may give the impression that some elements have been completely skipped.

The following are some issues that tabindex (with a value of 1 or above) results in:

• Unexpected tab order: From the user’s perspective, tabindex alters the normal tab order in unanticipated ways, which could lead to confusion.

• Items can appear to be skipped entirely: Items only once appear in the tab sequence. When a user navigates through the tabindex items and moves on to the rest of the page, they eventually reach the location of the tabindex items. However, the tabbing cycle skips over these links because the user already navigated past them at the start of the cycle. When visitors are unable to access items and may be unaware that they must cycle through the complete collection of links on the page to reaccess those links, incorrect tab ordering are frustrating.

• All tabindex items are tabbed to before any non-tabindex items. You would need to set the tabindex value for each and every item through the end of the updated section if you wanted to modify the tab order of the initial items AND of a section further down the page. When taken to an extreme, if a page contains 20 links and one of those links has its tabindex set to tabindex="100", the user will tab to that link first even if there are fewer than 100 links on the page. The tab order of sections further down the page cannot be changed unless all the links before that section’s tab order are manually changed.

What this Accessibility Rule Checks

Makes sure that explicit tabindex attributes that are greater than 0 are never used

Markup for data tables can be tedious and complex. Make sure the summary table’s properties and the caption don’t match. There are several capabilities in screen readers that help with table navigation, but for these features to function properly, the tables must be accurately marked up.

Tables are announced in a certain way by screen readers. The potential for unclear or erroneous screen reader output exists when tables are not properly marked up.

Screen reader users may become perplexed and struggle to understand the name and function of the table if the summary and caption text for the table are identical.

What this Accessibility Rule Checks

Verifies that the wording in data tables that have both a summary and a caption is not the same.