Library IT Accessibility Training

1. Accessible
Web
Scott Williams
Office for Institutional Equity
swims@umich.edu
@swimsy
umich.edu/webaccess/

2. 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

3. 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. Questions?

10. Best Practices

11. 1. Navigation

12. 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

13. 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

14. 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

15. 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

16. 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.

17. 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}

18. 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

19. 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

20. 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>

21. 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">

22. <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

23. 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

25. 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

26. Form example
 Label attribute matches input id — not name
 Can insert “off-page” label if it would hinder sighted
users

27. 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

28. Form example 2

29. 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

30. 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” >

31. 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

34. Keep it simple
 Table readability on the web is difficult for everyone
 Avoid rowspans, colspans, horizontal and vertical
scrolling, and nesting tables

35. 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!

36. Mouse-dependent Event Handlers
 onClick
 onMouseOver and onMouseOut
 OnMouseDown
 onChange used with onSelect
 onHover

37. 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

38. onMouseOver and onMouseOut
 onMouseOver should be accompanied by onFocus
 onMouseOut should be accompanied by onblur

39. 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

40. 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

41. 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

42. 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

43. ARIA resources
 W3C’s WAI-ARIA Overview
(http://www.w3.org/WAI/intro/aria)
 WAI-ARIA Authoring Practices 1.1
https://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/)

44. 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

45. 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

46. Don’t use color alone to convey
meaning

47. Test in gray scale …

48. 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

49. 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

50. 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

51. Publishing PDF
 WebAIM Acrobat resource page:
http://webaim.org/techniques/acrobat/
 Office Accessibility Center:
https://goo.gl/Qnbi6l

52. 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/

53. W3C Validator

54. Questions?

55. Website Evaluation

56. 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

57. 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.

58. 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.

59. 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.

60. 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

61. 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.

62. 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

63. Demo: testing with the keyboard

64. Exercise: keyboard testing

65. 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

66. WAVE screen shot

67. Demo WAVE toolbar

68. Exercise: Testing with WAVE

69. U-M resources
 http://umich.edu/webaccess/
 Evaluation tools and procedures:
http://umich.edu/webaccess/eval/
 swims@umich.edu

70. 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