This page summarizes the accessibility issues demonstrated on the Accessible University (AU) home page (Inaccessible Version). With each issue, a solution is proposed. To see these accessibility solutions implemented, view the AU Home Page Accessible Version.
Inaccessible dropdown menu. The navigation menu on this page is dynamic: Sub-menus 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 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 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 1.0 Authoring Practices, which includes a set of recommended design patterns for common widgets. This includes a menu design pattern, which was followed closely in creating the menu for the accessible version of the AU home page. For more details about accessible dropdown menus, see Terrill Thompson's blog post Accessible Dropdown Menus Revisited. Terrill is technology accessibility specialist with AccessComputing, and created the Accessible University website.
Insufficient visual cues. 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:
Color used to communicate information. 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 and designers should not override this feature by turning off link underlines in their style sheets.
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.
Language not specified. This page includes content in both English and Spanish. Leading 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:
If the web page includes content that differs from this primary language, the language of that section of content must also be identified in the code. For example, to markup a paragraph as being in Spanish, the paragraph tag would look like this:
Missing accessible form markup. 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.
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 robots. The W3C published a Working Group Note in 2005 that explores the Inaccessibility of CAPTCHA and proposed possible solutions. Several solutions have been proposed and implemented with some success:
This feature has many problems:
Missing ARIA landmark roles. ARIA (defined in item #5) includes eight so-called 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 thepage 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.
Inaccessible modal window. 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.
Several steps are required in order to make a modal window accessible:
Additional details about accessible modal dialogs are available in Greg Kraus's blog post The Incredible Accessible Modal Dialog. Note the links to updated versions within the blog post. Greg's Accessible Modal Dialog is available on GitHub, and was used with minor modifications in the accessible version of the AU home page.
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:
The W3C has developed an Accessible Carousels Tutorial which documents strategies for addressing these issues. The carousel in the accessible version of the AU home page demonstrates many of the solutions described in the W3C's tutorial.
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. Also, headers should include the scope attribute, which identifies whether the cell is a row header (<th scope="row">) or a column header (<th scope="col">).
If the table includes nested rows or columns, the relationships between headers and cells become even more difficult to decipher. In these sorts of tables, there are typically two, three, or more headers that apply to every cell in the table. To explicitly express these relationships using HTML markup, each header needs a unique id (e.g., <th scope="col" id="col1">), and each data cell needs a headers attribute which lists the id's of all headers that apply to that cell, separated by a space (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.
Also, it is helpful to provide a brief summary of a complex table specifically for screen reader users, as this will help them to understand how the table is organized before they explore it. Prior to HTML5, this was accomplished with the summary attribute on the <table> element. In HTML5, a summary can provided in a separate paragraph or div adjacent to the table, and that can be explicitly linked to the <table> element with the aria-describedby attribute. The summary might be useful for all users, but if it truly only benefits screen readers, then it can be visually hidden without hiding it from screen reader users. See the accessible version of the AU home page for an example.
Also, it is helpful to provide a caption for all tables using the <caption> element, nested within the <table> element. In the accessible version of the AU home page, the table caption "AU Enrollment Trends" is redundant since there is also a heading with this same information immediately prior to the table. However, the caption is still important because it's explicitly associated with the table. If screen reader users jump directly to the table (for example, using the "t" shortcut key in JAWS or NVDA, or the rotor in VoiceOver), their screen reader announces the caption so they can quickly tell which table they're on. As with the table summary, the caption can easily be hidden from sighted users using CSS if it's redundant or unnecessary for them to access this information.
Missing abbreviation tags. Abbreviations can be difficult for all users to understand. The AU Enrollment Trends table includes a common example of how abbreviations are used in higher education. These abbreviations may be new to some users, and for all users there may be possible conflicts. For example, the abbreviation "Eco" could refer either to 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:
HTML fails validation. The rules of markup languages like HTML were meant to be followed. If a web page uses non-standard tags or uses standard tags inappropriately, this increases the likelihood that some browsers or assistive technologies will render the page incorrectly. Therefore web pages should be checked with tools like the W3C Markup Validation Service. A check of the inaccessible version of the AU home page results in five errors, all of which are accessibility-related.