Download to read offline
Lit 20170306
- 1. Accessible Web Scott Williams Office forInstitutional Equity swims@umich.edu @swimsy umich.edu/webaccess/
- 2. Goals Learn the4 principles of accessible interface design Learn how to create accessible web content Learn how to evaluate a web interface for accessibility
- 3. What is webaccessibility? 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 textalternatives 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 functionalityis 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 andplain 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 acrossvarious 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.
- 10.
- 11.
- 12. Navigation Navigation isa 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 youcan’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 Notfavored 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 Usefulwhen 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 Mainnavigation 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=“youngman on a climbing wall reaching for a hold, which symbolizes a navigation element available to assistive technology” /> Example alt text
- 23. More guidelines Imagesthat 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 Labelattribute matches input id — not name Can insert “off-page” label if it would hinder sighted users
- 27. Keyboard accessibility Makesure 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.
- 29. 4. Tables Providea 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 Thesummary 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 andscope 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 Usingjavascript 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 youuse 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 theonMouseDown, 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 withonSelect 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 isinaccessible 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 ARIASpec 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’sWAI-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 Anoften 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 colorcontrast? 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 coloralone to convey meaning
- 47. Test in grayscale …
- 48. 7. Captioning Goodfor 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 MSWord 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 WebAIMAcrobat 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.
- 54.
- 55.
- 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 Keyboardaccessibility 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 withthe keyboard
- 64.
- 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.
- 67.
- 68.
- 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
Editor's Notes
- #4 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.
- #5 This is a departure from WCAG 1.0, which references specific technologies, such as javascript
- #6 Captions, screen reader, Braille display
- #8 Chunking appropriately, avoiding jargon or institutional language, avoid URL descriptors, acronyms Different learning modalities, visual versus verbal Don’t change nav and layout structure Careful with AJAX-y elements, pop-ups Considerate form validation and error correction
- #12 Headings, links, and landmarks are like hand-holds on a climbing wall. Without them, assistive tech user must parse linearly through a web page.
- #14 What are those hand holds?
- #17 Don’t select heading levels for their default size—use CSS to style your headings.
- #21 Announced with a screen reader. Semicolon key cycles through regions. Note that these perform same function as off-page headings.
- #24 Think about how alt text relates to the inline text as well.
- #26 Labels are also a form of alternative text.