Intro to web accessibility

1,820 views
1,754 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,820
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Not just blindness. A very diverse community.
  • 1 in 10 have a disability that will affect their using the internet
  • Not just blind and deaf …

    Avoid motion on screen.

    Keyboard accessible and don’t make fine motor control necessary.
  • We have created an adverse environment: social and technological.
    Our technical infrastructure needs to allow the disabled to work.
    Example: VCM interface completely flash-based.
  • Life is circumscribed for disabled. Everything the web does for able-bodied is amplified for disabled.
  • Besides being the right thing to do … we have legal considerations.
  • In general terms …

    The beauty of the standards are that you don’t have to keep in mind every conceivable disability when you are coding your site.

  • This is a departure from WCAG 1.0, which references specific technologies, such as javascript
  • Captions, screen reader, Braille display
  • Chunking appropriately, avoiding jargon or institutional language
    Different learning modalities, visual versus verbal
    Don’t change nav and layout structure
    Careful with AJAX-y elements, pop-ups
    Considerate form validation; especially important for ITS
  • Headings, links, and landmarks are like hand-holds on a climbing wall.

    Without them, assistive tech user must parse linearly through a web page.
  • What are those hand holds?
  • Don’t select heading levels for their default size—use CSS to style your headings.
  • Announced with a screen reader.
    Semicolon key cycles through regions.
    Note that these perform same function as off-page headings.
  • Think about how alt text relates to the inline text as well.
  • Labels are also a form of alternative text.
  • Running form through WAVE validator
  • Use Gateway as example
  • Intro to web accessibility

    1. 1. Accessible Web Scott Williams Office of Institutional Equity swims@umich.edu @swimsy
    2. 2. 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)
    3. 3. 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
    4. 4. 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
    5. 5. 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
    6. 6. 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
    7. 7. Most influential disabled user  Google, “the blind billionaire” — Jeffery Zeldman
    8. 8. The web offers unprecedented opportunities for disabled  Education  News  Commerce  Social  Benefits of web are amplified for disabled  Web is an enabling technology
    9. 9. 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
    10. 10. 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.
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 14. 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
    15. 15. 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
    16. 16. Screen reader demo
    17. 17. Best Practices
    18. 18. 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
    19. 19. 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
    20. 20. 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
    21. 21. 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>
    22. 22. 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.
    23. 23. 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}
    24. 24. 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
    25. 25. 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
    26. 26. 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>
    27. 27. 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">
    28. 28. 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
    29. 29. <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” />
    30. 30. 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">
    31. 31. 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
    32. 32. Form example  Label attribute matches input id — not name  Can insert “off-page” label if it would hinder sighted users
    33. 33. 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
    34. 34. 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
    35. 35. Form example 2
    36. 36. 4. Tables  Provide a table summary  Use table headings  Use the scope attribute
    37. 37. 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” >
    38. 38. 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
    39. 39. Keep it simple  Table readability on the web is difficult for everyone  Avoid rowspans, colspans, excessive horizontal and vertical scrolling, and nesting tables
    40. 40. 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
    41. 41. Mouse-dependent Event Handlers  onClick  onMouseOver and onMouseOut  OnMouseDown  onChange used with onSelect  onHover
    42. 42. 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
    43. 43. onMouseOver and onMouseOut  onMouseOver should be accompanied by onfocus  onMouseOut should be accompanied by onblur
    44. 44. 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
    45. 45. 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
    46. 46. onHover  onHover must die  It is inaccessible to everything but a mouse  Touch-screen technology is the death knell
    47. 47. 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
    48. 48. 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)
    49. 49. 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 Java http://www- 03.ibm.com/able/guidelines/java/snsjavag.html
    50. 50. 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
    51. 51. 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
    52. 52. 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
    53. 53. 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
    54. 54. 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
    55. 55. 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
    56. 56. 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/
    57. 57. 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
    58. 58. W3C Validator
    59. 59. Accessibility Resources  U-M: http://umich.edu/webaccess/  WebAIM: http://webaim.org  Online accessibility checkers:  http://www.achecker.ca/  http://wave.webaim.org/
    60. 60. Website Evaluation
    61. 61. 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.
    62. 62. 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.
    63. 63. 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.
    64. 64. 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.
    65. 65. Evaluation tools
    66. 66. 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.
    67. 67. 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.
    68. 68. 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.
    69. 69. AChecker screen shot
    70. 70. Using AChecker  Enter URL of site you are affiliated with  Select compliance level under “Options” link  If an authenticated page:  View source
    71. 71. Demo AChecker
    72. 72. Exercise: Testing with AChecker
    73. 73. 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
    74. 74. WAVE screen shot
    75. 75. Demo WAVE toolbar
    76. 76. Color contrast checker
    77. 77. 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
    78. 78. 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
    79. 79. 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
    80. 80. Demo NVDA
    81. 81. Exercise: Testing with NVDA

    ×