Assessment steps
Every time we do an assessment on a new website, we follow the steps in the following video series. If a developer goes through these steps before they finish development, the website will likely be pretty accessible.
Following this checklist will result in saving time and money by reducing the number of issues that need fixed. If this checklist of issues is followed we might not find any issues when we do our final official assessment.
Introduction to this "How to do a web accessibility assessment" series
This is an introduction to this How-to do a web accessibility assessment.
Links to an example of a website before accessibility fixes and after accessibility fixes from the video.
Overview of the Web Accessibility Evaluation Toolbar
To do a simple web accessibility assessment, you will need the help of automated testing tools provide visual feedback about the accessibility of website content by injecting icons and indicators into your page. No automated tool can tell you if a page is accessible, but these automated tools facilitate human evaluation and reveal some accessibility issues.
For this series, we are featuring the Web Accessibility Evaluation tool (WAVE Toolbar) because it is the easiest to learn. Other extensions include:
Missing Bypass block (Skip-to main content)
A bypass block, otherwise known as a skip-to link, is a mechanism that is available to bypass blocks of content that are repeated on multiple Web pages. In this case, it allows keyboard-only users to skip over the navigation to get to the main content without needing to tab over the entire menu every time they load the page.
Improper use of headings assessment
Headings and subheadings help organize documents, including web pages, so that they are easy to read and understand.
Visually, the bad example page appears to include several headings. However, these headings are not marked up explicitly as headings using HTML heading tags (e.g., <h5>, <h2>). Instead, they are simply marked up as plain text that is bold and large. If HTML heading tags are used, screen reader users have access to this structural information. This helps them to gain a better understanding of how the document is organized. It also helps with navigation: Screen reader users can jump between headings in a document using a single keystroke, which is much more efficient than reading the entire page from beginning to end.
Image alt tags assessment
There are several images on the page. Some are decorative, but the logo, the three photos featured in the carousel, and others communicate important information. Whenever an image communicates information, it requires alternate text so users who are unable to see the image have access to its content.
Notice the text is embedded in the hero image. Screen readers cannot read text in images. They can only read real selectable text. If a person who was blind was on this site they could not know about the event because the title, date, and location of the event is in the image. If it is unavoidable the alternate text needs to have the same information so users who are unable to see the image have access to its content.
Insufficient color contrast assessment
The navigation menu is difficult to see due to the choice of foreground and background colors. The W3C Web Content Accessibility Guidelines (WCAG) include specific contrast ratios that must be met in order to meet the guidelines at various levels. Contrast can be easily checked with free tools like the Colour Contrast Analyser and the WCAG Contrast Checker plugin for Firefox.
How to check for hover states
Interactive focus state assessment
This page includes visual cues that show mouse users when they're pointing to clickable items on the page such as links. However, this same functionality is not provided for keyboard users, and they would arguably benefit from it even more than mouse users. Without a clear visual indication of one's current location on the page, keyboard users can have a very difficult time getting their bearings as they tab through links and controls. Visual cues for mouse users are typically provided in CSS using the selector :hover. The same visual cues can be replicated for keyboard users by using the selector :focus. Here's an example in CSS:
a:hover, a:focus {
color: white;
background-color: black;
}
Dropdown menu assessment
The navigation menu on this page includes sub-menus that appear when users hover over the menus with a mouse. However, these same menus do not appear for non-mousers. If a user navigates to the menu by pressing tab, the sub-menus do not appear; nor do the main menu items send the user to a new page. They simply don't work. If they did work, screen reader users would depend on supplemental markup added to the HTML that informs them that an item has a submenu, and whether that submenu is expanded or collapsed. This supplemental markup can be provided using Accessible Rich Internet Applications (ARIA). ARIA is a W3C specification first published in 2014 that is designed to communicate roles, states, and properties of user interface elements to assistive technologies. ARIA is essential for accessibility of today's modern web interfaces. The W3C has created a companion guide WAI-ARIA Authoring Practices, which includes a set of recommended design patterns for common widgets, including a menu design pattern. These standard design patterns include detailed recommendations for how users should be able to interact with the widget using the keyboard, as well as recommendations for which ARIA attributes should be used in order to make the widget accessible using assistive technologies. All dropdown menus should be coded in accordance with these recommendations so users can count on dropdown menus everywhere having a consistent interface.
Developers:
- Review other menu systems can be found on the WC3 Fly-out Menu suggestions page.
- Consider other modern menu system for dropdown menus. Using this dropdown method is also WCAG 2.1 AA compliant.
Redundant links assessment
This example includes three links that say "Click here". Screen reader users may encounter these links out of context. For example, many screen readers include functionality that enables users to quickly generate a list of links and navigate through that list. If links are presented out of context, such as in a list of links, they should be unique, and should be meaningful in-and-of-themselves.
Color only method to communicate information assessment
The links within the main content are distinguishable from other text by color alone. Look closely! They're difficult for most people to spot. Even if the color choice had been more dramatic, some users (for example, those who are color blind) would still be unable to distinguish link text from non-link text. This is why browsers underline links by default&it's a good, accessible practice.
Also, in the application form, required fields are marked with blue text. Again, even if a more obvious color were chosen, some users would still be unable to identify which fields are required. The solution is to communicate information using other means, in addition to color. For example, the labels for required fields could appear in bold and be marked with a * or if space permits, with "(required)". Also, if markup is available to communicate the same information, use that. For example, in the case of required fields, use the HTML5 required attribute, supplemented with aria-required="true" for assistive technologies that don't fully support HTML5 attributes.
Form label and markup assessment
In the application form, sighted users know which labels accompany the various form fields by their position. In the first six fields the label appears immediately above the form field, and in the set of possible majors the label appears immediately after each checkbox. Although these relationships may seem apparent to sighted users, they're not so obvious to screen reader users. HTML includes markup that enables form fields and their labels to be explicitly associated with one another. If this markup is not present, screen readers have to guess which labels are associated with each field, and they don't always guess correctly. For example, some screen readers incorrectly assume the label for each checkbox is the text that immediately proceeds it, rather than the text that follows it. Therefore, a screen reader user could check the Psychology checkbox, having been erroneously informed by their screen reader that they're checking the Physics checkbox. To explicitly associate labels with form fields, each label must be marked up with the HTML <label> element. The <label> element has a for attribute whose value matches the id attribute of the associated form field.
Also, when a form uses checkboxes, there are typically two pieces of critical information related to each checkbox: The label associated with that checkbox (e.g., Psychology) and the overall question or prompt (e.g., Desired major(s)). In order to explicitly communicate the relationships between all of this information, the entire set of checkboxes and labels, plus the overall question or prompt, should be wrapped in a <fieldset> element, and the question/prompt should be marked up as a <legend>. The individual checkbox labels should be marked up using the <label> element as described above. With this accessible markup in place, screen readers can announce the overall question or prompt as the user enters the fieldset, or as he or she selects one of the checkboxes. This same markup applies to radio buttons.
Form field validation assessment
Form validation can be a useful feature, but it should be designed in a way that considers the needs of all users, including those who can't see the error message visually, and those who are unable to use a mouse.
ARIA landmark assessment
ARIA includes eight Landmark roles, which are specific regions of the page identified according to their function. They are: application, banner, complementary (e.g., a sidebar), contentinfo (e.g., a footer), form, main, navigation, and search. By defining the Landmark role of a block of content (for example role="main" for the main content), screen reader users can quickly locate and jump to the section of the page that meets their needs. The accessible version of the AU Home Page uses ARIA Landmarks to mark the banner, main, navigation, form, and contentinfo sections of the page. The navigation menu additionally uses aria-label to clearly communicate the function of the navigation menu (in this case, aria-label="Main menu"). This supplemental label is announced by screen readers and is especially helpful for distinguishing between navigation regions if there are more than one of these regions on a page.
Some of the ARIA Landmarks map directly to HTML5 elements. For example, role="main" is the same as <main> and role="navigation" is the same as <nav>. However, it's ok to use both to ensure support for older assistive technologies, which supported ARIA before supporting HTML5.
Modal/popup assessment
In the "Can You Spot the Barriers?" section of the AU home page, the link that opens the Cheatsheet of Accessibility Issues opens the content in a modal window, which appears in the foreground while background content is masked behind a dark transparency. This is not truly modal, however. If a keyboard user presses the Tab key they may discover that their focus remains in the background, and they may find that it's very difficult to tab to the dialog so they can dismiss it. Also, screen reader users are not aware that a dialog has appeared. Instead, they're likely to be confused because they clicked on a link but nothing seemed to happen.
Slideshow/carousel assessment
Carousels or slideshows are common features on university home pages. Unless designed and coded with accessibility in mind, these features present a variety of accessibility issues:
- Keyboard users are unable to access all components
- Screen reader users are unable to operate the controls or access and understand all content.
- People who are distracted by movement or who need more time to read the content are unable to pause the animation.
A detailed explanation can be found in the Smashing Magazine article on slideshows.
The ARIA Authoring Practices Guide also has details on making a slideshow accessible.