This page summarizes the accessibility problems demonstrated on the Accessible University (AU) home page (Inaccessible Version). With each problem, a solution is proposed. To see these accessibility solutions implemented, view the AU Home Page Accessible Version.
Menu inaccessible to keyboard users. 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, or using a touch screen or stylus, the sub-menus do not appear; nor do the main menu items send the user to a new page. They simply don't work. There are many examples of menu systems that have been developed with accessibility in mind. Terrill Thompson, Technology Accessibility Specialist with AccessComputing, examined several of these in depth in his blog post Accessible Dropdown Menus. One of the more accessible options discussed in Terrill's article is Yahoo's YUI MenuNav Node Plugin.
The accessible version of the AU home page uses YUI menus.
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 is typically provided in CSS using the selector a:hover. The same visual cues can be replicated for keyboard users by using the selectors a:focus (for all browsers other than Internet Explorer (IE)) and a:active (for IE). Here's an example in CSS:
Missing accessible form markup. In the Apply Now! 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:
For demonstration purposes, the updated AU home page provides a text CAPTCHA. This is for demonstration purposes only, and there is no actual server-side validation that alerts users if they submit the form with an incorrect security answer.
This feature has many problems:
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, the <table> element can include a summary attribute, the purpose of which is to provide an overview of how the table is organized, specifically for screen reader users.
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 (and its sister element, <acronym>) should be used to identify abbreviations (or acronyms). With either of these elements, the title attribute is used to spell 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 AU home page results in 12 errors, and detail is provided about each error. A scan of those details reveals that the 12 individual errors are actually only two errors repeated multiple times. The two errors are:
On the updated AU home page, the above validation errors have all been corrected. Also, the new AU home page is built using an HTML5 doctype. This allows the page to validate when using ARIA markup such as the role and aria-label attributes described above. Since ARIA post-dates earlier versions of HTML, it is not valid markup according to HTML validators. However, ARIA is supported by assistive technologies regardless of doctype, so we highly recommended using it even if doing so causes pages to fail validation. While it's important to use valid code in general, it's also important to know when it's ok to break the rules.
In fact, the improved AU home page has one validation error: The summary attribute on tables (described in item #15) is no longer valid in HTML5. This was removed from the HTML specification with considerable controversy, and is still supported by assistive technologies even in HTML5. Therefore, this is yet another case where breaking the rules is advisable since doing so results in improved accessibility.