Testing for Non-Visual Clarity

When you are testing the non-visual accessibility of your site or application, some of what you’ll do does overlap with testing for keyboard access. Some of it will also overlap with testing for visual clarity, but some of it is unique to non-visual accessibility testing. Before you begin, you are going to want to install NVDA. If you haven’t yet, you can read the getting started page for NVDA. You will also want to know how to use Narrator. You can get the basics of getting started with Narrator by reading the getting started with Narrator page.

Use semantically correct markup

A large part of making sure your page is accessible to users of screen readers is to always use the semantically correct elements for the various parts of the page. This includes header, footer, nav, article, aside and other semantic elements. If, however, you can’t use these elements for some reason and you absolutely must use a more generic element, use the “role” attribute to tell a screen reader to announce the element as if it were that kind of element. To learn more about the “role” attribute, you can read this article from MDN.

Alternative text for images

One of the most basic wins you can get with non-visual accessibility is making sure all meaningful images on a page have what is called alt text. This is typically done with the “alt” attribute in HTML. If an image is decorative, however, you need to still have an alt attribute, just left empty. What that does is tell the screen reader to ignore it entirely. An “alt” attribute must never be absent from an image. If you don’t include one, the most common result is the file name being read aloud to the user, which is not a good experience. The lack of an alt attribute is one of the things that automated tools will always catch, but they cannot catch improper use of the alt attribute when it does exist on an image. That is where manual testing is required. If the image is a chart, there needs to be some textual alternative that conveys the same data.

Keyboard access

Screen reader users rely on the keyboard instead of the mouse to navigate through and operate a page. This includes:

• Making sure there is a logical tab order
• Making sure that all interactive elements on a page are in the tab order
• Making sure that all interactive controls can be operated with the keyboard
• Making sure that when a user presses tab to navigate the page, focus doesn’t leave the current context, such as a modal (For modals, you must provide a way to exit with the keyboard)
• When navigating a page with a screen reader by a specific element, such as headings, the user must not be confused about where they are on the page or about the page’s structure as they go
• When tabbing around the page, each focusable element must have a noticeable focus ring around it, even if custom styled instead of using the default one provided
• If a keyboard shortcut is applied to, for example, a button, the user needs to be able to toggle it off if desired or triggered only when focused if the keyboard shortcut is a single letter, number or punctuation symbol

You can learn more about this by reading guideline 2.1 of WCAG 2.2 and the Accessible Rich Internet Applications (ARIA) authoring practices.

Properly labeling form controls

When the average user fills out a form, they can visually associate the form field with its label next to or above it. Screen reader users, however, do not have that ability. The label and form field must be programmatically associated with each other. This can be done in three main ways:

1. By using the “for” attribute on a label element in HTML, referencing the id of the form field
2. Wrapping the input in the label element
3. Using the aria-labelledby attribute, referencing the form field’s id

Only use that third option when providing a label to elements that do not support any of the other two options. A rule of thumb to follow is to use ARIA as little as possible, instead relying on semantic HTML markup. If a label is not provided to a form control, a screen reader will only hear something like “button”, “edit text”, “checkbox” and “radio button,” which isn’t useful information. Ideally, a user of a screen reader needs to hear the name/label, value and type of a control. How this information is conveyed, however, can differ across screen readers and browsers.

"Skip to content" links

When the user of a screen reader navigates to a page, in order to traverse the page quickly, they expect to have a “Skip to Content” or “Skip to Main Content” link. This kind of link, when pressed, moves the user to the main content of a page, skipping the navigation entirely. These links are included as the first element on a page and not visible on the page, but still accessible to screen readers and other assistive technologies. The best way to do this is to style them with CSS to appear invisible or to position them outside the browser’s viewport.

Logical ordering of content

When a screen reader user navigates a page, the screen reader follows the order in which the elements were defined in the markup. Because of that, it’s important to make sure the markup is defined in a logical order to prevent users from getting lost or confused about where they are on the page. This also improves muscle memory if the user frequently navigates to a particular part of the page.

Clear text for labels and links

When crafting the text for labels, titles for buttons and text for links, it is important to keep them not only brief, but descriptive. Something like “click here,” “here” and similar unclear titles are meaningless without additional context. If a user is traversing the page by link, form control, button, or other specific element, the purpose of the element needs to be clear without needing additional context. If You must have a specific title for a button for example, and that title is unclear when navigating by form control, by button or by pressing tab, you can use the “aria-label” attribute to convey a different, more clear title to screen readers without touching the visual title. Just like with “aria-labelledby,” use this sparingly and opt for using semantic markup when possible. If you want to learn more about the “aria-label” attribute, you can read this MDN article about the aria-label attribute.