37 million reasons to give a damn about the disabled
â˘
4 gostaramâ˘21,017 visualizaçþes
Chris Merkel talks us through the hows and whys of accessibility design for websites. During his presentation you'll learn what types of devices the disabled use to access the web, and see videos of real people using them. You'll learn practical tips for how to make our websites and apps more accessible and learn how to try out a screen reader for yourself.
Recomendados
Recomendados
Mais conteĂşdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (18)
Semelhante a 37 million reasons to give a damn about the disabled
Semelhante a 37 million reasons to give a damn about the disabled (20)
Ăltimo
Ăltimo (20)
37 million reasons to give a damn about the disabled
- 1. 37 Million Reasons to give a damn about the disabled Chris Merkel User Experience Designer/Architect Computech Inc.
- 2. Who is this "Chris" guy?
- 3. About Chris ⢠Computech's User Experience Designer and Information Architect ⢠On contract with the FCC for a new licensing system ⢠Classically-trained designer ⢠BFA 1996 from MICA ⢠Fled to the web in 1997
- 4. About Chris ⢠design for editorial and corporate clients in NC ⢠moved to Silicon Valley ⢠from 1998, clients were Ask Jeeves, Intel, Yahoo! Xerox, and Microsoft ⢠back to the East in 2009 ⢠8 years of in-depth accessibility experience
- 5. Why bother? A common question from my past
- 6. Why bother with accessibility? Cost Lawsuits Hotline call volume Government contracts Audience appeal SEO Source: zgeek.com at http://www.zgeek.com/forum/gallery/files/1/0/8/simpsons_angry_mob.png
- 7. How the Disabled Use the Web, 1 Introduction to the Screen Reader with Neal Ewers of the Trace Research Center A short 6 minute video demonstrating how screen readers assist people who are blind navigate the web, access the electronic page, and more. More videos by UW-Madison at http://www.doit.wisc.edu/accessibility/video/
- 8. How the Disabled Use the Web, 2 Head Designed with Giesbert Nijhuis, graphic designer A short 3 minute video demonstrating how mobility devices assist people with issues navigating and using applications we User Experience professionals take for granted. More videos by AssistiveWare at http://www.assistiveware.com/videos.php
- 9. Have some Empathy Try using a screen reader yourself⌠Is your site accessible?
- 10. Available Screen Reader Software Windows ⢠Jaws from Freedom Scientific: the free demo allows for 40 minutes at a time before rebooting ⢠WindowEyes, GW Micro: a fully functional demo is available for Windows but times out after 30 minutes. ⢠NVDA, NV Access: available in full for free ⢠Thunder: available for Vista or XP ⢠Narrator: built into Windows Vista and Windows 7
- 11. Available Screen Reader Software Apple OSX ⢠VoiceOver: Mac OSX includes VoiceOver, Appleâs powerful and very successful screen-access technology â VoiceOver also included on the iPhone and the iPad ⢠Run Windows screen readers using Parallels, VMWare, Virtual PC , or Boot Camp
- 12. Available Screen Reader Software Linux ⢠Orca: available on Linux, free and open source Browser-Based ⢠Firevox: available in full for free on Windows and Mac but only works with Firefox ⢠Fangs: this screen reader emulator is a Mozilla Firefox extension that displays a text representation of a web page similar to how a screen reader would read it
- 13. Disabilities and Devices How different folks use different strokes
- 14. Percentage of Disabilities in the U.S. Within ages 21-64, across any gender, race, and education: ⢠5.4% Mobility ⢠4.1% Cognitive ⢠2.3% Auditory ⢠1.9% Visual 299,852,800 Base U.S. population 2,949,415 Sample size Source: 2008 Cornell University Disability Statistics, incl U.S. Census, American Community Survey, and other major studies
- 15. Mobility Disabilities Conditions ⢠Limited movement and fine motor controls ⢠Complete or partial paralysis Photo: by ngvn_tech at http://www.flickr.com/photos/21984458@N07/2281511627/
- 16. Mobility Access Solutions Common solutions ⢠Keyboard controls ⢠Predictive type input ⢠Easy to select & manipulate switches, buttons, and other controls Devices used ⢠Headmouse ⢠Wand ⢠On-screen keyboard ⢠Microphone and dictation software Photo: by Diane Bedard at http://www.flickr.com/photos/windsordi/4650884575/
- 17. Cognitive Disabilities Conditions ⢠Dyslexia ⢠Memory deficit ⢠Educational or cultural disability ⢠Computer settings Photo: by M.V. Jantzen at http://www.flickr.com/photos/mvjantzen/2428033128/
- 18. Cognitive Disability Solutions Common solutions ⢠Consistent design/layout ⢠Simplified language ⢠Predictable behavior ⢠Redundant input such as providing both an audio file and a transcript of a video ⢠Selectable languages ⢠Sitemaps ⢠Donât disable browser history Devices used ⢠Browser history ⢠OS clipboard OSX Finder iTunes
- 19. Auditory Disabilities Conditions ⢠Full or complete inability to perceive frequencies of sound ⢠Computer or device settings Photo: by laurenlemon at http://www.flickr.com/photos/renolauren/3290699773/
- 20. Auditory Disability Solutions Common solutions ⢠Captioned video and audio transcripts ⢠Text instructions ⢠Blinking or (gently) flashing error messages Devices used ⢠Audio captioning Photo: fccdotgovvideoâs channel at http://www.youtube.com/user/fccdotgovvideo
- 21. Visual Disabilities Conditions ⢠Low vision, corrective eyeware e.g. ⢠Color blindness ⢠Complete lack of sight Image: Ishihara color test from http://commons.wikimedia.org/wiki/File:Ishihara_9.png
- 22. Visual Disabilities Common solutions ⢠Use of symbols and shapes ⢠Readable text size, or control of text size Devices used ⢠Screen readers ⢠Braille printers ⢠Screen magnifiers ⢠Dictation software Photo 1: Covert Affairs, USA Network Photo 2: by Dan Hett at http://www.flickr.com/photos/turkboy/2341555716/
- 23. Disability Laws & Guidelines Introducing 508, WCAG, ARIA, and other horrible, horrible animals
- 24. 508 Compliance What is it? ⢠1997 update to an Amendment of the Rehabilitation Act of 1973 Impact on websites? ⢠16 provisions of Sub-part B, 1194.22* Who needs to meet it? ⢠All federal agencies (with some exceptions) ⢠State and local agencies Who enforces it? ⢠The United States Access Board More info at Section508.gov A complete, handy checklist is available at: webaim.org/standards/508/checklist Official federal standards are listed at: section508.gov/index.cfm?fuseAction=stdsdoc
- 25. Web Content Accessibility Guidelines What is it? ⢠Recommendations published by W3C's Web Accessibility Initiative (WAI) Impact on websites? ⢠3 levels of conformance: A, AA, AAA ⢠WCAG 1.0 created 1999 ⢠WCAG 2.0 updated in 2008 Who needs to meet it? ⢠Not required by law (yet) ⢠DOJ may soon enforce both public and private Who enforces it? ⢠3rd parties such as NFB ⢠Private companies ⢠DOJ may soon use WCAG + 508 * More info at w3.org/TR/WCAG20/ (2008) and w3.org/TR/WCAG10/ (1999)
- 26. Major Accessibility Fail Or: This Could Be You
- 27. One great example: NFB v. Target National Federation of the Blind (NFB) v. Target Corporation Background: In a California state case, NFB sues Target for its commercial website's violation of 2 state and 1 federal civil rights acts. Result: Judge rules in favor of NFB, awarding $3,738,864.96 to the plaintiffs. That's 3.7 million reasons to give a damn. More legal goodness on http://dralegal.org/ - Disabilities Rights Advocates
- 28. Another concern: the DOJ July 26, 2010 20th anniversary of the Americans with Disabilities Act (ADA) The U.S. Department of Justice (DOJ) announces possible expansion of the ADA to cover some web sites: ⢠Government sites ⢠Corporate sites that provide âgoods, services, and programs to the publicâ, e.g. shopping and other publicly accessible e- commerce sites
- 29. USA Video Captioning Laws Most recent bill - should be the one signed into law: ⢠http://thomas.loc.gov/cgi-bin/query/z?c111:S.3304 Adobe's blog - on captioning implications: ⢠http://blogs.adobe.com/accessibility/2010/10/president- obama-signs-accessibility-act.html Free subtitling tool: ⢠http://universalsubtitles.org/
- 30. USA U.S. Plain-Language Law The Plain Writing Act of 2010 ⢠Signed into U.S. federal law October 13, 2010 ⢠Requires federal agencies to create documents using plain language
- 31. Your Best Friends are Blind Google, Bing, Yahoo, and their cousins can't see Design for the sightless for best results in search engine optimization Photo: by Caleb Sconosciuto from http://www.flickr.com/photos/seraphimc/513230222/
- 32. What's a guy to do? Practical tips and checklists
- 33. Build Accessibility at the Start Make accessibility a central concept from inception Plugging access features in during development is much harder and expensive in the long term Image: by Bryce Glass for Flickr at http://www.flickr.com/photos/bryce/58299511/
- 34. POUR it on Plan to make the content, features and controls of your site or application... 1. Perceivable all senses, all states 2. Operable inputs, timing, recovery 3. Understandable meaning, association 4. Robust all devices, future-proof Photo: by Sam Agnew at http://www.flickr.com/photos/samagnew/3708407892//
- 35. For Websites 1. HTML 2. CSS 3. Javascript 4. WAI-ARIA (think of it like making a pizza w/toppings) start with basic HTML for content and structure add visuals as extra presentation scripts add interactivity, esp. for rich apps ARIA gives screen elements more meaning
- 36. HTML tips Content should make sense when linearized Use tags which help reinforce the meaning of elements Help users understand the structure of a screen Provide text and non-text alternatives for multimedia Image: Wufoo user registration at https://secure.wufoo.com/signup/1/
- 37. CSS tips display:none :hover, :focus position:absolute form labels Color, contrast, size padding, margin, positioning hides content from screen readers, too making these states look the same helps content only for screen readers can help strengthen association of label:input:instructions in forms help keep the level of visual contrast high watch visual association b/w objects, but help make click targets bigger
- 38. JavaScript tips Use a library YUI, EXT, jQuery, etc. Do not use onchange for navigation Do not enforce timing Use caution in movement, updating Manage focus carefully For maintenance, robustness, extensive testing Causes confusion in screen readers, esp. in menus Impossible to tell how long users will stay on a part of a page Difficult for cognitive disorders, flashing 4 to 59/second = seizures Start reading at the right place
- 39. JavaScript examples from YUI Modal dialog Each shows management of focus, properties Tabbed section
- 40. WAI-ARIA to the Rescue Web Accessibility Initiative for Accessible Rich Internet Applications Problem: Desktop is not dependent on server requests, has a far richer set of UI components Solution: ARIA allows developers to create rich web applications Great intro on the Opera website: dev.opera.com/articles/view/introduction-to-wai-aria/
- 41. What Am I? ARIA Roles Landmark roles (beyond tabindex) Widget roles (extend ancient HTML tags) Labelling & association (make instructions be read with field labels) Managing dynamic change (live regions and content/presentation updates) Role = âbannerâ Role = ânavigationâ Role = âmainâ or âapplicationâ Role= âcomplementaryâ Role = âcontentinfoâ Browser window
- 42. What Happened to Me? ARIA States Values (min, max, current) Required or Optional (better than the * character) Labelled and Described (associate inputs/controls with instructions, info, errors) Text Equivalents (for visual widgets like sliders) aria-required=âtrueâ aria-labelledby=âpword" aria-describedby=âchars" aria-role=âbuttonâ
- 43. HTML 5 New features in HTML: ⢠The canvas element ⢠New video and audio elements for media ⢠Better support for local offline storage ⢠New content specific elements ⢠New form controls Photo: Amazon.com <article> <audio> <canvas> <footer> <header> <nav>
- 44. HTML 5: Problems & Opportunities Pros: ⢠Good support in new, popular mobile devices ⢠Degrades well in older browsers ⢠Tag itself describes its purpose w/o extra markup ⢠Helps move the web and devices forward Cons: ⢠Spotty support in browsers ⢠Potential conflicts with ARIA roles ⢠Disagreements about video support ⢠Accessibility issues with canvas drawings
- 45. Test for the Disabled Yourselves Test with many different screen readers Turn off your monitor Switch your mouse hand Ditch the mouse, use keyboard only Bring in real users Great article on setting up a screen reader test lab: iheni.com/screen-reader-testing/ Photo: by wbsercessa at http://www.flickr.com/photos/stasigh/2017218782/
- 46. Development Tools Available WAVE toolbar (Firefox) From webaim.org Web Developer Toolbar (Firefox and Chrome) From chrispederick.com AIS Accessibility Toolbar (Internet Explorer) From visionaustralia.org.au Photo: by Chris Merkel at http://merkelwerks.shutterfly.com/2008/601#602
- 47. Development Tools Available FireEyes (Firefox) From deque.com Accessibility Evaluation Toolbar (Firefox) From addons.mozilla.org Fangs Screen Reader Emulator (Firefox) From addons.mozilla.org Many more listed on W3C: w3.org/WAI/eval/selectingtools.html Photo: by Chris Merkel at http://merkelwerks.shutterfly.com/2008/601#602
- 48. Checklists from Respected Sources Many disability advocacy groups and large corporations provide great lists to follow. National Federation of the Blind: Criteria for Nonvisual Accessibility Certification Google Sites: Section 508 Compliance report IBM Human Ability and Access: Web accessibility checklist Federal Web Managers Council and the GSA: WebContent.gov
- 49. Further Research & Assistance Government agencies ⢠Federal Web Managers Council & GSA: WebContent.gov ⢠US Access Board: access-board.gov Corporate and non-profit agencies ⢠NFB: nfb.org ⢠Even Grounds: evengrounds.com Local accessibility groups and events ⢠Accessibility DC: accessibilitydc.org ⢠Meets locally at MLK Library, 901 G St NW in DC
- 50. Join the Conversation Twitter @a11y - UK @webaxe - Cupertino, CA USA @w3c_wai @AccessibilityDC #axs #a11y Photo: by Michelle Wegner at http://www.flickr.com/photos/michellewegner/2874818735/
- 51. Fire away with any questions Image: Shirtoid.com at http://shirtoid.com/4809/the-spanish-inquisition/
- 52. Thanks for watching Chris Merkel is on: Email christophermerkel@yahoo.com Twitter @merkelwerks
Notas do Editor
- Hello, and welcome. Iâm Chris, one of Computechâs user experience designers and information architects. Computech works mainly with federal organizations, and our products must meet Section 508 for procurement standards. One of my main interests is in the field of accessibility, the highlight of tonightâs presentation. Iâll show some common problems disabled users face, give a demonstration of some assistive technologies, and a way of approaching accessibility on the web and software.
- Since Iâm new to the DC chapter of IxDA, youâre probably wondering, who I am, whatâs my background, and what I bring to the Interaction Design Association.
- Iâm currently working on Computechâs contract with the Federal Communications Commission, specifically in interaction and visual design for their licensing and auctions applications. Computech has provided the FCC with several licensing applications, and the upcoming Consolidated Licensing System will combine various bureausâ own filing systems into one centralized, standard application and review process. I started with Computech last year, just before the wonderful Snowpocalypse. Iâm originally from the East Coast, and I trained as a traditional graphic designer and illustrator at the Maryland Institute, College of Art in Baltimore. Print media are still a big part of my experience and background, and I still like to keep a hand in, but I liked the fast pace of web publishing and computer design.
- I moved to the web soon after graduating, and worked for a regional newspaper in North Carolina, with editorial and commercial design projects. I saw that more action was happening out west, and took the chance to become a part of that Silicon Valley scene in 1998. Iâve worked with some great companies on both application design and marketing, but it was time to find some stability, and California and especially the San Francisco Bay are not known for having very solid ground. Washington DC is one of the most recession-proof areas in the country, whether or not you like the winters, mosquitos, and traffic. Accessibility has been an interest of mine since working with disabled Gulf War veterans at the News & Record. At Ask Jeeves, it was accessibility for all ages, such as design for young children on its AJ Kids site. At Intel, Yahoo and Xerox it was simply a corporate requirement, though at Xerox I again got the opportunity to work directly with the disabled through usability studies, and volunteering at the Palo Alto Veteranâs Hospital across the street. It was at Xerox and Yahoo where I learned the most about the problems of accessibility through direct observation, and gained the most empathy for the users of the devices Iâll show you in a couple of minutes.
- Corporate governance was a concern at my past employers. Unfortunately, so was the bottom line. Meeting financial or date-driven deadlines was in our job descriptions, and cutting corners meant bonus points towards promotions or clientsâ contract extensions. However, those short-term solutions were proven failures in the long term.
- Accessibility is like Security: Just like security, few wanted to allocate resources to support accessibility, especially in those days of the Dot-com boom. But it needed to be done from a usability, legal and moral perspective. Products will only become more accessible when vendors like us hold ourselves accountable to accessibility standards at the highest levels we can maintain. The benefits to us are tangible. Lawsuits, dropped contracts will become more rare, and weâll see our overall costs in development, testing, marketing, and customer support shrink down, when we build in accessibility from the start.
- Familiarity with the device that a person uses to interact with the web is a major key to accessibility review. One of the easiest ways to test that ease of use is with a screen reader. Many disabled people use this type of software not only if they have vision issues, but also if content being read to them out loud helps their comprehension. They may have dyslexia, or attention deficit disorder, and this spoken speech helps them make more sense of the interfaces you and I are designing. Itâs a very different way of using the web, and to give some background before our demonstration, Iâd like to take a few minutes to show you how a typical sightless person goes about surfing the web. This is Neal Ewers from the Trace Research Center, a part of the College of Engineering at the University of Wisconsin in Madison. Trace publishes one of the best series of videos on accessibility Iâve seen, especially videos of actual device use, and I encourage you to view their resources and share them with your own organizations. * http://www.doit.wisc.edu/accessibility/video/intro.asp
- Giesbert Nijhuis is paralyzed from the neck down due to a spinal cord injury caused by a car accident. He designs t-shirts, CD covers, film posters and much more using a head pointer, also called a Head Mouse, an on-screen keyboard, and his Mac. * http://www.youtube.com/watch?v=x31u1seLTo0
- Try a screen reader for yourself. Use NVDA, a free screen reader, or a trial version of Jaws or Window-Eyes. Try doing something simple on your own companyâs website, such as filling out a contact form. To give yourself the fullest experience of being a sightless user, start up the screen reader, and cover up the computer screen and unplug the mouse. Youâre now effectively blind. Disabled people who are new to computers, or the newly disabled, may spend many weeks getting used to their setup, so I donât expect you to fly through cyberspace like someone whoâs been doing this for years. To help you out, this PDF has all of the common browser and screen reader shortcuts youâll need to navigate a website and to fill out any forms within it. Again, try doing something very simple such as filling out your own companyâs contact form on its website and submitting it.
- Most screen readers are available for Windows only, and there are a wide variety of choices. The more expensive choices are going to be the most sophisticated in their pronunciation, as well as the quality of their voices, which are the most costly portions of the software to create. JAWS is by far the most widely used, and it and WindowEyes have the most understandable voices and pronunciation. They are both fairly expensive, and re-using the demo versions of both programs might violate their end-user license agreements. http://www.freedomscientific.com/downloads/JAWS/JAWS-downloads.asp http://www.gwmicro.com/Window-Eyes/Demo/ NVDA, by Non-Visual Access, is an open-source program, developed and provided for free. Its speech synthesizer (voice) is not up to the level of JAWS, but NVDA does have the ability to use other synthesizers installed on the computer, such as Windows Narrator. http://www.nvda-project.org/ Thunder is another free program, developed by a non-profit company out of the UK. Its default voice is not the highest quality, but the company does make available better voices for about ÂŁ40. http://www.screenreader.net/ Windows Vista and Windows 7 come with a fairly good built-in software called Narrator. Its voice is very good quality, though it has some pronunciation issues, especially with technical terms such as âpluginâ and abbreviations. http://www.microsoft.com/enable/products/windows7/
- Mac OSX users may have fewer native software, but VoiceOver is a strong contender for a quality non-visual access tool, with a high-quality voice, very strong support for braille displays, and even more features such as trackpad gestures and thorough customization. And although screen readers tend to be built for Windows, thereâs plenty of virtualization software out there to help you run these programs, including Parallels, VMWare, and Virtual PC , or run them in native Windows using Boot Camp. http://www.apple.com/accessibility/voiceover/ http://www.parallels.com/ http://www.vmware.com/ http://www.microsoft.com/Windows/products/winfamily/virtualpc/default.mspx http://www.apple.com/macosx/compatibility/
- There are few options for Linux, though on this operating system and others, some browser-based screen readers will also provide a strong non-visual access experience. http://live.gnome.org/Orca http://firevox.clcworld.net/ http://www.standards-schmandards.com/projects/fangs/
- That was tough, wasnât it? Itâs hard to imagine surfing the web, reading email, and having online conversations without being able to see everything in front of you. But being visually impaired doesnât mean not being able to do all of these things. These screen readers convert what is on the screen into synthetic speech, and the user âhearsâ whatâs been put in front of them. Among other tools -- such as Braille keyboards, closed captioning, and voice activated data entry software -- people with issues in vision, comprehension, mobility and sound can use assistive technologies such as this screen reader to read and participate on the web.
- About 12% of the United States population had listed some type of disability as of 2 years ago. Thatâs 36 million out of all non-institutionalized men and women of all ages, races, and education levels in the United States who reported a disability. http://www.ilr.cornell.edu/edi/disabilitystatistics
- Mobility disabilities can be complete, in the form of disease, such as cerebral palsy, or military action such as Sergeant Sam here, recovering at the Palo Alto Veteranâs Hospital. It could be more moderate, such as repetitive stress disorder from using firearms or tiny keyboards for a prolonged period of their life. Or it could be temporary, such as you or I being careless with a pair of scissors. Ever try using a mouse with your non-dominant hand? Or pull an all-nighter or two in a row, that wonderful achy feeling you have afterwords?
- There is a range of mobility, from stress disorders to the completely paralyzed. Keyboard access, time-savers such as auto-complete in search and word-processing, and larger click targets all make a big difference when they are implemented well. We can let users take a choice of input devices, and bring things to them in easy reach. The types of mobility solutions we should be thinking about will also cross over into solutions for perception and visual disorders.
- Problems in immediately perceiving and understanding content, context and meaning can stem from real medical disorders, such as dyslexia. Memory issues due to Alzheimerâs, or pulling all-nighters for a client, definitely affects perception through time. Unfamiliarity with technical or cultural terms also doesnât help. Even switching computer systems or versions of a program can give you what is essentially a short-term learning disorder. You canât file for it on your taxes, but there it is.
- Help for associative and memory disorders comes from consistency, predictability, and repetition or redundancy. It can be as simple as taking out the technical jargon from a system which will have new users, or just keeping the layout of the screens youâre designing consistent in their placement of elements and use of symbols and terminology. Having the browser history actions available to use is a big win for anyone suffering from memory disorders, or just plain forgetfulness. Some of these solutions carry over to auditory and visual disabilities, like audio transcripts, and use of shape and color to underscore meaning and purpose.
- Iâve only had a handful of participants in usability studies who had hearing problems. Much of what we create for software is text- and image-based compared to TV, radio, and similar media. But, my study participants have made me aware of how limited they felt in the growing popularity of video on the web, and in certain applications where sound is a major component of announcement. Some of the people Iâve met have been born with a deficiency; and others have been from the military, where machine-guns, artillery, and grenades are not kind to eardrums. And it could be any regular person off the street. How many times have you Muted your computerâs audio and then missed noticing an incoming email?
- Again, redundant feedback of audio and visuals, such as the New Message sound from your e-mail program combined with a visual notification of a mail icon appearing in your taskbar. Google has broken new ground in their captioning of video uploaded to YouTube. This helps even wider audiences revel in the antics of your pets and childrenâs behavior and language. It also helps in real practical ways, such as the captioning of my clientâs broadcasts from the Commission, on important topics such as the National Broadband Plan.
- Yes, not all of us have the eyes of a fighter pilot. But, we are all so accustomed to seeing people wear glasses or contact lenses that we do not think of poor vision as a disability, but it is. And thatâs why we canât rely on tiny text in websites to solve our clientsâ needs for stuffing as much information as possible into an interface. Besides crossing over into that cognitive disorder area, it is simply too hard for most people to read without assistance. And sometimes we forget and leave those assistances on our bedside tables and not in our briefcases. However, even with good-size text comes other problems. Did you know that 1 in 12 of we men have some form of color blindness? Go ahead and say it, ladies, weâre flawed. Though, some scientists have written that these different visual perceptions helped us find animals in hiding when we hunted in nature rather than Safeway. But it has its problems in more than just choosing the wrong clothes. Think of traffic signals at intersections. Warning labels on medications. Error messages in your web applications. As part visual designer, we user experience pros are concerned with color, shape and size. Some disorders such as cataracts cover up or distort parts of our vision. And for those who canât see, theyâve even more but related problems, as weâve demonstrated.
- Access to screen readers, magnification software, and braille printers solve these non-visual access to a point. Screen readers weâve demonstrated. This image comes from the USA Network tv show called âCovert Affairsâ. This main character is written as a completely blind person, and I think the show does a fair job in showing off devices like this braille printer. The "screen" is the line of braille at the bottom, which is mechanically manipulated by the CPU to match the text it needs to display. It changes instantly as you move from line to line, moving small pins up or down through a grid of holes in its surface. Control over text size is also a concern. Many of our popular browsers now magnify the entire display, negating the need for much use of a magnifier, and operating systems can control font size as well. We need to test for those user-initiated changes and plan for them. Because of physical limitations, some people donât have the ability to navigate around using a traditional mouse or trackpad. They have to rely entirely on their keyboard to navigate a site or program, and if youâve ever tried to do this, you know how difficult it can be! Unfortunately, many pages and functions were never made accessible to these users, and people can become âtrappedâ inside of menus, frames, and other coded land mines. We need to understand how those tools bring information to a user. Their results can be pretty surprising, and some of this software and hardware can be pretty expensive, often the same or greater cost as the computer itself. Because of that, users donât update as frequently as we add richness to our sites and applications, and when that gap widens, things become inaccessible to that cash-strapped end user. For sighted users, we canât rely on changing text color alone; it is a small percentage, but some of us guys and a small portion of women will see different colors that as the same. Adding a shape, such as an icon, to that error message will underscore the meaning you need to get across to them, and helps understanding and memory with that association. And thereâs nothing like movement for grabbing the attention of users. For complex forms, where follow-on questions change, appear or disappear, a slight bit of animation added will go a long way to helping users notice that something has changed visually and cognitively.
- All of these disabilities and equal rights to access are meant to be covered by various laws. Building applications and sites for the government, we have to fulfill these requirements as a matter of course, and I think we all have some kind of training processes built into our new hire orientation, and questions and tests for our recruitment. Some of you might have heard about Section 508, WCAG, and techniques such as ARIA. For those who arenât, I hope this will be a good overview.
- Many of you working with government organizations are already familiar with Section 508. Section 508 is a fairly recent update to the Rehabilitation Act of 1973. It actually covers all forms of computer procurement, down to the desks we sit at. For those of us working on websites for government organizations, we should be focused on 16 provisions of a specific sub-part of that amendment. Each government organization chooses the provisions they are going to support. State and local government organizations are also impacted by the Section 508, especially when entities receive Federal funding. Private companies may enforce Section 508 as a voluntary standard for all releases, such as Iâve done at Xerox and Intel, and colleagues of mine at Kaiser Permanente. At each of these organizations, this often extends to include their internal applications and content. However, private web sites are not required to comply unless they are receiving federal funds or under contract with a federal agency. There are some exceptions, such as programs at the NSA and the military where the use of an application would be prohibitive to the disabled, such as air-ground traffic controls. http://www.section508.gov http://webaim.org/standards/508/checklist http://www.section508.gov/index.cfm?fuseAction=stdsdoc
- The World-Wide Web Consortium have put out two versions of these guidelines from their Web Accessibility Initiative. Their first Web Content Accessibility Guidelines, or WCAG, appeared in 1999, and while thorough it was criticized for being too technical, inaccurate at times, and contradictory between related areas. The second version of WCAG was just updated a couple of years ago. It has obsolete policies removed, such as guidelines for using tables in layout, and the specs have an accompanying document with some good techniques and examples. While it is more consistent, it is still a very heavy technical text and isnât without its problems. In many locations it becomes vague, and leaves itself open to some pretty wild interpretation, with vendors claiming the highest AAA rating with questionable practices. WCAG is just a guideline, not federally enforced. Yet. But some disability rights groups are using WCAG as a standard, and are claiming in courts of law that commercial sites should be held as accountable as brick and mortar stores. http://www.w3.org/TR/WCAG20/ http://www.w3.org/TR/WCAG10/
- Some of these legal actions have already come to pass, with more to come. Our attention to detail in accessibility will soon be as important as any other aspect of our sites and applications.
- In 2005, the National Federation of the Blind, or NFB, came to Target with claims that its site was difficult or impossible for sightless users to access and comprehend. The two of them negotiated for months, at which point NFB sued Target, who tried to get the case dismissed, claiming that civil rights acts apply to their physical stores, which are accessible. However, the judge didnât agree, stating that online stores need to provide access to the disabled, too, and certified the case as a class action lawsuit for claimants across the United States. After this settlement, the NFB monitored Target starting in 2008, and examined any further complaints regarding the websiteâs accessibility, though they did provide training to the websiteâs developers. Early this year, NFB awarded Target their Non-Visual Access certification for Target.com. In terms of US law, this was a lawsuit that needed to happen. The case law on Web accessibility is so far pretty thin. But with cases such as this, weâre getting more pressure on software and websites, even if our clients are online-only, and itâs too expensive not to notice. Targetâs multi-million dollar settlement is pretty small for a corporation that had $63 billion in revenue and $3 billion in net income in 2007. Still, the settlement amount is significantly more than what it would have cost Target to implement a high level of accessibility in the first place. Besides the money angle, I want to point out the fact that NFB are awarding certifications. Those may become valuable for us to earn and display on company About pages. And I think it makes a lot of sense to involve groups like this at an early stage. http://dralegal.org/
- After this summerâs anniversary of the Americans with Disabilities Act, the Department of Justice announced that they are planning to become more active. We already have the Access Board looking over federal organizationsâ online properties, but we may soon have DOJ officials checking into private companiesâ websites, too. We need to keep an eye on this.
- Over the next few years videos and movies in the USA will have to be captioned for the deaf and descriptions of non-audio scenes or information will have to be described for the blind. Specific requirements, and exceptions, should be available by Q3 2011 after an advisory committee decides what's required and realistic for non-consumer created videos/movies dispersed across the Internet. Adobe Software is watching these developments for how they relate to their video development products. The most recent version of the bill is available for viewing online, and there is a free subtitling tool available for use. http://thomas.loc.gov/cgi-bin/query/z?c111:S.3304 http://blogs.adobe.com/accessibility/2010/10/president-obama-signs-accessibility-act.html http://universalsubtitles.org/
- The Plain Writing Act requires a section on each federal-agency Web site that follows best practices of plain-language writing. This law, passed in Q4 2010, will help people with cognitive disabilities to find and understand information much easier, giving a wider audience to more users who are interested in contacting their government representatives, and for determining how their government could help them. http://www.plainlanguage.gov/
- While itâs not anything legal in nature, good accessibility helps us in other ways. Your favorite search engines canât see a thing. They go through information space in similar ways to the blind. If we make our sites accessible from the start, weâll see more traffic from search engines. Iâve seen this personally after two major redesigns of Xerox.com, with double-digit increases in traffic from search engines to our product pages.
- Designing accessibility into a site or application is much more cost effective than trying to âfixâ already-deployed resources, so accessibility must be a part of our processes across the life cycle of a product.
- Creation and governance of standards must be defined and publicized at all levels of an organization, not just siloâd in design, development or testing areas as a âbolted-onâ process. Training should happen often, and we should share knowledge more often within our organizations when we learn something new. Get involved with your testers, your developers, your analysts. If you can get the approval, reach out to advocacy organizations like the National Federation of the Blind and learn from them, too. Make an organizational change. Select technologies that support accessibility for projects before putting them in place. I regularly choose the Yahoo User Interface library because of Yahooâs commitment to usability for the disabled, above simple accessibility. Another good step is including team members, clients, and end users with disabilities in planning and testing deliverables. If you can get their input during requirements gathering, they may help notice gaps in our thinking from their perspective. During testing, they can help point out things weâve missed.
- There are a lot of guidelines we need to follow, and a great deal of disabilities involved, but they break down into four areas. A term thatâs growing in the access community is âPourâ. Do people know that an area of content, or a control, is there? Can they use it? Do they understand its purpose and how it relates to the things around it? Will our designs work across input and output devices, such as screen readers or a little Blackberry phone? We need to be familiar with as many of our usersâ devices as we practically can in order to get that first-hand understanding, and not just reading articles about them, trying to understand them through inference.
- For web-based apps and content sites, start with a basic foundation of semantic HTML. Use tags with real meaning to them, not a collection of Divider tags with styles applied to them. Use your lists, paragraphs, and especially headings. Remember how Mr. Ewers browses using that list of headings. On top of that, add your styles, scripts, and other markup like ARIA, which Iâll get into next.
- Content should make sense when separated from its presentational, style layer. Tags which actually mean something will help non-visual users understand their purpose and the relationship between elements to get a clear picture of your page or application screen. The order in which you place elements should also make sense. Take this sign-up form for Wufoo. Notice how the instructions are placed after each field. Any non-visual user will hear that text after theyâve already filled something out! A better way to do this would have been to place the instructions within each formâs label, and visually move just the instructions where needed using CSS. This is good practice for re-use of the same code in other devices, such as going from desktop browsers to mobile Safari.
- On top of that structure and content is the presentation layer. Some of this crosses over into interactivity, and I want to point out some problems that non-visual and visually disabled users find irritating. One of those is not being able to see their current focus. This could be the highlight state of a button, or the dotted line which browsers render when using keyboard controls. Donât disable this. In fact, try to make your focus and hover states look the same. Poor contrast is another issue. A great visual design may not be usable to people with lower vision. Test it out. Your non-visual users may appreciate the use of skip links, and you can move those off-screen for visual viewers who may not use them. You can also use positioning to help surface instructions on forms before the a non-visual user enters a data entry control. But be cautious when hiding things entirely. Display:none and Visibility:hidden attributes hide content from screen-readers, too. You may want to do this for progressive disclosure on forms, so that all of your users are seeing just what they need to and not content which doesnât apply to them. But watch out for going bananas with white-space: this may look pretty for that Communication Arts Interactive Annual, but your real end users with memory or cognitive disorders may have a tough time remembering where they are or associating things together. On the opposite spectrum, donât rely on tiny text to solve data overload.
- Javascript, AJAX and screen readers can work fine together. Screen readers all run from a regular OS, and disabled users are on the same browsers anyone else are, especially since they are free, and theyâre running the same scripts. The only issue is that screen reader users may not know that something has happened. Screen readers load content from the current screen, such as an OS dialog window, or the Web browserâs document object model. That content goes into whatâs called the virtual buffer, which stores content ahead of time to be read to the user once they get there. The virtual buffer is refreshed every few seconds. That means that there is a potential for on-the-fly updates to be misunderstood or missed completely. On our side, in planning for a better user experience, we need to give users control over any time requirements, not disable other products' accessibility features (such as a browserâs Back button or its history), and carefully manage changes in focus and page content.
- Here are a few examples using a common interface library. 1) First, letâs look at one of the favorites on the web these days: a modal dialog, also called a âlight boxâ -- http://developer.yahoo.com/yui/examples/container/container-ariaplugin.html -- Using a browser and screen reader combination which supports ARIA, activate the dialog, and listen... Notice how after the activating click, the reader announces that a dialog has appeared, announcing both the purpose of this new content, and its title. The script also changed focus to this dialog, so without eyeballs we know itâs there. Mere accessibility would simply start reading the dialogâs title, but without your visual senses, you wouldnât know that this was a dialog, a separate but related conversation to the page which launched it, and which needs to be paid attention to in a different way since this could be an error message or a prompt to save information before leaving the parent screen. 2) Here is another example we use quite a bit in webpages: a group of information divided across tabs -- http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin.html -- as you focus on this area, and navigate through it, the screen reader is letting me know that these are tabs, not just paragraphs and list items. And for older screen reader software without the support of this extra layer of announcement, even without scripts running, their focus is still managed through anchor tags, so that after a click, the user is still brought to the correct piece of information.
- This extra layer of accessibility is whatâs called âARIAâ. This, too, comes out of the World Wide Web Consortium, from their Web Accessibility Initiative. As I was showing on the Yahoo examples, moving focus around a screen and managing page refreshes is great accessibility, but itâs often not usable. DIV tags by themselves donât mean anything, and our common web UI components havenât been refreshed since the 90s. To get anything richer like those tabbed sections, carousels, sliders, and much of what we take for granted in our desktop OS, and make it more than accessible, to make a control usable and its purpose understandable, we need to add an extra layer of meaning. This is where ARIA comes in.
- To support the understandable part of POUR, ARIA can help users recognize parts of a screen or control for what they really are, rather than just being a divider, a paragraph, or a list. We can start adding landmarks to areas of a screen, making them into a type of bookmark, and even changing the way screen readers pay attention to them. Add roles to elements, such as having them be announced to users as an alert, a button, or a slider. Associate elements with one another: tell the user what a controlâs label is, give them multiple labels, such as a title and supporting instructions, so that a user hears all the important information before using the control, avoiding mistakes.
- Deeper into controls, we can make things more perceivable, operable and understandable by showing users what the state of something is. If itâs a table column sorted up or down, what a slider controlâs minimum and maximum states are, and most of all, if a form field is required or not, beyond displaying an asterisk character. Letâs look at parts of that Wufoo form again, and think of some improvements. For one thing, we can tell screen readers that this form field is required. We can associate it not only with its label, but also with its instructions! This way, a non-visual user will be informed before they start typing. The designer wanted this Cancel to look smaller in visual priority next to a primary action button. These both may have been created as links, not as an actual <button> or <input> tag. Reinforcing the fact that these are commands, we can give each command a âbuttonâ role. Now the intent and purpose of these controls are much stronger.
- And very recently, HTML 5 has come into play as the new kids on the block. It gives us new ways of drawing, and serving audio and video, without requiring a 3rd party plug-in like Flash. It has better support for dealing with local client-side storage for working with files. And it has new elements and controls, such as specific navigation and dialog tags, so that the tag describes its purpose without needing extra markup.
- HTML 5 is a good choice for the Robust part of POUR. The newer mobile devices which have the most market share all have great browsers in them, and are more likely to see these new tags. In older browsers, the new HTML 5 tags degrade into regular HTML 4 containers. Not needing extra markup will reduce file size, both on the clientâs end for a mobile user, and on our end for serving content up to thousands of users. Itâs also the right step forward to push web-based technology and mobile apps forward. Unfortunately, it might not be ready for prime time. Some browsers are not necessarily ready for the full range of HTML 5 tags, and the spec itself is still in draft form, which might change. You may get some conflicts between ARIA roles and an HTML 5 tag in how theyâre announced to a screen reader, and there are accessibility issues with the canvas drawing element. Iâve heard some disagreements about video support, too, so when using the audio and video elements of HTML 5, plan for some type of fall-back presentation in Flash or other standard plug-in.
- I urge you to at least try some simple techniques, and across different software. Donât use just one screen reader; as one of my pals keeps telling me, they all suck in different ways. You will get confused, or get a false sense of security if you leave your monitor on, so pull out the headphones and turn that screen off when youâre testing for non-visual access. Besides vision disabilities, try switching your dominant hand when you use your mouse, and see how you think about the size of your buttons, checkboxes, and other controls. Do you think theyâre too tough to click on now? Put your mouse off to the side and use your keyboard alone. Can you get to everything? Is it usable? Best of all, bring in real disabled users. Reach out to your local disability rights advocacy groups, show that youâre committed to them. You can invite them to test your next product releases, and if itâs possible in your organization, ask for their input very early on in requirements-gathering.
- There are a great number of good tools available, many of them freeâŚthough Iâd like to ask everyone to donate to their makers so that we can continue to see these tools grow. Most of these plug-ins are available for the Firefox and Chrome browsers, but the folks at Vision Australia have made a great accessibility-checking toolbar for Internet Explorer (IE). And IE itself has a fair set of built-in development tools. http://wave.webaim.org/toolbar http://chrispederick.com/work/web-developer/ http://www.visionaustralia.org.au/ais/toolbar/
- Worldspace FireEyes, an accessibility tool which integrates with the Firebug extension for the Firefox browser, enables users to test static and dynamic web pages for compliance and fix issues collaboratively. Some of its strengths include tracing the steps used to reproduce an issue. The Accessibility Evaluation Toolbar for Firefox is another alternative development tool with good, clear features, intended for displaying information about a screen. An alternative to using a screen reader is to use the Fangs Screen Reader Emulator to render a text version of a web page similar to how a screen reader would read it. Other great tools are out there, and the World Wide Web Consortium have an extensive list on their site. Many websites are available, too many to list here, which will offer to check your site for errors and give you a full report. These are great to have for public sites, but you will need some internal tools such as the previously-listed toolbars to check whatâs in your sandbox. http://www.deque.com/products/worldspace-fireeyes https://addons.mozilla.org/en-US/firefox/addon/5809 https://addons.mozilla.org/en-US/firefox/addon/402 http://www.w3.org/WAI/eval/selectingtools.html
- Many companies make their own standards available to public readers. The exhibit which Target created as part of their settlement is also available for public view. After their turn-around and their award of NFBâs Gold Level certificate, their own guidelines would be a great base for making our own checklists. These are consistent with priority 1 WCAG 1.0 guidelines and Section 508 standards and they include keyboard access and advice on Ajax. IBM has a great web accessibility checklist, Google offers an honest Section 508 compliance report for their sites and apps, and NFB themselves offers a list of the criteria theyâre looking for. Federal websites also offer checklists and guidance, and are not necessarily as tough to follow as you might think. http://www.nfb.org/nfb/certification_criteria.asp?SnID=1058913823 http://www.google.com/sites/accessibility.html http://www-03.ibm.com/able/guidelines/web/accessweb.html http://www.usa.gov/webcontent
- Government, corporate and non-profit agencies are out there, and willing to help. Besides checklists, some of these organizations are willing to help directly. We also have some local accessibility groups and events right here in DC, such as Accessibility DC, who meets each month at the MLK Library on G street. Iâm still very new to the area and still learning whoâs around, so I donât yet have a lot of local resources to share. http://www.usa.gov/webcontent http://www.access-board.gov/ http://www.nfb.org/ http://www.evengrounds.com/ http://www.accessibilitydc.org
- Twitter used to seem like a deluge to me, but Iâve started using it differently. There are some prolific writers out there with great content. Two in particular, one from the UK and one from nearby Appleâs headquarters, give me some of the best news, tips and links Iâve ever had. The W3C puts out some notices for their Web Accessibility Initiative, and our local Accessibility DC group uses their twitter account to post notices for meetings, archived presentations, and links that the organizer feels we need to pay attention to. I encourage you guys to follow those in particular, and to check the searches they often refer to.
- Thank you very much for your time, and Iâd like to keep up the conversation with any questions and comments you may have for me.
- Thanks again for attending tonightâs talk, and feel free to contact me further via e-mail and Twitter. Iâll be happy to talk and collaborate further with you.