Accessible Web Scott WilliamsOffice of Institutional Equityswims@umich.edu@swimsy

Goals

Understand the nature of disabilities and how they relate to the web

Learn the 4 principles of accessible web design

Learn how to create accessible web content

Learn how to evaluate web accessibility (second session)

Disabilities and the web

Visual: blindness, low-vision, color-blindness

Hearing: partial to total deafness

Motor: inability to use a mouse or physical keyboard, slow response time, limited fine motor control

Cognitive: Learning disabilities, distractibility, dyslexia, inability to remember or focus on large amounts of information

1in 5 people have a disability

People with disabilities in the U.S: 54.4 million

People in U.S. with disabilities that impede them using the internet: 24 million

People age 15 and older having difficulty hearing a normal conversation: 8 million. Completely deaf: 1 million

People age 15 and older having difficulty reading ordinary newsprint (even with glasses):

8 million. Completely blind: 1.8 million

A diverse population

Cognitive disabilities Adults with ADD/ADHD: 16 million 38% of soldiers, 31% of Marines and 49% of National

Guard members returning from combat report psychological conditions such as TBI and PTSD

Greater number than physical and perceptual disabilities combined

Mobility issues—8 million Americans have difficulty using their arms or hands

11 million people 6 and older need assistance with everyday activities

More stats

8.3% of the U.S. population have 2 or more disabilities

40,000 people the in U.S are both deaf and blind

41 percent of adults 65 and older have a disability

8.7 million people with disabilities are poor

70% of disabled are unemployed

Most influential disabled user

Google, “the blind billionaire” — Jeffery Zeldman

The web offers unprecedented opportunities for disabled

Education

News

Commerce

Social

Benefits of web are amplified for disabled

Web is an enabling technology

Legal

DOJ is in the process of revising Title II and III of the ADA to include online resources of state and local entities

ETA of revised rules: 2 years out

Smart money: will be based on W3C WCAG 2.0 de facto standard, Level A or AA

DOJ not interested in the budgetary or logistical reasons for why you are violating someone’s civil rights

Case law—individuals or entities can file civil rights complaints, e.g., Target, Southwest Airlines, Priceline.com, Ramada, Kindle, and LSAC

What is web accessibility?

Making the web accessible for the widest possible audience

This audience includes temporarily able-bodied users (TABs)

Inseparable from usability: improve one and you improve the other

Best way to accomplish accessibility? Adherence to standards.

WCAG 2.0

De facto standard world-wide. Cited in U.S case law. Adopted by governments.

W3C Web Content Accessibility Guidelines are principle-, not technology-based

The four principles (POUR): Perceivable Operable Understandable Robust

Perceivable

Provide text alternatives for images and form elements

Provide captions and transcripts for video and audio

Use correct semantic markup so content can be presented in different ways

Make it easier for users to see content by using good color contrast

Avoid movement and distractions on page

Operable

All functionality available from the keyboard!

Users have control over timing and limits

Do not cause seizures (don’t flash content)

Provide ways to help users navigate, find content, and determine where they are

Understandable

Economical and plain use of language

Text supplemented with illustrations, videos, and other formats where appropriate (i.e., use good Universal Design)

Navigation, information structure are discernable and consistent

Make pages operate in predictable ways

Help users avoid and correct mistakes

Robust

Functional across various technologies

Syntax errors that don’t affect visual presentation may hamper assistive technology and accessibility evaluation tools

Adhering to W3C standards ensures future compatibility

Validate your code at validator.w3c.org

Screen reader demo

Best Practices

1. Navigation

Navigation is a critical aspect of accessibility

Information being apparent isn’t enough

Sighted users have tried and true visual cues to orient them on a page Banner Search box Main navigation box Content well

Blind and low-vision users rely on proper coding of page for orientation

What if you can’t see?

Title of page lets you know what page you’re on when page loads

Proper heading placement and hierarchy conveys organization of page and allows SR users to skip navigation

Link descriptions convey content of page and organization of site

ARIA document landmark roles highlight geographic regions of webpage

Browser find function used as well

Skip-to-content links

Not favored by screen reader users (!)

Allows those who cannot use a mouse to avoid tabbing through entire menu and sidebar

Place at top of document; limit to 3

Jump to <h1> tag, which should always directly precede main content

Should be visible on keyboard focus so sighted keyboard users will know it is there

Proper <h1> heading

Screen readers can find and list headings

<h1> heading uniquely identifies the page in the website

Should be placed directly in front of the main content of the page

The <h1> header should also match at least a subset of the the page <title>

Proper heading hierarchy

Headings need to be properly nested to convey organization of the page

<h2> tags follow the <h1> tag, the <h3> tags follow the <h2> tags, etc.

Off-page headings

Useful when you want to give SR users a navigational aid without cluttering presentation for sighted users

Examples: Main and local navigation, search, etc.

Use CSS to position headings off-page

.offpage {position: absolute; left: -1000px;}

Don’t use {display:none} or {visibility: hidden}

Meaningful link text

Screen readers can find and list links

Descriptions for the links must be meaningful out of context, via tabbing or presented in a list

Don’t use “here”, “click here”, “read this”, and “more”

Don’t use URL as a link description—will sound like gibberish, unless very short and intuitive

Accessible menus

Main navigation needs to be operable using the keyboard only

Subcategories should be visible on keyboard focus

Main menu items link to index pages that list subcategories

Complex menus with multiple columns and headings have negative effect on those with cognitive impairments, low vision, and motor impairments

Document landmark roles

They do what good visual layout does for sighted users

Call out main geographic areas of web page: Banner Navigation Search Main content Auxiliary content Posted content Footer information

<div id="maincontent" role="main"></div>

2. Text equivalents

All informative non-text elements must be accompanied by text equivalents Informative images graphical representations of text (including drop

caps, equations, and symbols) form controls and text fields graphical buttons and links audio files and podcasts Videos

<img src="mlogo.gif" alt="University of Michigan Block M logo">

There is no typical SR user

I don’t want to miss out on any content!

I’m listening to a page at 400 words per minute with a robotic computer voice — I don’t care about the mood and feel of the page

OK …

Focus on the content and the function of the image

<img src=“wall_sm.jpg” alt=“young man on a climbing wall reaching for a hold, which symbolizes a navigation element available to assistive technology” />

More guidelines

Images that are links must have alt text that describes the landing page, preferably the page title or heading text

Keep text to “tweet length”, 140 characters or less

If the image needs further explanation, use a longdesc element pointing to a URL, or describe the image inline

<img src="graph.jpg” alt="Graph of percentage of total U.S. population age 16–64 declaring one or more disabilities" longdesc="media/description.htm">

   3. Forms

Use <label> tag to describe form fields and controls to screen reader users (is a form of alternative text)

Use <fieldset> and <legend> tags when necessary to group form elements together (not for layout)

Keep form labels close to their associated controls

Make sure the form is operable using just the keyboard

Form example

Label attribute matches input id — not name

Can insert “off-page” label if it would hinder sighted users

Form layout

There is nothing inherently inaccessible about simple, non-nested tables

Be aware that the visual layout of a table does not equal the reading order

A screen reader parses a table left to right and top to bottom

Make sure that the label’s cell directly precedes the associated form control or text-entry cell

Keyboard accessibility

Make sure that form widgets can be operated using the keyboard only

Make sure reading order and tab order are logical and intuitive

Source order = tab order

Use source order, not tabindex attribute, to determine tab order

Form example 2

4. Tables

Provide a table summary

Use table headings

Use the scope attribute

Table summary

The summary conveys the context or conclusion of the table data (what is the table demonstrating?) to assistive tech users

This is accomplished by adding a summary attribute to the table tag:

<table summary="Tensile strength of structural materials showing the superiority of multiwalled carbon nanotubes” >

Table headings and scope attributes

Use the <th> tag to designate the table headings

The scope attribute is used to further define the row and column headings for your data table

These attributes can be read along with the individual data cell by a screen reader

Keep it simple

Table readability on the web is difficult for everyone

Avoid rowspans, colspans, excessive horizontal and vertical scrolling, and nesting tables

5. Scripting

Using javascript does not make your site inaccessible

Most screen readers can interact with javascript

As long as a user can operate widgets using the keyboard only

And changed content is apparent to a screen reader

Mouse-dependent Event Handlers

onClick

onMouseOver and onMouseOut

OnMouseDown

onChange used with onSelect

onHover

onClick

Use onClick only with an anchor tag or form control

Most browsers and assistive technologies will be able to to trigger the event with the Enter key

onMouseOver and onMouseOut

onMouseOver should be accompanied by onfocus

onMouseOut should be accompanied by onblur

OnMouseDown

If the onMouseDown, onMouseUp and onMouseMove event handlers are used, equivalent functionality also needs to be implemented through the keyboard as well

Provide an alternate means of interacting with the web page

onChange used with onSelect

The combination of the onChange and onSelect event handlers can cause problems for keyboard-only users

Although they are device independent, they need to be tested with the keyboard to ensure that they are accessible

onHover

onHover must die

It is inaccessible to everything but a mouse

Touch-screen technology is the death knell

AJAX and ARIA

ARIA = Accessible Rich Internet Applications

The use of AJAX introduces new challenges in accessibility

Updating information on a page without a page refresh can disorient assistive tech users or leave them unable to view the updated content

ARIA roles and properties are a means of making AJAX widgets accessible and info apparent

The scope of ARIA role and property code is limited to assistive technologies

ARIA resources

University of Illinois ARIA examples (http://test.cita.illinois.edu/aria/)

CodeTalks website(http://wiki.codetalks.org/)

Paciallo Group listing of ARIA-enabled libraries(http://www.paciellogroup.com/blog/?p=313)

AOL Developer Network accessibility website(http://dev.aol.com/topic/accessibility)

Java

Same POUR principles apply to Java

The Java Foundation Classes (JFC), a.k.a. Swing, and their implementation of accessibility methods in the user interface components are an easy way to incorporate accessibility into designs.

The Java Accessibility API. If developers choose to create components themselves, they should implement this API.

IBM Guidelines for Writing Accessible Applications Using 100% Pure Javahttp://www-03.ibm.com/able/guidelines/java/snsjavag.html

6. Color contrast

An often overlooked aspect of web accessibility

Many more people are visually impaired or color blind than are legally blind

There are tools that quantify the contrast between text and its background

Check your web templates’ color contrast during design phase

What is color contrast?

You intuitively know when something has poor contrast

There is an algorithm for determining a numerical value

Ratio of foreground luminance to background luminance

Big is good: 4.5:1 or greater for Level AA

7. Captioning

Good for those who are: Aurally impaired Do not have access to audio In a quiet and/or public setting Not fluent in the native language of the audio or

video Cognitively disabled

Subtitles increase the amount of time that a user spends watching a video by almost 40 percent

Where subtitles appear, 80 percent more people watch the entire video to its completion

8. Accessible word & pdf

As in the web environment, navigation and orientation are key tasks a screen reader user must perform

Word and pdf docs need hand holds too

Create structured MS Word docs

Use heading styles for headings

Use the table-of-contents utility

Provide alternative text for images

Use the table utility to create tables

Use styles for formatting text

We want to ensure that assistive tech metadata is transferred to PDF

Publishing PDF

Use the Microsoft Office PDF add-in (http://goo.gl/eaDP)

Or … if you have installed Acrobat Pro after installing Microsoft office, you will automatically have access to the PDFMaker add-on.

http://umich.edu/webaccess/best/pdf.html

9. Web standards

Many webmasters avoid validating their HTML and CSS code because they view it as limiting and a time sink

However, adhering to standards helps to ensure that everyone has access to the information on web pages

Assistive technologies depend on syntactically correct HTML

Validate your code: http://validator.w3.org/

Advantages of using web standards

A variety of devices will be able render your website properly

Web content can be converted more easily to other formats, such as databases and Word documents

Your website code will work with older and future web browsers

Search engines rank pages higher if they validate and will index your site more accurately

W3C Validator

Accessibility Resources

U-M: http://umich.edu/webaccess/

WebAIM: http://webaim.org

Online accessibility checkers: http://www.achecker.ca/ http://wave.webaim.org/

Website Evaluation

The design phase

Page designs must have sufficient color contrast.

The default text size should be large large enough for older people and folks with visual impairments to read.

The navigation should be simple and the visual layout clean.

Features that involve motion should be opt-in.

Building the templates

Validate your code.

Use CSS for layout.

Set up your skip navigation links.

Implement document landmark roles.

Define a unique <title> for each page.

Place the <h1> heading directly before the main content, and make sure it matches at least part of the <title>.

Specify a DOCTYPE and language definition for each page.

Populating the website

Use a proper heading hierarchy to organize your page.

Use correct markup for your data tables.

Make sure your form controls and data entry fields are labeled.

Give your images meaningful alt text.

Caption and make transcripts for your video, and make transcripts for your audio.

Launch and maintenance

Include a contact for web accessibility complaints.

You should also post an accessibility statement page that includes contact information. Put it after your “skip nav” link.

Evaluation tools

The keyboard

Keyboard accessibility is one of the cornerstones of web accessibility.

Screen reader users and those with motor impairments cannot use a mouse.

You should be able to easily navigate to any part of your web pages or website and perform all functionality using just the keyboard.

Testing keyboard accessibility

Unplug your mouse

Employ the tab, arrow, return, and spacebar keys.

Tab through the entire page. Note sequence.

Operate menus.

Submit forms.

Evaluate the number of links on the page. Copy all into buffer Paste into text file Select the “Check Accessibility by File Upload” option

Concentrate on “Known Problems”, but scan “Likely” and “Potential” as well.

AChecker

An online accessibility evaluator.

On a single page: cites the line number of the accessibility

violation shows the errant code gives the appropriate remediation links to a resource page specific to the problem

Concentrate on “Known Problems” category.

AChecker screen shot

Using AChecker

Enter URL of site you are affiliated with

Select compliance level under “Options” link

If an authenticated page: View source

Demo AChecker

Exercise: Testing with AChecker

WAVE Accessibility Toolbar

WAVE uses a distinctive icon approach in displaying accessibility information.

Displays: missing alternative text for images missing form labels table structure script elements and event handlers document structure and reading order and much more

Icon key explains icons

WAVE screen shot

Demo WAVE toolbar

Color contrast checker

NVDA screen reader

NonVisual Desktop Access (NVDA)

Free and open source screen reader for the Microsoft Windows operating system.

Has the ability to run entirely from a USB drive with no installation.

Slimmer command set than JAWS

Testing with NVDA

NVDA runs on top of Windows.

NVDA intercepts the arrow keys and some other keys to offer additional navigation operations for the user.

NVDA has two different viewing modes: “Browse mode” and “Forms” mode.

Sample protocol: http://umich.edu/webaccess/eval/nvda.html

Sample NVDA shortcut keys

Down-arrow: read next item

h and shift+h: read next and previous heading

k and shift+k: read next and previous link text

f and shift+f: go to next or previous form field

t and shift+t: go to next or previous table

Insert+t: read title

Demo NVDA

Exercise: Testing with NVDA