WCAG 2.0 Basic Principles, Guidelines, and Tips

The following are guidelines based off of the Web Accessibility Initiative’s (WAI) WCAG2.0 Guidelines for building accessible web content. These requirements must be met for all documents posted publicly to the internet including web pages, Word, PowerPoint, Excel, and PDF documents.

Perceivable

– Information and user interface components must be presentable to users in ways they can perceive.

Guideline 1.1

  • Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language
  • Example: Use the <alt> attribute with images. For images that are not important or decoration use <alt="">
    • <img src="smiley.gif" alt="Smiley face">
  • Decision Tree: The W3C decision tree describes how to use the alt attribute of the <img> element in various situations.

Guideline 1.2

Guideline 1.3

  • Adaptable: Create content that can be presented in different ways without losing information or structure
  • Example: Use headings (<h1-h6> in proper outline form), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>), etc. appropriately

Guideline 1.4

  • Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
  • Example: Don’t use color or visuals as the sole method for conveying information and ensure good color contrast between the content and backgrounds. Provide a mechanism to stop/pause content that automatically plays on a page.

Operable

– User interface components and navigation must be operable.

Guideline 2.1

  • Keyboard Accessible: Make all functionality available from a keyboard.
  • Example: Make sure that all elements of the page are navigable via the Tab key and that the focus outline is visible in your CSS. Ensure that all javascript plugins used also support keyboard control and do not trap the visitor’s navigation by keyboard.
    • a:focus { outline: thin dotted; }

Guideline 2.2

  • Enough Time: Provide users enough time to read and use content
  • Example: If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit. This is not a requirement for real-time events (e.g., an auction), where the time limit is absolutely required, or if the time limit is longer than 20 hours.

Guideline 2.3

  • Seizures: Do not design content in a way that is known to cause seizures (more than 3 changes/flashes per second)
  • Example: Do not use flashing text or colors

Guideline 2.4

  • Navigable: Provide ways to help users navigate, find content, and determine where they are
  • Example: Provide links to skip the navigation of a page and/or a link to skip back to the top of the page and/or top of the main page content. Links and form elements should be logical and intuitive.
    • <body>
      <a href="#maincontent">Skip to main content</a>
      ...
      <main id="maincontent>
      <h1>Heading</h1>
      <p>This is the first paragraph</p>

Understandable

– Information and the operation of user interface must be understandable.

Guideline 3.1

  • Readable: Make text content readable and understandable
  • Example: Define the language of the page using <html lang="en"> tag and inline elements which differ from the page’s primary language <i lang="haw">aloha kakahiaka kākou</i>. Use a glossary, or definition list when necessary for ambiguous or unknown words. Use <abbr> element to define abbreviations.
    • <abbr title="University of Hawaii at Manoa">UHM</abbr>

Guideline 3.2

  • Predictable: Make web pages appear and operate in predictable ways
  • Example: On focus and on input, interactions should not result in a substantial change to the page or spawn pop-up windows.

Guideline 3.3

  • Input Assistance: Help users avoid and correct mistakes
  • Example: Provide error identification where user input is required, such as form field validation. Include proper <label> tags for input and select elements and any instructions for required interactive elements.

Robust

– Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Guideline 4.1

  • Compatible: Maximize compatibility with current and future user agents, including assistive technologies
  • Example: Avoid parsing errors and use markup in a way that is accessible by following HTML/XHTML specifications.

Specific requirements can be found at https://www.w3.org/WAI/WCAG20/quickref/

Additional Accessibility Tips

The following rules are based on the WAI WCAG 2.0 Web Accessibility Guidelines. Adhering to these rules when creating course content can assist in making course sites more accessible. These guidelines are just some of the methods used to help make web sites more accessible:

For more extensive information on accessibility and what you can do to make your web site accessible to all, please visit World Wide Web Consortium’s Web Accessibility Initiative.

Text Information

Provide accurate descriptions for text links

  • Reason: Accurate information of where links will lead help users navigate your site more effectively.
  • Solution: Provide a clear and concise text descriptor about the nature of the link. Long lists of links should be organized in a logical manner. Avoid text links such as “Click here”. Users with a screen readers who jump from link to link or list links will only hear “Click here”.

Image Maps

Use Client-side Image Maps instead of Server-side image maps whenever possible

  • Reason: Client-side image maps allow the author to add <alt> attribute for the links which will allow screen readers or text based browsers to identify the hot spots. A server-side image map merely provides the coordinates of the hot spots in an image map and the browsers cannot indicate to the user the URL that will be followed when a region of the map is activated.
  • Solution: Provide <alt> attribute in client-side image maps for each link and if server-side image maps are used, provide redundant text links. Its also common to provide redundant text links for client-side image maps also.

Style Sheets

Use Style sheets to structure layout and properties of content

  • Reason: Style sheets can be used to control color, font, sizes and spacing for an entire web site. This reduces the amount of html code in a web site making it easier for screen readers to navigate. It also makes it easier to change a whole web site. For example, if you need to change the size of headings or fonts, all you need to do is change the properties in the style sheet.
  • Solution: Use internal style sheets (placing the style sheets in the <head> tag of an HTML document or external style sheet, (style sheet is in a separate file). Often, style sheets are referred to as “Cascading Style Sheets” or CSS which are templates, very similar to templates containing a set of rules specifying the rendering of various HTML elements. These templates describe how a document is presented on the screen or when printed out.

Make sure a web page is accessible without a style sheet

  • Reason: Some assistive technology devices may have trouble with style sheets or a browser may not support it.
  • Solution: Test to make sure your web site can be viewed logically without style sheets.

Java, Javascript and Applets

When using JavaScript, provide functional text equivalence for screen readers

  • Reason: If functional text is provided describing the action occurring within the JavaScript, the screen reader can read the information to the user. Without functional text, the screen reader will read the JavaScript itself resulting in a meaningless jumble of numbers and letters.
  • Solution: One method is to include the <alt> attribute with a JavaScript. For example: <a href="javascript:myFunction();"><img src="myFunction.gif" alt="image link for starting myFunction"></a>.Another method involves the <title> attribute of the <a> tag. For example: <a title="this link starts myFunction" href="javascript:myFunction();"><img src="myFunction.gif"></a>

Use Event Handlers that allow for accessibility

  • Reason: Some event handlers require mouse input which create accessibility problems.
  • Solution: Use event handlers that have been tested for accessibility.

The following JavaScript event handlers have been found to work with assistive technology:
onClick – State clearly on the page what will occur with this event handler. Don’t use onClick for form elements that include several options (e.g., select lists) unless absolutely necessary.
onLoad and onUnload – Since these event handlers are not triggered by user input, accessibility is not a problem.

Avoid using these JavaScript event handlers:
onDblClick – Requires mouse input and can be confusing.
onMouseDown and onMouseUp – Also require mouse input. Use the onClick event handler instead.
onChange – Use only if you associate it with a link or button that is adjacent to a tag.

Other JavaScript handlers that don’t usually pose a problem with AT, but don’t provide useful information to them and could create confusion
onMouseover and onMouseOut, onBlur and onFocus.

Java Techniques

The Java 2 Platform features built-in accessibility support that allows developers to produce applications that work with AT. A component uses the Java Accessibility API extension by using the “Accessible” interface. This is done with, getAccessibleContext(), which returns an instance of AccessibleContext specific to the component allowing it to become accessible.

Use the AccessibleName and AccessibleDescription on all components. The AccessibleName property is the key to make objects usable by a person with a disability. Use a label (no more than two words) that describes the purpose of the component. An AccessibleDescription can also be added if the purpose of the component is not obvious from its name. This will provide more information for the assistive technology device. For example, a button for Enter could have an AccessibleName of “Enter button”. A Cancel button could have an AccessibleName of “Cancel button”. The cancel button can also have an AccessibleDescription of “Ignore entry and close dialog box”.

Applets

Use the <alt> attribute (only for browsers that support Java). Put text between <Applet> or <Object> tags.

Example: <APPLET CODE=?Appletinventory.class" WIDTH="200", HEIGHT="100">
This applet displays current list of items in stock.
</APPLET>

Resources

Sun Java Tutorial: http://java.sun.com/docs/books/tutorial/uiswing/misc/index.html

Accessible PDF’s

Provide an alternate way to view PDF’s, or create them to be accessible.

Forms

Include an alternative to online forms

  • Reason: Forms can be difficult to for people using screen readers and may not be supported by all browsers.
  • Solution: Allow the user to print out the form, send email, phone or FAX. Forms should be navigable using the Tab key which are commonly used in screen readers.

Use the <label> tag for forms (Not necessary for simple forms where all the form elements are adjacent or right under labels).

  • Reason: Its always a good idea to provide alternate means to an online form, however you can make forms accessible to screen readers.
  • Solution: Use the tag and the associated <for> attribute to associate form elements with specific labels. The <label> tag will identify the form element (e.g. text area, check box etc.) with a label. Also use the “FOR” attribute and make it equal the item in the “ID” attribute which will “tie” the form element to the associated label. Without the Label tag, a screen reader may get confused as to which label to pair the form element resulting in data entered into the wrong element. For example:


<FORM>
<TABLE>
<TR>
<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME" ID="first" ></TD>
</TR>
<TR>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME" ID="last" ></TD>
</TR>
</TABLE>
<P>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>

 

Adobe Animate

Testing Your Web Site

  1. Test markup against WCAG 2.0 Guidelines with the Siteimprove Browser Extension. Markup should pass with WCAG 2.0 AA or better.
  2. Make any changes to markup, if needed, based on the results from the test. Test again if necessary, and then proceed to the next step.
  3. Test with a screen reader using JAWS if available or NVDA, which is free from http://www.nvda-project.org/ for readability.
  4. Check navigation with keyboard. Best tested by using a screen reader, your computer monitor turned off, and your speakers/headphones turned on.
  5. Check for usability/readability when zoomed into 200-300%.

WAI-ARIA Guidelines

  • AJAX
  • HTML 5
  • Oracle Java
  • Adobe Flash
  • Microsoft Silverlight

More information about the WAI-ARIA guidelines can be found at http://www.w3.org/WAI/intro/aria.php and at Accessible Rich Internet Applications (ARIA). Accessible HTML and ARIA code samples at Va11yS.

Note: Markup validation is not available for WAI-ARIA content. Please make sure you follow the accessibility guidelines and procedures for the platform you are using.