Accessible University Info Page
This page summarizes the accessibility issues demonstrated on the Accessible University (AU) home page Before accessibility. With each issue, a solution is proposed. To see these accessibility solutions implemented, view the AU Home Page After accessibility.
Structure
Everyone benefits when web pages are organized into distinct sections with headings, subheadings, lists, and other structural elements. Structure helps users to understand how the content is organized and makes it easier for them to parse and read the content. If a person is using a screen reader to access content audibly rather than visually, they too benefit from structure, just as visual users do. For screen reader users to benefit, structure needs to be built into the page in the underlying code.
Missing Landmark Regions
Most web pages have a common overall structure. The AU home page is no exception. It has a banner, footer, navigation menu, main content, and a sidebar. These page regions are clearly identifiable to sighted users, but they are not properly coded in a way that makes them similarly recognizable by screen reader users.
In 2014, the World Wide Web Consortium (W3C) published a new specification called Accessible Rich Internet Applications (ARIA), which introduced eight so-called landmark roles that could be added to HTML elements to identify specific regions of the page. For example, the regions mentioned above would be coded as role="banner", role="contentinfo" (for the footer), role="navigation", role="main", and role="complementary (for the sidebar). With properly-coded landmark regions, screen reader users can quickly locate and jump to the section of the page that meets their needs.
Not long after ARIA was published, HTML added new semantic elements that serve the same purpose. Now, landmark regions on the AU home page can be coded with <header>, <footer>, <nav>, <main>, and <aside> respectively.
Both of these methods for identifying page regions — ARIA landmark roles and HTML semantic elements — are well-supported by screen readers, easy to implement, and have a huge positive impact on accessibility. For the Accessible Version of the AU home page, we used HTML semantic elements.
No headings
Visually, the AU home page includes several headings. However, these headings are not coded as headings using HTML heading tags (e.g., <h1>, <h2>). Instead, they are just 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 understand how the document is organized, and helps with navigation: Screen reader users can jump between headings in a document using a single keystroke, such as the "h" key (for "heading").
Headings should form an outline of the page content, without skipping levels. On the AU home page, the logo, which contains the text "Accessible University," is arguably the main heading of the page, so on the Accessible Version it's coded as an <h1> heading. All other headings on the page are coded as <h2> headings.
Language not specified
The AU home page includes content in both English and Spanish. Screen readers support both of these languages (and many others), and can switch on the fly between languages if they know to do so. If they don't know to do so, an English-speaking screen reader will read the Spanish section using English pronunciation rules, which produces poor if not indecipherable Spanish. The technique for addressing this issue is to provide a lang attribute on the <html> element, with the value being the official language code for the primary language used in the document. For example, an English document would include this html tag:
<html lang="en">If the web page includes content that differs from the primary language, the change in language should be identified in the code. For example, to markup a paragraph as being in Spanish, the paragraph tag would look like this:
<p lang="es">
Images
Images are inherently inaccessible to people who are unable to see them. The technique for making them accessible to screen reader users depends on whether they are informative or decorative.
No alternate text on informative images
On the AU home page, the logo and the four photos that are featured in the carousel are all informative. Their purpose is to communicate information to the user. When images contain text, such as the AU logo, the primary message that's being communicated is the text itself. When images do not contain text, the message is often more subtle. In the AU carousel, all four images are working together to communicate that Accessible University has a pretty awesome campus.
To make these messages accessible, images require an alt attribute that succintly communicates the image's message. This is commonly called "alternate text" or simply "alt text".
Most web authoring tools provide some means of entering alt text for images, often in an Image Properties dialog. Some web authoring tools pre-populate the alt text field with the image filename, which is not good alt text, and should always be replaced. On the AU home page, the logo is an example of an image which has the file name as its default alt text. For screen reader users, this makes no sense and should be replaced with alt="Accessible University".
Missing or excessive alternate text on decorative images
Some of the images on the AU home page are decorative; they are not intended to communicate information to the user. Specifically, the page includes a horizontal line that serves as a separator between sections on the page. These images are tagged with alt="horizontal line graphic" which is unnecessary information, and makes for a noisy experience for screen reader users, distracting them from the page content they actually care about. One solution is to provide an empty alt attribute (alt="") for all decorative images. This is standard markup that instructs screen readers to ignore the image. Another solution is to move all decorative images to the background using Cascading Style Sheets (CSS). The latter is the solution we've used for addressing this issue on the Accessible Version of the AU home page.
Color
Insufficient color contrast
On the AU home page, the navigation menu is an example of content that is difficult to see due to insufficient contrast between foreground and background colors. The W3C Web Content Accessibility Guidelines (WCAG) 2.x includes specific contrast ratios that must be met in order to meet the guidelines at various levels. There are a variety of free tools available that check for contrast. See the Tools and Resources page on the UW Accessible Technology website for an annotated list of accessibility tools, including several color checkers.
Furthermore, contrast is frequently overlooked when colors change on focus, such as when a keyboard user tabs to them or a mouse user hovers their pointer on the item. This problem can be observed in AU's navigation menu. The menu already has poor color contrast, but when a user tabs to an item in the submenu, it's even worse! See the Keyboard section below for additional information about keyboard accessibility, and when testing with a keyboard, always be on the lookout for contrast problems that might not reveal themselves if you only test with a mouse.
Color used to communicate information
The AU home page includes two instances of color being used as the sole means of communicating information.
First, in the application form, required fields are marked with blue text. People who are color blind or have other visual disabilities may be unable to perceive the differences in these colors. Even if a more obvious color was 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. On the Accessible Version of the AU home page, we have addressed this issue by presenting labels for required fields in bold text, marking them with a star, and using the HTML required attribute, so browsers can do their part to communicate to users that a field is required.
Second, the links within the main content use color as the sole means of distinguishing links from other text. Look closely! They're difficult for most people to spot. Even if the color choice was more dramatic, some users would still be unable to distinguish link text from non-link text. This is why browsers have always underlined links by default, and still do. It's a good, accessible practice and with modern CSS that are a wide variety of techniques for adding nicely styled, aesthetically pleasing, on-brand underlines to link text.
Keyboard
Any page content or features that are accessible with a mouse should also be accessible with keyboard alone. Some users whose disabilities impact upper body mobility or dexterity are physically unable to use a mouse and may be using the keyboard instead. Also, if a web page is not accessible by keyboard, this is often a good indication of other underlying accessibility problems.
Keyboard accessibility is easy to test, as it requires no special tools or skills. Simply try navigating through a web page using the Tab key (or Shift+Tab to go back). Use Enter or spacebar to follow links or activate buttons. Use other keys, such as the arrow keys and Escape key if the interface seems to call for use of those keys.
Web pages tend to fail keyboard accessibility tests for one of two reasons. First, the page may be coded improperly, making it truly impossible for keyboard users to access some of the content or features. Second, the page may actually be technically accessible to keyboard users but there is no visible indication of focus, so it's impossible for sighted users to tell where they are on the page.
Inaccessible keyboard interface
On the AU home page, the biggest problem for keyboard users is the modal dialog that pops up when they follow the third "click here" link in the "Can you spot the barriers?" section. Without a mouse, it's impossible to close the dialog. For additional information about this feature, see the Inaccessible modal dialog section below.
Another problem is the navigation menu. The menu is technically accessible to keyboard users since it's possible to access all menu items, including those contained in dropdown submenus, with keyboard alone. However, this menu only supports the tab key, and moving through it with keyboard is extremely cumbersome. A properly coded navigation menu would additionally support other keys, such as the arrow keys and escape key, so keyboard users can navigate the menu more efficiently. For additional information about this feature, see the Inaccessible navigation menu section below.
No visible indication of focus
As a keyboard user tabs through a web page, they should always be able to tell where they are on the page. Some web browsers provide a built-in visible focus indicator such as a solid blue outline that identifies the element that currently has focus. Other browsers provide a thin dotted line that can be difficult to see. A best practice is to design your own visible focus indicator that works reliably across all browsers. For more on this issue, including sample CSS code, see the Visible Focus page on the UW Accessible Technology website.
No "skip to main content" link
The AU home page has content at the top of the page (a navigation menu for the demo site and AU's website naviation menu) that, even if coded properly for accessibility, can be burdensome for keyboard users who just want to tab to a link or button elsewhere on the page. This isn't a problem for screen reader users if the page is coded properly (e.g., using landmark regions and HTML headings as described above in the Structure section); they can easily jump to particular page content given functionality that's provided by their assistive technologies. However, keyboard users who are not using assistive technologies are much more limited.
The solution is to provide a "Skip to main content" link in the top left corner of the page, which links directly to the main content. This should be the first element that receives focus when a user starts tabbing from the top of the page. For the Accessible Version of the AU home page, we have designed this link so it's visibly hidden by default so as not to confuse mouse users who don't understand its purpose. It's hidden by positioning it off-screen using CSS, which keeps it visible to screen reader users. Even though they have other ways of navigating on the page, they may still find this link to be useful. When a keyboard user tabs to the link, its CSS properties change so that it moves onto the visible page.
Links
Redundant, uninformative link text
The AU home page includes three links that say "click here". Screen reader users may encounter these links out of context. For example, they might be tabbing through focusable elements on the page, or they might be navigating through a list of links (many screen readers include this feature). The solution is to always ensure that link text is unique and meaningful on its own, even if read out of context.
Links vs buttons
On web pages, links and buttons are different elements, which serve different purposes. Links take the user to a new location, such as a new web page or new section of the current page; whereas buttons trigger some action, such as showing content on the page that was previously hidden, playing a video, or submitting a form. This distinction matters because it affects user expectations. If a screen reader clicks a link expecting to be taken to a new location and that doesn't happen, the result will likely be a very confused user.
On the AU home page, the third "click here" links in the "Can you spot the barriers?" section triggers a modal dialog. This link should be a button.
Features
As web pages become more interactive, the interface can become more challenging to make accessible and usable for people with disabilities. Designers and developers need to consider how to make the feature accessible to keyboard users and how to code it properly so that screen assistive technology users can understand the interface and use it effectively. A key resource when designing, coding, or choosing an interactive web feature is the W3C's ARIA Authoring Practice Guide (APG). The APG includes a variety of design patterns for common web features, including all of the features listed below. Whenever possible, web features should be designed and developed in accordance with the APG design patterns, as doing so would ensure a reliable, consistent interface throughout the web.
Inaccessible navigation menu
The website navigation menu on the AU home page includes sub-menus that appear when users hover over the menus with a mouse. They also are technically accessible to keyboard users since it's possible to access all menu items, including those contained in dropdown submenus, with keyboard alone. However, this menu only supports the tab key, and moving through it with keyboard is extremely cumbersome. The AU navigation menu is simple and short compared to most menus in the real world, but it still requires 20 keystrokes to get from one end to the other.
A properly coded navigation menu would additionally support other keys, such as the arrow keys and escape key, so keyboard users can navigate the menu more efficiently. Also, ARIA is needed in order to communicate to screen reader users that submenus are available and whether they're expanded or collapsed. The APG includes a design pattern called Disclosure (Show/Hide), which works well for navigation menus.
Inaccessible carousel
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. For example:
- 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.
The APG includes a design pattern for a Carousel (Slide Show or Image Rotator). Following this design pattern will result in a much more accessible interface. However, it is important to test the carousel (and other complex interactive features) with assistive technologies, ideally recruiting actual users of these technologies to do the testing. Does the interface make sense? What is the experience like? How can it be improved? These are all important questions that must be explored in order to ensure features are not just accessible, but usable. Part of this line of inquiry should also be weighing the pros and cons of using a particular feature. What are the benefits of presenting content in a carousel? Do your analytics confirm that users are interacting with it as expected? Adding features just because they're trendy and cool may not be sound justification, especially if the features are challenging to implement and make your web page more difficult to use.
Inaccessible modal dialog
In the "Can You Spot the Barriers?" section of the AU home page, the third "click here" link opens the content in a modal dialog, which appears in the foreground while background content is masked behind a dark transparency. Despite its visible appearance, this is not truly a modal dialog. If a keyboard user presses the Tab key, their focus may remain in the background, making it difficult (maybe even impossible) to tab to the dialog so that they can dismiss it. Screen reader users may not even be aware that a dialog has appeared, leaving them confused because they clicked on a link but nothing seemed to happen. (See also "Links vs buttons" above).
The APG includes a design pattern for Dialog (Modal) that spells out the keyboard model and ARIA markup that are needed in order to make a modal dialog accessible. Also, HTML now includes a <dialog> element that greatly simplifies the coding required to create a modal dialog. We have used the latter as a solution for making the dialog accessible on the Accessible Version of the AU home page.
Forms
Form not properly labeled
On the AU home page, the application form mostly includes simple text fields and a set of checkboxes. Each of these form fields is accompanied by a label and sighted users know which labels accompany which form fields by their position. However, this is not coded properly for accessibility. Labels must be coded using the HTML <label> element and explicitly associated with the fields they represent. Without proper markup, some screen readers may attempt to guess the labels for each form field, while others will not. In this case, screen readers that attempt to guess the labels (i.e., JAWS) do so incorrectly within the group of checkboxes.
Another problem with the group of checkboxes is that the overall prompt "Desired major(s)" is not explicitly associated with the checkboxes. Screen reader users navigating in "forms mode", pressing the tab key to jump between fields, will skip past this prompt and not know what the group of checkboxes is all about. If a group of checkboxes or radio buttons was coded this way in an online quiz, users would be presented with the possible answers, but not with the question. Coding this properly involves wrapping the entire set of fields, including the overall prompt, in a <fieldset> element and coding the overall prompt as a <legend>.
Additional information, including sample code, is available on the Forms on websites page on the UW Accessible Technology website.
Inaccessible CAPTCHA
Online forms often include images of distorted characters called CAPTCHAs ("Completely Automated Public Turing test to tell Computers and Humans Apart"). CAPTCHAs are designed to prevent spammers and other unwanted users from filling out and submitting the form automatically. The usual method for making images accessible (alternate text) would not be feasible for CAPTCHAs since this same technique would make the images accessible to bots. The Forms on websites page on the UW Accessible Technology website includes a section on "Avoiding CAPTCHA" with considerations about how to block bots without burdening users.
For the Accessible Version of the AU home page, the method we've used to address this problem, for demonstration purposes only, is a text-only only CAPTCHA, which asks simple logic questions that are accessible to humans but more challenging for bots. As bots get smarter, this solution becomes less reliable. If spam is a significant problem for a particular form, techniques for addressing that problem must be considered very carefully in order to avoid blocking legitimate users.
Inaccessible input validation
On the AU home page, when the user submits the apppliction form, it's validated using JavaScript before the data is submitted to the server. If the user's submission fails validation, an error message is displayed at the top of the form.
This feature has many problems:
- Screen reader users are not informed that this message has appeared. They submitted the form but nothing seems to have happened.
- The error message appears in a location that is nowhere near the submit button, where the user is currently focused. Users who are zoomed in significantly may not see the error message when it appears.
- The error message is unclear. It states that there are errors, but does not identify what those errors were. The burden of finding the errors is left to the user, which adversely impacts usability for everyone, but can be especially challenging for screen reader users.
Client-side form validation is an important part of making online forms accessible. However, care must be taken to ensure it's done in an accessible way. For more information, see the W3C Web Accessibility Initiative's Forms Tutorial, which includes a detailed section on Validating Input.
Tables
Missing accessible table markup
Data tables can be challenging for screen reader users to understand, particularly if they have many columns, or a complex layout with nested rows or columns, as is the case with the AU Enrollment Trends table. Imagine reading a table from left to right and top to bottom, with no visual access to the column headers. When you're halfway through the table, will you remember which column you're in? This is not unlike what screen reader users experience as they try to read a data table unless the table includes semantic markup that explicitly defines the relationships between the table's parts. For example, table headers should be marked up with the <th> element ("th" stands for "table header"), and headers should include the scope attribute, which identifies whether it's a row header (<th scope="row">) or a column header (<th scope="col">).
The AU Enrollment Trends table includes additional challenges since it has nested column headers, plus row headers, that apply to each data cell. The W3C Tables Tutorial includes recommended markup for a variety of distinct table configurations.
For the Accessible Version of the AU home page, we made the AU Enrollment Trends table accessible by properly tagging each column and row header as explained above and by assigning a unique id to each header. Then, a headers attribute was added to each data cell, the value of which is a space-separated list of ids of all headers that apply to that cell (e.g., <td headers="col1a col2a row1">). When a table includes all of this markup, screen reader users can easily ascertain their current position with a table, and their screen reader can announce all of the headers that apply to the current cell.
Missing abbreviation tags
Abbreviations can be difficult for all users to understand. In the AU Enrollment Trends table, the column headers are abbreviations for different majors. These abbreviations may be new to some users, and for all users there may be ambiguities (does "Eco" stand for "Ecological Sciences" or "Economics"?) The <abbr> element should be used to identify abbreviations with a title attribute that spells out the full word or name. This is displayed as a tooltip to mouse users as they hover over the abbreviation, and is announced verbally to screen reader users if their screen reader is configured to support this functionality. In the "Eco" example, the <abbr> element would be used like this:
<abbr title="Economics">Eco</abbr>
Video
Inaccessible audio content
The AU video includes narration that is inaccessible to users who are unable to hear the audio. This includes people who are deaf or hard of hearing, as well as people who are watching the video in a quiet setting where they're unable to turn up the sound, and people who are watching the video in a noisy setting. The solution is to add captions to the video. For details, see the Captions page on the UW Accessible Technology website.
Inaccessible visual content
The AU video features rich imagery that is designed to communicate information about the unviersity to viewers. The video's narration captures some of this, but leaves out a lot of important content, and a person listening to the audio alone does not come away with an equivalent impression to that of a person who's listening to the audio accompanied with the visuals. The solution is to supplement the video with audio description, a narration track that supplements the video by describing the visual content for people who are unable to see it.
The Accessible Version of the AU home page uses Able Player, a free, open-source, accessible HTML media player created and maintained at the University of Washington. Among other features, it enables users to switch between the described and non-described versions of the video using the "Descriptions" toggle button on the player control bar.