Accessibility Checking for Large Sites

All accesskey attribute values in a document must be unique. Put another way, accesskeys must not be repeated to prevent unexpected effects for keyboard users.

Specifying a accesskey attribute value for some part of a document allows users to quickly activate or move the focus to a specific element by pressing the specified key (usually in combination with the alt key). Duplicating accesskey values creates unexpected effects that ultimately make the page less accessible.

For each defined accesskey, ensure the value is unique and does not conflict with any default browser and screen reader shortcut keys.

Content is not operable by keyboard users with no or low vision who cannot use devices such as mice that require eye-hand coordination, users who have trouble tracking a pointer, or users who must use alternate keyboards or input devices acting as keyboard emulators.

Values assigned to WAI-ARIA role attributes must be valid. This means values must be spelled correctly, correspond to existing ARIA role values, and must not be abstract roles in order to correctly expose the purpose of the element.

Intended accessible technology behavior by a developer is not enabled when an assigned WAI-ARIA role value is invalid for the parent element.

When screen readers and other assistive technologies do not know the role of each element on the web page, they are not able to interact with it intelligently, nor are they able to communicate the role to the user. When the value for a role is invalid, there is no way to communicate the element's features, properties, and methods to assistive technologies. For example, applying role="table" to a <ul> effectively hijacks the default semantics associated with the <ul> element in a way that screenreaders do not expect resulting in unexpected behavior.

Aria dialog elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.

Screen reader users are not able to discern the purpose of elements with role="dialog" or role="alertdialog" that do not have an accessible name.

Elements with role="text" must not have focusable descendants.

When a text node is split by markup (e.g. <h1>Hello <span>World</span></h1>) VoiceOver will treat it as two separate phrases instead of just one. Adding role="text" around the elements solves the problem. However, it also overrides the role of the element and all descendants and treats them all as text nodes. If one of the descendant elements is also focusable it would create an empty tab stop. That is, you could tab to the element but VoiceOver would not announce its name, role, or value.

Aria treeitem elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.

Screen reader users are not able to discern the purpose of elements with role="treeitem" that do not have an accessible name.

When at least one heading element (marked by <h1> through <h6>) is present, it is a best practice to ensure it contains content.

Screen readers alert users to the presence of a heading tag. If the heading is empty or the text cannot be accessed, this could either confuse users or even prevent them from accessing information on the page's structure.

If the text inside a heading cannot be accessed by a screen reader, users of this technology will not be able to hear the contents of the heading. Since headings relay the structure of a webpage, it's crucial that users of screen readers are able to access the contents.

Applying heading markup (<h1> through ><h6>) is a quick way to make text stand out, however, using it for anything other than headings will make navigating a web page more confusing for users of assistive technology.

In addition to making the page more accessible, headings have other benefits, since search engines use headings when filtering, ordering, and displaying results. Improving the accessibility of your site can also have the effect of making your page more findable.

In the same way that sighted users can glance at a page and get a sense of its contents, users of screen readers can do the same by navigating through headings. Well written and properly ordered headings can save users, especially those who use screen readers, a lot of time and frustration.

User input elements must have appropriate roles, whether native HTML or a custom widget, to convey to screen reader users their meaning when landed on and given focus. If a custom widget, appropriate ARIA role values must be used instead of abstract roles to correctly expose the purpose of the element.

Elements in the focus order need a role appropriate for interactive content so that screen reader technology can communicate that information to users.

If interactive content elements do not have appropriate roles, the role will not be able to perform the accessibility function intended by the developer.

When screen readers and other assistive technologies do not know the appropriate role of each element on the web page, they are not able to interact with it intelligently, nor are they able to communicate the role to the user. When the value for a role is not valid, there is no way the HTML element's set of features, properties, and methods of conveying information to and/or from the user can be communicated via assistive technologies.

Frames must be tested with axe-core.

Without the axe-core script, it is not possible for the tool to perform violation checking on multiple levels of nested iframes.

All frame or iframe elements in the document must have a unique title to describe their contents to screen reader users.

Screen reader users rely on a frame title to describe the contents of the frame. Navigating through frames and iframes can quickly become difficult and confusing for users of this technology if the frames are not marked with a title attribute.

Screen reader users have the option to pull up a list of titles for all frames on a page. Adding descriptive, unique titles allows users to quickly find the frame they need. If no titles are present, navigating through frames can quickly become difficult and confusing. If no title is listed, screen readers will instead give information like “frame,” “javascript,” the filename, or the URL. In most cases, this information won’t be very helpful.

Headings must be in a valid logical order, meaning h1 through h6 element tags must appear in a sequentially-descending order.

The underlying purpose of headers is to convey the structure of the page. For sighted users, the same purpose is achieved using different sizes of text. Text size, however, is not helpful for users of screen readers, because a screen reader identifies a header only if it is properly marked-up. When heading elements are applied correctly, the page becomes much easier to navigate for screen reader users and sighted users alike.

In the same way that sighted users can glance at a page and get a sense of its contents, users of screen readers can do the same by navigating through headings. Well written and properly ordered headings can save users, especially those who use screen readers, a lot of time and frustration.

The purpose of headings is to describe the structure of the webpage, not just highlight important text. They should be brief, clear, unique, and marked with h1 through h6 elements applied in hierarchical order. All of these qualities make headings valuable tools for screen reader users. Similar to the way sighted users can glance at a page and get a sense of its contents, screen reader users can navigate through headings. Well written and properly ordered headings can save screen reader time and frustration.

In addition to making the page more accessible, headings have other benefits since search engines use headings when filtering, ordering, and displaying results. Improving the accessibility of your site can also have the effect of making your page more findable.

Informs users about hidden content that cannot be analyzed for accessibility violations.

Hidden content cannot be automatically analyzed for accessibility rule violations.

Visually hidden content must be accessible by both sighted and screen reader users. If there is a compelling reason to hide content from sighted users, there is usually a compelling reason also to hide that content from blind users. When the content is made available to sighted users, it makes sense to make it available to blind users as well.

Content will be hidden from screen reader users (and all sighted users too) when the CSS properties display: none or visibility: hidden are used. Changing CSS properties to display: block, display: inline, or using other display values makes the items available to screen reader users.

When button and link text repeats in a alt attribute value, screen reader users hear the same information twice, which renders the alt text meaningless and confusing.

It is unnecessary and potentially confusing to have alternative text for a link or image to be repeated in text adjacent to the link or image since it would be read twice by a screen reader.

Since image buttons use alt attributes for labels, the labels must not duplicate the text next to the button. Duplicated alternative text for an image or link in the text adjacent to that image or link results in screen readers announcing the text to the user twice.

Form <input> elements may be given a title using the title or aria-describedby attributes (but not both). These attributes are used to provide additional information such as a hint.

The title and aria-describedby attributes are used to provide additional information such as a hint. Hints are exposed to accessibility APIs differently than labels and as such, this can cause problems with assistive technologies.

When form inputs such as text entry fields, radio buttons, check boxes, and select menus contain no labels other than title and aria-describedby attribute values, screen readers interpret the content as advisory information only. Labels created by the title and aria-describedby values are not sufficient to create a true label that can be determined programmatically from the code to convey the purpose of the input form element.

Banner landmark must not be contained in another landmark.

If the banner landmark is not the top-level landmark (and is contained within another landmark), it does not effectively designate the pre-defined header portion of the layout in the design and therefore prevents screen reader users from being able to easily find their way around the layout.

Ensures the complementary landmark or aside is at top level

Complementary content is ancillary content to the main theme of a document or page. Screen reader users have the option to skip over complementary content when it appears at the top level of the accessibility API. Embedding an <aside> element in another landmark may disable screen reader functionality allowing users to navigate through complementary content.

Contentinfo landmark must be at top level.

The purpose of the contentinfo landmark can be defeated when placed within another landmark, as it can prevent blind screen reader users from being able to quickly find and navigate to the appropriate landmark.

When screen reader users have to sort through too much extra information to find what they're looking for, such as not being able to quickly figure out which landmark contains the content information they're looking for negates the purpose of an existing contentinfo landmark.

It is a best practice to ensure the main landmark is not contained within another landmark. All content should be contained within distinct regions such as the header (role="banner"), content (role="main"), and footer (role="contentinfo").

Navigating a web page is far simpler for screen reader users if the content splits between some high-level sections. Content outside of these sections is difficult to find, and its purpose may be unclear.

HTML has historically lacked some key semantic markers, such as the ability to designate sections of the page as the header, navigation, main content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered a best practice, but the future probably favors HTML regions as browser support increases.

The HTML Living Standard states "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 reflect a "best practice" based on W3C validation.

Ensures the page has at most one banner landmark.

Landmarks allow blind users to navigate and find content quickly. Missing landmarks require screen reader users to sort through too much extra information to find anything.

JAWS, NVDA, and VoiceOver support the ability to navigate to sections of a web page using ARIA landmarks. Landmarks provide a more elegant solution to the problem of providing a way for users to skip to the main content of the web page. There is no visible alteration to the web design, making it unobtrusive and invisible. Of course, the fact that this technique is invisible is fine for blind screen reader users, but not so fine for sighted keyboard users or screen enlarger users with low vision. In this sense, HTML 5 regions and ARIA landmarks cannot yet replace the old-fashioned "skip navigation" links. Browsers still do not have a built-in way to notify users that HTML 5 regions or ARIA landmarks are present. Screen reader users are the only ones who can take advantage of them. There is a Firefox ARIA landmark extension available, which adds the ability to navigate by landmarks in Firefox, but this is not a native feature of the browser.

Ensures the page has at most one contentinfo landmark.

One of the main purposes of landmarks is to allow blind users to quickly find and navigate to the appropriate landmark, so you should keep the total number of landmarks relatively low. If you don't, screen reader users will have to sort through too much extra information to find what they're looking for.

Despite all of the talk about using correct semantic structure for accessibility, HTML has historically lacked some key semantic markers, such as the ability to designate sections of the page as the header, navigation, main content, and footer. With HTML5, these designations are possible, using the new elements header, nav, main, and footer. Similar functionality is available using the ARIA (Accessible Rich Internet Application) attributes role="banner", role="navigation", role="main" and role="contentinfo".

JAWS, NVDA, and VoiceOver support the ability to navigate to sections of a web page using ARIA landmarks. Landmarks provide a more elegant solution to the problem of providing a way for users to skip to the main content of the web page. There is no visible alteration to the web design, making it unobtrusive and invisible. Of course, the fact that this technique is invisible is fine for blind screen reader users, but not so fine for sighted keyboard users or screen enlarger users with low vision. In this sense, HTML 5 regions and ARIA landmarks cannot yet replace the old-fashioned "skip navigation" links. Browsers still do not have a built-in way to notify users that HTML 5 regions or ARIA landmarks are present. Screen reader users are the only ones who can take advantage of them. There is a Firefox ARIA landmark extension available, which adds the ability to navigate by landmarks in Firefox, but this is not a native feature of the browser.

It is a best practice to ensure that there is only one main landmark to navigate to the primary content of the page and that if the page contains iframe elements, each should either contain no landmarks, or just a single landmark.

Navigating a web page is far simpler for screen reader users if all of the content splits between one or more high-level sections. Content outside of these sections is difficult to find, and its purpose may be unclear.

HTML has historically lacked some key semantic markers, such as the ability to designate sections of the page as the header, navigation, main content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered a best practice, but the future will favor HTML regions as browser support increases.

It is a best practice to ensure that there is only one main landmark to navigate to the primary content of the page and that if the page contains iframe elements, each should either contain no landmarks, or just a single landmark.

Navigating a web page is far simpler for screen reader users if all of the content splits between one or more high-level sections. Content outside of these sections is difficult to find, and its purpose may be unclear.

HTML has historically lacked some key semantic markers, such as the ability to designate sections of the page as the header, navigation, main content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered a best practice, but the future will favor HTML regions as browser support increases.

landmark-unique is a new best practice rule ensures that landmarks have a unique role or accessible name (i.e. role, label, title) combination.

The document must not use the user-scalable="no" parameter in the <meta name="viewport"> element because it disables text scaling and zooming which is essential to users with low vision.

The user-scalable="no" parameter inside the content attribute of <meta name="viewport"> element disables zooming on a page. The maximum-scale parameter limits the amount the user can zoom. This is problematic for people with low vision who rely on screen magnifiers to properly see the contents of a web page.

Users with partial vision and low vision often choose to enlarge the fonts on their browser to make text on the web easier to read. The browser's viewport focus is everything visible in the browser window at a given moment. If the user maximizes the browser to full size on a high-resolution monitor, the viewport focus area is large and may include the entire web page.

If the browser window is small, the viewport focus area includes only a small part of the web page. The browser's viewport focus does not affect the programmatic focus. Users can scroll up and down the web page, but the programmatic focus does not follow the viewport. The Web Content Accessibility Guidelines calls for developers to design pages so that they support resize up to 200%; however, it is a best practice to require 5x zoom.

Ensures that the page, or at least one of its frames, contains an h1 element that appears before the start of the main content to allow screen reader users to use keyboard shortcuts to navigate the heading structure instead of wasting time listening to more of the web page to understand its structure.

Screen reader users can use keyboard shortcuts to navigate directly to the first h1, which, in principle, should allow them to jump directly to the main content of the web page. If there is no h1, or if the h1 appears somewhere other than at the start of the main content, screen reader users must listen to more of the web page to understand its structure, wasting valuable time.

Keep in mind that blind users can't just look at a web page and immediately understand its layout the way that a visual user can. Visual users can take in much information about the page layout without having to read all of the content. Blind users don't have that luxury. Screen readers read linearly, which means listening to the entire web page unless there is some other convenient way to get a "glimpse" of the page's layout and structure. It turns out that headings are a way to do that. Screen reader users can use keyboard shortcuts to navigate through the heading structure of a document.

Ensures elements which are marked to be removed from the accessibility tree are in fact removed.

There are certain cases where the semantic role of an element with role="none" or role="presentation" does not resolve to none or presentation (respectively). When this happens, the element is not removed from the accessibility tree (as expected) and screen readers are able to interact with it.

To ensure the element remains removed from the accessibility tree, you should not add any global ARIA attributes to the element or make if focusable.

It is best practice to contain all content excepting skip links, within distinct regions such as the header, nav, main, and footer.

Navigating a web page is far simpler for screen reader users if the content splits between multiple high-level sections. Content outside of sections is difficult to find, and the content's purpose may be unclear.

Historically, HTML lacked some key semantic markers such as the ability to designate sections of the page as the header, navigation, main content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered a best practice, but the future favors using native HTML5 element regions as browser support increases.

The page must have a link at the top before the navigation that allows users to skip lengthy navigation and proceed to a page's main content to save time.

Screen readers announce content sequentially as it appears in the HTML file. What this means for users of assistive technology is that the content at the top of the page, typically including the entire navigation, is read out to the user before reaching any of the main content. Since content at the top of the page can often be very lengthy, it can be time-consuming to listen to or tab through all of it when the user is only interested in the main content. Including a skip link in an HTML page is beneficial to blind users, users with low vision, and mouse-only users.

A tabindex attribute must never have a value greater than 0 to prevent an unexpected tab order that can give the appearance of skipping some elements entirely.

Using tabindex with a value greater than 0 can create as many problems as it solves. It creates an unexpected tab order, which makes the page less intuitive and can give the appearance of skipping certain elements entirely.

Here are some of the problems that tabindex (with a value of 1 or greater) causes:

• Unexpected tab order: From the perspective of the user, tabindex changes the default tab order in unexpected ways, possibly causing disorientation.
• Items can appear to be skipped entirely: Items appear in the tab order only once. If a user tabs past the tabindex items and continues through the rest of the web page, at some point the user arrives at the location of the tabindex items, but the tabbing process skips over these links, because the user already tabbed through them at the beginning of the cycle. Incorrect tab orders are frustrating when users are unable access items, and may not know that (s)he needs to cycle through the entire set of links on the page to reaccess those links.
• All tabindex items are tabbed to before any non-tabindex items. If you want to change the tab order of the first items AND of a section later in the page, you would need to set the tabindex value for every single item through to the end of the modified section. Taken to a bit of an extreme, if you have 20 links on a page, and if you set the tabindex of one of those links to tabindex="100", the user tabs to that link first, even though there are fewer than 100 links on the page. There is no way to modify the tab order of sections later in the page unless you manually set the tab order of all the links before that section.

Data table markup can be tedious and confusing. Make sure the caption and summary table attributes are not identical. Screen readers have some features to manage table navigation, but tables must be marked up accurately for these features to work correctly.

Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.

When tables have summary and caption text that is identical, screen reader users can be confused and find it difficult to know the name and purpose of the table.