Last updated on September 25, 2019.
In this document:
- I. Abbreviations
- II. What are the requirements?
- III. Tools
- IV. Content
- V. Common Questions
- VI. Technical Techniques
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:
- Color blindness (red weakness, blue weakness, etc.)
- Low-vision (e.g., from cataracts, glaucoma, etc.)
- Full blindness
- Lack of fine motor control (e.g., tremors)
- Cognitive disabilities (e.g., dyslexia, under considerable stress, weak ability in the language in which the page is written (non-native speakers), etc.)
Also consider device-based accessibility issues:
- Very large monitors
- Very small monitors
- High definition (HD/retina) and low definition (TV) displays
- Mobile devices (including non-smartphones)
- Multiple orientations (portrait/landscape)
- Different input methods (mouse, pen, finger, no keyboard, voice command, etc.)
- Very slow internet connection speed
- Printed on paper (in color or in black ink only)
- Projected (washed out, bright light, or low light)
- User overridden style sheets
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:
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.
In the accessibility community, a few abbreviations are commonly used.
a11ystands for accessibility and is simply the beginning "a" and ending "y" and the 11 letters between the two.
ATstands for Assistive Technology and refers to technology-based aids. Examples of AT are screen readers and other text-to-speech devices.
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.
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>
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.
- Text and images of text must have a contrast ratio of at least 4.5:1.
- Large text - at least 18 point (typically 24px) or 14 point (typically 18.66px) bold must have a contrast ratio of at least 3:1.
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).
<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.
5. Skip Links
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>
It is highly recommended to implement WAI-ARIA technologies in pages for improved accessibility.
This is not an exhaustive list of tools available but includes a few good free ones.
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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.
- Captioning YouTube Videos
Step-by-step guide to adding captions to an uploaded video. Also available as a one page PDF.
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.
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).
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.
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
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
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
.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>
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.
- UH Hilo templates include the
.visuallyhiddenclass from the HTML5 Boilerplate.
- The Twitter Bootstrap framework includes the
- The Zurb Foundation framework includes the
- The newer WordPress default themes such as twentyseventeen and twentynineteen include the
Also see the section on Icon Fonts when using icons as field labels.
B. Hiding Design Elements From Screen Readers
<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
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>