University of Hawaii at Hilo

Meeting Accessibility Requirements for Web Pages

Last updated on September 25, 2019.

In this document:

Introduction

By Federal law and UH BOR policy, all content created by and for the University must meet certain standards for accessibility to visitors.

Consider the following:

Also consider device-based accessibility issues:

How does your website perform in all of these situations? It can be difficult to test your site for every type of disability, population type, or circumstance. But first and foremost:

Note Do not assume that the way you experience your website is the same way any one else experiences it.

You are not required to ensure your site looks and behaves exactly the same for everyone; you only must ensure that all of your visitors are able to navigate and consume the core content without undue burden.

This documentation aims to assist with improving your site accessibility with a mix of non-technical and technical information. Read more about accessibility on the UH ITS website for accessibility.

I. Abbreviations

In the accessibility community, a few abbreviations are commonly used.

For readability, however, the above abbreviations will not be used further in this document.

II. What are the Requirements?

A. Section 508 and WCAG 2.0

The current baseline standard for University of Hawaiʻi websites is Section 508 which is part of the Rehabilitation Act of 1973. Section 508 was refreshed in 2017 to adopt WCAG 2.0 levels A and AA. Visit the official Section 508 website for the full text of the standards, but the WebAIM Section WCAG 2.0 Checklist is an easier to read document describing each guideline and criteria.

While all level A and AA standards must be met, the most often violated standards are highlighted here.

WCAG 2.1 is a newer standard than WCAG 2.0 and is not required by Section 508, however it makes some important improvements, particularly in the domain of smaller screen sizes. While WCAG 2.0 A and AA is currently required, meeting WCAG 2.1 A and AA is highly recommended.

1. Alt Text for Non-Text Elements

WCAG 2.0, 1.1.1 Non-text Content (Level A).

A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

See the Content section of this document on Mixed Media for techniques to address this standard, specifically for audio, images, and video.

2. Color

Using Color for Identification

WCAG 2.0, 1.4.1 Use of Color (Level A).

Use additional content when conveying information using color.

The following code illustrates non-compliant and compliant uses of color.


<p>Active members are indicated with a
  <span style="color:green;">green *</span>
  and inactive members are shown with a
  <span style="color:red">red *</span>.</p>

<p>Active members are indicated as
  <span style="color:green;">(active)</span>
  and inactive members are shown as
  <span style="color:red">(inactive)</span>.</p>
Color Contrast

WCAG 2.0, 1.4.3 Contrast (Minimum) (Level AA).

Content must have sufficient color-contrast against its background to be easily distinguishable. See the Contrast Calculator section in Tools for determining contrast ratios.

3. Proper Markup for Tables

WCAG 2.0, 1.3.1 Info and Relationships (Level A).

Data tables, or tables that show content categorized by column or row, should properly use the <th> tag for header cells, <thead> for header rows, and <tbody> for rows in the table body.

The following code shows an example data table with proper semantic markup.

<table>
  <thead>
    <tr>
      <th>Semester</th>
      <th>Enrollment</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Fall 2016</td>
      <td>100</td>
    </tr>
    <tr>
      <td>Spring 2016</td>
      <td>85</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <td>Total</td>
      <td>185</td>
    </tr>
  </tfoot>
</table>

4. Proper Markup for Forms

WCAG 2.0, 1.3.1 Info and Relationships (Level A).

All visible <input>, <textarea>, and <select> fields should have descriptive <label> tags linked to them.

The following code shows examples of non-compliant fields and compliant fields.


<input type="email" name="user_email">

<label>Name:</label>
<input type="text" name="full_name">

<label for="email-input">Email:</label>
<input type="email" name="user_email" id="email-input">

<label>
  <input type="radio" name="resident" value="yes">
  Resident
</label>
<label>
  <input type="radio" name="resident" value="no">
  Non-resident
</label>

Proper labeling is particularly important for checkboxes and radio buttons as the labels serve as a larger interaction target than the relatively small inputs themselves.

WCAG 2.0, 2.4.1 Bypass Blocks (Level A).

Commonly, a web site will include a list of links near the top of the page as site navigation links. While helpful to the sighted visitor, screen reader users would hear every single link read to them on every page—a frustrating and time consuming experience. Proving a link before the navigation which jumps over the links or directly to the page content allows visitors to skip that long list on subsequent page visits.

The following code illustrates the use of a skip link.

<a href="#content" class="visuallyhidden">Skip to content</a>
<ul role="navigation">
 <li><a href="/">Home</a></li>
 <li><a href="/about/">About Us</a></li>
 ...
</ul>
<main id="content" role="main">
  <h1>Main content</h1>
  ...
</main>

In the above example, you'll also notice WAI-ARIA roles included and the use of a visuallyhidden CSS class to hide the skip link from non-screen reader visitors.

B. WAI-ARIA

Web Accessibility Initiative (WAI) Accessible Rich Internet Applications (ARIA) is a draft of standards which work in conjunction with Section 508 and WCAG 2.0 to improve web accessibility, particularly for modern web applications which employ JavaScript to modify page contents, even on-the-fly. The current WAI-ARIA draft specification has already been partially implemented in many Assistive Technologies, including ARIA Roles.

It is highly recommended to implement WAI-ARIA technologies in pages for improved accessibility.

III. Tools

This is not an exhaustive list of tools available but includes a few good free ones.

A. WAVE

The Web Accessibility Evaluation Tool (WAVE) is a web application and Chrome browser extension by WebAIM for evaluating a webpage's accessibility features.

WAVE tool screenshot
Screenshot of the WAVE tool showing accessibility errors.

WAVE includes a contrast checked which can help identify text that may be too difficult to read in low-vision and abnormal light brightness situations. Good contrast is not a Section 508 requirement but the WCAG 2.0 AA and AAA define varying contrast standards based on font sizes.

WAVE contrast errors screenshot
Screenshot of the WAVE tool showing contrast errors.

B. a11y-outline

Many screen readers like JAWS or NVDA have shortcuts to bring up a list of WAI-ARIA landmarks, headings or links. The a11y-outline] Firefox browser extension provides similar functionality.

a11y-outline landmarks example
Screenshot of the a11y-outline landmarks display.

a11y-outline headings example
Screenshot of the a11y-outline headings display.

a11y-outline links example
Screenshot of the a11y-outline links display.

C. Elinks or Links or Lynx

Using a command line text-only browser can be another good tool in testing the accessibility of your website. It will emulate the core page content, particularly as may be seen on a non-smartphone browser or similar to the content that may be read by a screen reader.

Links screenshot
Screenshot of the text-only Links browser viewing the UH Hilo home page.

As seen in the screenshot below of an inaccessible page, [IMG] shows in place of the linked image with no alt text and the color of the asterisks for active and inactive members is not shown.

Links screenshot of a demo inaccessible page
Screenshot of the text-only Links browser viewing the UH Hilo home page.

D. Contrast Calculator

Use of color should not only consider color blindness, but also poor vision or circumstance (washed out projector colors). The WCAG 2.0 standards (1.4.3 Level AA) require text to have at least a 4.5:1 contrast ratio in most cases to maintain readability.

Use a color contrast calculator when developing your site’s palette, such as the one linked.

Screenshot of a Contrast Calculator
Screenshot of a contrast calculator tool.

IV. Content

A. Link Text

Some Assistive Technologies allow visitors to navigate content by hyperlinks only. Providing context in the link text gives such visitors the ability to navigate your site without the context around each link. For example, in the Fangs links list screenshot above, only one link in that example page provides the context to the linked page.

Avoid link text which is repeated for multiple links but leads to different locations. For example, using Read more as the link text to continue reading an article is fine, but not when there are multiple read more links on a single page. Each read more link should provide context. Read more about …. A less preferred alternative is to add a title="unique specific title" parameter to each link while using non-unique link text such as “read more.”

B. Mixed Media

The standard requires that all non-text content have a text equivalent using techniques described below.

1. Audio

Provide a full transcript of the audio in a text-only format available for reading or download. Do not provide the transcript in a PDF document.

2. Images

Include either a caption to the photo or embed the caption in the image's "alt text". Adding the alt text will depend on the content management system used, but in HTML, this means adding alt="...caption..." to the img tag.

Good alt text is a short (around 100 characters or less) description of the image. Consider how you would describe the photo to someone over the phone. Do not use the words 'image' or 'photo' for alternative text. These alternative text guidelines from WebAIM offer examples of appropriate alternative text in a variety of situations.

3. Video

WCAG 2.0 Guideline 1.2 Time-based Media: Provide alternatives for time-based media..

Videos, whether recorded or live, must have embedded closed captions or a person signing. If neither captions nor signing are possible, a full text timestamped transcript must be available with the video.

Note that the captions or transcript must match the actual spoken words, not the script or notes used for the performance.

Some video websites such as YouTube offer built-in closed captioning tools which make captions very easy to add to videos.

YouTube captioning screenshot
Screenshot showing YouTube's built-in closed captioning tool.

C. Non-Web-Native File Types

When content requires a plugin to view (such as a PDF viewer), you must provide a link to download the plugin. For example, if a page links to a PDF file, that page shall have a link to Download the free Acrobat reader.

Warning Just because your browser may have a built-in PDF reader does not mean your visitors’ browsers have a built-in PDF reader.

It is also helpful to indicate to the visitor that a particular link is not a web page by indicating so in the link text. For example, "Download the Friday, May 13 meeting notes (PDF file)".

While PDF files are non-native, Adobe Acrobat provides a number of features which can greatly improve a PDF document’s accessibility using Adobe Acrobat Pro DC which is a paid product and different from the free Acrobat Reader. See Adobe’s Create and verify PDF accessibility (Acrobat Pro DC) for more information on working with PDF accessibility.

It is also worth noting that some PDFs are simply scanned images of paper documents versus PDFs generated from source files such as Microsoft Word. These collections of images are wholly inaccessibile and should be converted to a web-native format (HTML or text).

D. Capitalization

Many Assistive Technologies are smart enough to determine if something written in full capitalization (all caps) is an abbreviation or normal text, but some assume all capitals should be read letter by letter. Write your content using properly mixed case and use CSS, text-transform: uppercase;, to display content in all capitals.

Warning Avoid using all caps as fully capitalized text can be difficult for some readers, such as those with dyslexia.

In social media, use of #hashtags is commonplace. Use mixed case with multiple word hashtags for improved readability. For example, #GoVulcans is easier to comprehend by more people than #govulcans.

E. Extended Characters

Some Assistive Technology does not properly support extended characters such as the ʻokina and kahakō. This fault lies with the particular products and there is no easy solution to both work with incomplete technologies and use proper Hawaiian spelling, so your choice should be based on your individual campus’ style guide. The UH Hilo Website Style Guide suggests using proper Hawaiian spelling with full diacritics, however if your site’s or page’s content is specifically targeting Assistive Technology or its users, exceptions may be warranted.

F. Icon Fonts

Icon fonts have inherent accessibility issues so alternatives such as inline SVG are preferred. That said, a number of popular icon fonts enjoy widespread use, but they are not often employed with accessibility features. When used in conjunction with ARIA roles and text only for screen readers, icon fonts can be used to maximize their accessibility within the limitations of icon fonts.

The following code illustrates the use of the FontAwesome icon font with accessibility features.

<a href="/sign-up/">
  <i class="fa fa-pencil-square-o fa-3x" aria-hidden="true" aria-role="presentation"></i>
  <span class="visuallyhidden">Sign up now</span>
</a>

V. Common Questions

A. When must my content be accessible?

Your content must meet accessibility standards at the time of posting. You may not post non-compliant content with a “we’ll fix it later” intent as “later” rarely, if ever, comes.

B. What if my content is limited in scope or availability (e.g., only on Laulima)?

The standard of “fully accessible at the time of posting” still holds, however, if you do not have a student or staff member with a reported disability, the risk of getting in trouble for non-compliance is low. If you plan on reusing the content or keeping it available for any length of time, it is worth the effort to be compliant from the start.

VI. Technical Techniques

A. Text Only for Screen Readers

Warning Do not hide elements with display: none; or visibility: hidden; as this will also hide them from most screen readers.

Many frameworks include CSS classes such as .sr-only or .visuallyhidden which are intended to hide content for visual users but not from screen readers. Common uses for such classes are for hiding form labels and icon font only links.


<form>
  <input type="search" id="site-search" placeholder="Search this site">
  <input type="submit" value="Go">
</form>

<form role="search">
  <label for="site-search" class="visuallyhidden">Search this site:</label>
  <input type="search" id="site-search" placeholder="Search this site">
  <input type="submit" value="Go">
</form>

Adding a label tag meets the accessibility requirement but because the label is undesired for this design example, the .visuallyhidden class is applied to it. Note also the addition of the role to the form which further improves its accessibility.

Also see the section on Icon Fonts when using icons as field labels.

B. Hiding Design Elements From Screen Readers

Elements only for visual design may be used, but still require alt text. Adding the presentation WAI-ARIA role and aria-hidden further improve accessibility.

<img src="border-design.png" alt="" role="presentation" aria-hidden="true">

More complex visual design elements, such as a linked image followed by a linked title works great for visual visitors but is duplicative and cumbersome for non-visual visitors. Adding aria-hidden, the presentation ARIA role, and tabindex="-1" to the duplicate anchor, along with the normal image markup can hide further hide the repetitive content from the Assistive Technology.

<a href="article.html" aria-hidden="true" role="presentation" tabindex="-1">
  <img src="thumbnail.jpg" alt="image description" role="presentation">
</a> 
<a href="article.html"><h3>Link to article</h3></a>

Contact

For more information on meeting accessibility requirements for websites, please contact Sunny Walker and review the UH ITS website for accessibility and other resources listed in this document.