Accessible Web Scott WilliamsOffice for Institutional Equityswims@umich.edu@swimsyumich.edu/webaccess/

Goals

Learn the 4 principles of accessible interface design

Learn how to create accessible web content Learn how to evaluate a web interface for

accessibility

What is web accessibility?

Making the web accessible for the widest possible audience

This audience includes temporarily “able-bodied” users

Currently, online infrastructure is hostile to those with disabilities

Inseparable from usability, mobile, SEO: improve one and you improve the others

Best way to accomplish accessibility? Adherence to standards.

W3C WCAG 2.0 De facto standard world-wide. Cited in U.S case law.

Adopted by EU. ISO standard 40500:2012. W3C Web Content Accessibility Guidelines are

principle-, not technology-based The four principles (POUR):

Perceivable Operable Understandable Robust

Contain Guidelines (normative) and Success Criteria (advisory) for each principle

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 noise, movement, and distractions on page

Operable

All functionality is 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

Questions?

Best Practices

1. Navigation

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 and blocks of unwanted information

Link descriptions convey content of page and organization of site

ARIA document landmark roles highlight geographic regions of webpage

Browser “find” function used as last resort

Skip-to-content links

Not favored by screen reader users (!) Allows visual users who cannot use a mouse

to avoid tabbing through entire menu and sidebar

Place at top of document Jump to <h1> tag Must be visible on keyboard focus so

sighted keyboard users will know it’s there

Proper <h1> heading

Screen readers can find and list headings <h1> heading should uniquely identify the

page in the website The <h1> heading should also match at least

a subset of the the page <title> Should be placed directly in front of the main

content of the page, not in banner or footer

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 not be displayed when main item has focus (and exposed for hover)

Main menu items link to index pages that list subcategories

Complex menus with multiple columns and headings have negative effects 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">

<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” />

Example alt text

More guidelines

Images that are links must have alt text that describes the target

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

If the image needs further explanation, describe it in the inline text or a link to a separate page

   3. Forms

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

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

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

Keyboard accessibility

Make sure that forms 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

program tab order

Form example 2

4. Tables

Provide a table summary—what are you trying to prove, anyway?

Use table headings Use the scope attribute to define row and

column headings

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, 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: Widgets can be operated using the keyboard only Content is announced Focus is managed properly Context is conveyed

Native html elements have built-in a11y—which you must supply if you code a JS alternative!

Mouse-dependent Event Handlers

onClick onMouseOver and onMouseOut OnMouseDown onChange used with onSelect onHover

onClick

If you use onClick with an anchor tag or form control, most browsers and assistive technologies will be able to to trigger the event with the Enter/Return key

Scripted elements must contain an Enter/Return event handler. Keyboard testing will expose this common error.

Scripted elements must be inserted in tab order with “tabindex=0” so they can receive tab focus

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

It is inaccessible to everything but a mouse This fact can be taken advantage of , e.g.,

triggering submenus for mouse users but not screen reader and keyboard-only users

AJAX and ARIA Spec 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, states, 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

W3C’s WAI-ARIA Overview(http://www.w3.org/WAI/intro/aria)

WAI-ARIA Authoring Practices 1.1https://www.w3.org/TR/wai-aria-practices-1.1/

Hans Hillen’s examples(http://hanshillen.github.io/jqtest/#goto_slider)

Open Ajax Alliance examples (http://oaa-accessibility.org/examples/)

6. Color

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 WCAG 2.0 Level AA

Don’t use color alone to convey meaning

Test in gray scale …

7. Captioning

Good for those who are: Hearing 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 a11y hooks 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

WebAIM Acrobat resource page:http://webaim.org/techniques/acrobat/

Office Accessibility Center:https://goo.gl/Qnbi6l

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/

W3C Validator

Questions?

Website Evaluation

The design phase

Page designs must have sufficient color contrast

The default text size should be 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

Keyboard — using your tab, arrow, and enter keys

WAVE — Chrome browser extension aXe—Chrome browser extension Mac VoiceOver Universal Access — Mac native

screen reader

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.

Can you see keyboard focus? Operate menus Submit forms

Demo: testing with the keyboard

Exercise: keyboard testing

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 many more …

Icon key explains icons

WAVE screen shot

Demo WAVE toolbar

Exercise: Testing with WAVE

U-M resources

http://umich.edu/webaccess/ Evaluation tools and procedures:

http://umich.edu/webaccess/eval/ swims@umich.edu

Accessibility Resources

U-M: http://umich.edu/webaccess/ WebAIM: http://webaim.org Online accessibility checkers:

http://tenon.io/ http://wave.webaim.org/

Plug-ins: aXe: https://goo.gl/CpgsZd WAVE: https://goo.gl/LptVVT