Accessible University: List of Accessibility Problems

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.

  1. No headings. Headings and subheadings help organize documents, including web pages, so that they are easy to read and understand. Visually, this page includes several headings. However, these headings are not marked up explicitly as headings using HTML heading tags (e.g., <h1>, <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.
  2. No alternate text on informative images. There are several images on this page. Some are decorative, but three of the images (the logo and the two photographs) communicate information. Whenever an image communicates information, it requires alternate text so that users who are unable to see the image have access to its content.
  3. Missing or excessive alternate text on decorative images. Screen reader users do not need access to images whose purpose is solely decorative. The example on this page is the horizontal line that appears multiple times on the page. The current alt attribute for this image is "horizontal line graphic", which is unnecessary information, and can be especially cumbersome to listen to when it's repeated multiple times on a page. One solution is to present all decorative images as background images in Cascading Style Sheets (CSS). Another is to provide an empty alt attribute (alt="") for all decorative images. This is standard markup that instructs screen readers to ignore the image. If the alt attribute was missing entirely, screen readers don't know whether the image is informative or decorative, so they typically provide information about the image (such as the path and filename) in hopes that this will contain information that may help the user to understand the image's function and/or content. In a page with many decorative images, this can become very cumbersome.
  4. Images used to represent text. Whenever possible, it is best to present text using text, rather than images. Text downloads in a fraction of the time that it takes images to download. It is also much easier for web developers to edit plain text content. For users who need to enlarge content in order to see it clearly, text scales without loss of clarity when enlarged (e.g., using Ctrl + in most Windows browsers, or Apple + in Mac browsers). Depending on the browser, images of text either do not enlarge at all, or they become pixilated and difficult to read as they get larger.
  5. Insufficient color contrast. The navigation menu is very difficult to see due to the choice of foreground and background colors. Designers should always be sure to provide high contrast between the foreground and background colors.

  6. 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, including these:

    The accessible version of the AU home page uses YUI 3 menus.

  7. 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:

    a:hover, a:focus, a:active {
     color: white;
     background-color: black;
    }
  8. 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: <html lang="en">. 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: <p lang="es">
  9. Redundant, uninformative link text. This page includes two 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.
  10. Color used to communicate information. In the Apply Now! form, required fields are marked with blue text. It is very difficult for most users to distinguish between the blue and black text. Even if the required fields were a more obvious color for the majority of users (e.g., red), many users will still be unable to distinguish between colors (e.g., blind or color-blind users, users with monochrome or color-deficient displays). Consequently they will not have access to this information. Color can be one way of communicated information, but it should also be accompanied with other means of communicating the same idea. For example, the required fields could be bold and marked with an asterisk (*), or if space permits, with "(required)". Another solution is to identify required fields with aria-required="true". The aria-required attribute is defined within the W3C's Accessible Rich Internet Applications (ARIA) 1.0 specification. ARIA is designed to communicate semantic information about interactive, dynamic web content so that assistive technologies such as screen readers can provide a meaningful and effective interface through which users can interact with that content. As of November 2010, ARIA is still a draft specification, but current versions of most leading screen readers already support many of its recommendations, including aria-required. On the AU Accessible Version, we have option to include the text "(required)" on the label for each required field, since older versions of screen readers don't support ARIA markup.

  11. 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.

  12. Poor design of Javascript-based form validation. When the user submits the form, it's validated using Javascript before the data is submitted to the survey. If the user's submission fails validation (due to required fields missing or an invalid email address), a message is displayed in a modal div, positioned in the center of the screen, with text: "Your form has errors. Please correct, then resubmit." Users must click off of the error message in order to restore the window to its original state so they can proceed to fix the form errors.

    This feature has many problems:

    Javascript-based 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. A better design would be one in which:

  13. Missing ARIA landmarks. ARIA (defined in items #10 and 12) 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. Most screen readers now support ARIA landmarks. Users can jump between landmarks on a page with a single keystroke, or can generate a list of landmarks and navigate the page using that list. This is similar in purpose to using good heading structure (see item #1), but differs in the information it communicates about the organization of the page. The accessible version of the AU Home Page uses ARIA landmarks to mark the banner, main, navigation, form, and contentinfo sections of the page.

  14. 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.

  15. 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:

    <abbr title="Economics">Eco</abbr>

  16. 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 numerous errors, and detail is provided about each error. A scan of those details reveals that many of the individual errors are actually only three errors repeated multiple times. The two errors are:

    On the updated AU home page, the above validation errors have all been corrected, but new errors have been introduced: The role attribute (described in Items #10, 12 and 13) is not valid HTML. This is because ARIA is a new specification, and is not recognized by any version of HTML or XHTML prior to HTML5. Therefore, unless a web page uses HTML5 as its doctype, ARIA markup will result in validation errors. Despite this problem, ARIA is supported, at least in part, by many of the latest browsers and assistive technologies, and improves accessibility especially for screen reader users. Therefore, while it's important to use valid code in general, it's also important to know when it's ok to break the rules.

  17. Skip repetitive navigation. Any time a site has content that repeats at the top of every page of a site, like a navigation menu, you need to provide a way for keyboard-only users to easily skip over the content. Otherwise the user will need to tab through each element of the navigation in order to get to the main content. This is often referred to as a "skip to main content" link or "skip navigation link". This technique uses a hidden off-screen link that becomes visible on screen when a user tabs to it. By implementing it this way, both screen reader users and keyboard-only users can take advantage of the feature.
    a.skip-main {
    left:-999px;
    position:absolute;
    top:auto;
    width:1px;
    height:1px;
    overflow:scroll;
    z-index:-999;
    }
    a.skip-main:focus, a.skip-main:active {
    color: #fff;
    background-color:#000;
    left: auto;
    top: auto;
    width: 30%;
    height: auto;
    overflow:auto;
    margin: 10px 35%;
    padding:5px;
    border-radius: 15px;
    border:4px solid yellow;
    text-align:center;
    font-size:1.2em;
    z-index:999;
    }

    <a class="skip-main" href="#main">Skip to main content</a>
  18. Page updates without notification. Any time part of a page updates after the page has completely loaded it is difficult for many assistive technologies to recognize and alert the user to the change. These types of changes are common with scripting technologies like JavaScript and are used extensively in AJAX applications. The ARIA specification provides methods for indicating dynamically changing portions of the page to the assistive technology. This is accomplished by defining "Live Regions" in a page. In our example, each score that changes is inside an <li> element.
    <li aria-relevant="text" aria-atomic="true" aria-live="polite">Access U <span id="our_score">0</span></li>
    These particular attributes tell the assistive technology that text is being added or removed, to read the entire contents of the region when it updates (aria-atomic), and to be polite when announcing changes. The polite setting tells the assistive technology to wait to notify the user of the change until the user has paused in reading the page. The opposite of "polite" is "assertive" meaning the user will be notified immediately.