Accessibility Demystified: 3 Myths and Why They're So, So, So Very Wrong
•
1 gostou•535 visualizações
Think website accessibility applies to a select few? Or that it means moving away from innovation and creativity on your site? Actually, web accessibility impacts us more than we think - in a positive way. This session goes over how Phase2 implemented some innovative accessibility practices to improve the usability experience for everyone. In this presentation, we'll go over the myths of accessibility, examples of quality accessible practices, and how to integrate accessibility into the site planning and implementation.
Recomendados
Mais conteúdo relacionado
Semelhante a Accessibility Demystified: 3 Myths and Why They're So, So, So Very Wrong
Semelhante a Accessibility Demystified: 3 Myths and Why They're So, So, So Very Wrong (20)
Mais de Phase2
Mais de Phase2 (20)
Último
Último (20)
Accessibility Demystified: 3 Myths and Why They're So, So, So Very Wrong
- 1. ACCESSIBILITY DEMYSTIFIED: 3 MYTHS AND WHY THEY’RE SO, SO, SO VERY WRONG. Catharine McNally Quality and Accessibility Analyst, Phase2 Technology
- 2. 3 MYTHS
- 3. “ What are the chances that a blind person would visit my site? ”
- 5. “ I don’t have the budget, time, or expertise to make a website accessible. ”
- 7. 10% 1 in 10 of all web users do not get the full experience of the site as designed. 90%
- 8. OUR ASSUMPTIONS ABOUT ACCESSIBILITY
- 9. WHO ELSE?
- 10. WHO ELSE? A teenager who broke his wrist biking
- 11. WHO ELSE? A soldier returning A teenager who home from deployment broke his wrist biking with mild hearing loss
- 12. WHO ELSE? A soldier returning A teenager who home from deployment broke his wrist biking with mild hearing loss A recovering brain- trauma patient
- 13. WHO ELSE? A soldier returning A teenager who home from deployment broke his wrist biking with mild hearing loss A recovering brain- A disaster survivor trauma patient in shock
- 14. “ What are the chances that a blind person would visit my site? ”
- 15. “ What are the chances that a blind person would visit my site? ”
- 16. “ What are the chances that a blind person would visit my site? ”
- 17. “ i n 1 0 What are the chances that a blind person 1 would visit my site? ”
- 19. WHAT ACCESSIBLE “READ MORE LINKS” DO FOR USABILITY
- 20. WHAT ACCESSIBLE CONTRAST DOES FOR USABILITY INDOORS OUTDOORS
- 21. WHAT ACCESSIBLE LINK TARGETS DO FOR USABILITY LARGE (& MULTIPLE) LINK TARGETS
- 22. CHOICE OF ENGAGEMENT: EVERYONE HAS THE OPPORTUNITY TO CHOOSE HOW THEY RECEIVE CONTENT.
- 23. CONTEXT QUALITY, JARGON-FREE DESCRIPTIONS APPEAL TO A WIDE-RANGE
- 28. BUDGETING, PLANNING, & IMPLEMENTING ACCESSIBILITY
- 29. LEARNING SECTION 508 STANDARDS, WCAG STANDARDS: Section 508 is a legal requirement for all organizations and their sites that receive federal funding. Web Content Accessibility Guidelines (WCAG) are a series of “best practices” published by the W3C, and Download WCA G Practices: are not part of Section 508 or any federal law. www.w3c.org/ TR/WCAG SECTION 508 S tandards www.section50 8.gov. There are subtle differences between the two, with WCAG having up-to-date applications for the latest technology.
- 30. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours
- 31. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours
- 32. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours POST-DEVELOPMENT PLANNING 20 hours DESIGNING 25 hours DEVELOPING 80 hours TESTING 30 hours REMEDIATION 15 hours TOTAL 180 hours
- 33. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours POST-DEVELOPMENT PLANNING 20 hours DESIGNING 25 hours DEVELOPING 80 hours TESTING 30 hours REMEDIATION 15 hours TOTAL 180 hours 80 hours (45%) over budget.
- 34. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours
- 35. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours REMEDIATION 15 hours TOTAL 100 hours POST-DEVELOPMENT PLANNING 20 hours DESIGNING 25 hours DEVELOPING 80 hours TESTING 30 hours REMEDIATION 15 hours TOTAL 180 hours
- 36. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours PRE-DEVELOPMENT REMEDIATION 15 hours PLANNING 15 hours TOTAL 100 hours DESIGNING 15 hours DEVELOPING 45 hours POST-DEVELOPMENT TESTING 25 hours PLANNING 20 hours REMEDIATION 15 hours DESIGNING 25 hours TOTAL 115 hours DEVELOPING 80 hours TESTING 30 hours REMEDIATION 15 hours TOTAL 180 hours 80 hours (45%) over budget.
- 37. BUDGETING 100 HOUR PROJECT: PLANNING 10 hours DESIGNING 15 hours DEVELOPING 40 hours TESTING 20 hours PRE-DEVELOPMENT REMEDIATION 15 hours PLANNING 15 hours TOTAL 100 hours DESIGNING 15 hours DEVELOPING 45 hours POST-DEVELOPMENT TESTING 25 hours PLANNING 20 hours REMEDIATION 15 hours DESIGNING 25 hours TOTAL 115 hours DEVELOPING 80 hours TESTING 30 hours 15 hours (14%) investment. REMEDIATION 15 hours TOTAL 180 hours 80 hours (45%) over budget.
- 38. USER EXPERIENCE STRATEGY WILL FEATURE BUILDS BE ACCESSIBLE? WHAT ARE THE MOST COMMONLY VIS ITED FEATURES OF Y OUR CLIENT’S SITES ? REVIEW ANALY TICS. MAKE THOSE P AGES ACCESSIBLE FIR ST.
- 39. BUILDING BUILD THE RIGHT WAY, FROM THE START “Skip Links for Accessibility” Module under development o n Drupa l.org: http://drupal.o rg/project/ accessible_skip _links
- 40. TESTING TEST EARLY AND OFTEN FREE SCREENR EADERS: MAC: VOICEOVE R WINDOWS: NVD A FREE AUTOMAT ED TESTING: wave.webaim.o rg Chris Pederick Web Developer Toolbar: (Chrom e, FF) www.chrisped erick.com
- 41. TESTING TEST EARLY AND OFTEN FREE SCREENR EADERS: MAC: VOICEOVE R WINDOWS: NVD A FREE AUTOMAT ED TESTING: wave.webaim.o rg Chris Pederick Web Developer Toolbar: (Chrom e, FF) www.chrisped erick.com
- 42. “ I don’t have the budget, time, or expertise to make a website accessible. ”
- 43. “ ”
- 44. “ ”
- 45. “ I cannot afford to have an inaccessible website. ”
Notas do Editor
- My name is Catharine McNally, and I’m a Quality and Accessibility Analyst from Phase2 Technology. As a person who is deaf, I’m really passionate about quality, equal web experiences for everyone, regardless of ability. I never like to be given a separate experience “just for deaf people.” A lot of what I do every day is looking at our web projects and finding areas for greater, inclusive opportunities to engage everyone in the same experience. \n\nIn the next 45 minutes, I’ll be going over 3 myths about accessibility and why they’re so, so, so very wrong. Additionally I’ll provide you with a holistic overview of what accessibility means, how accessibility benefits everyone--not just those with disabilities--and what you can do to implement this type of thinking and practice into your website.\n
- I’m very open when it comes to talking about my disability. I think it’s really important for everyone to be able to have an honest conversation, especially when it comes to perceptions about website accessibility and user experiences. It is always my hope that people feel like they can ask me anything -- and that goes for you here in the audience. Feel free to raise your hand at any point and ask question, no matter how trivial it may seem. Heck, I’ve evenhad people ask me if deaf people can drive!” \n\nAnyway, I’ve put together the three most common questions that I get about web accessibility, and I thought I’d share them with you. The first one is: \n
- [Read Quote] \n\nI get this so often, especially when a deadline is looming. They state, “Let’s go ahead and launch. “What’s a month’s difference? It’s not like a blind person will visit that page, I mean what are the odds?” \n\n\n
- The next one: \n\nAccessibility is an entirely different, separate experience that is ugly, cumbersome, and just boring. It means creating a text-only version of the site with a bunch of links and no theming. It’s for that maybe one person who ever visits the site, ever, so we’re just going to turn the other way and not do anything until someone complains.\n\nI actually had an experience in which I was having coffee with an executive from a national news broadcast company said to me, “We’re just not going to caption our TV shows online until someone complains.” I’m sitting across from him, and thinking to myself, “You know, you’re saying this to a deaf person right here!?”\n\nThe irony!\n\nSo this is one problem, the concept that accessibility is ugly, cumbersome, and something to not deal with until someone complains. \n
- This is the most common statement I get, [read quote]. I get it. Web accessibility at one point to me was really overwhelming, too. But once I broke it down into manageable pieces, I began to see a holistic view, and recognize how accessibility is more ingrained in our experiences. And it’s more attainable than we think it is. It’s about opening out eyes and recognizing that some of the best experiences out there have accessibility practices implemented into them at the core. \n\nHow many of you use the curb cuts when you’re pushing your cart full of groceries to your car? Those are pretty handy, right? Developed primarily for wheelchairs, and a huge appeal for carts, strollers. \n\nHow about you’re in a noisy bar at a restaurant to watch your favorite sports team? Lucky for you, the closed captions are on and you can follow along. Closed captioning was developed for deaf people and has a wider appeal for everyone. \n\n
- So, let’s talk about WHO needs accessibility: \n\nTake a minute, and think about who you think would need accessibility. \n\n[Discussion: Ask Audience “Who Needs Accessibility?”]\n
- 1 in 10 of ALL web users do not get the full experience of the site as designed. They are in some way left out of the experience. And that’s not something you want your visitors to feel. It impacts loyalty.\n\nYou see, sometimes there may be a bunch of images online without alt-text, and that keeps a person who is blind out of the web experience. \n\nOr there’s a bunch of tiny links all over the site and it takes a steady hand to click on that linked word -- that’s going to be really difficult for a person who has Parkinson's or tremors in their hands. \n\nHow about a site with really poor color contrast? That’s going to be difficult for people who are color blind, or have failing vision, such as our aging baby boomer population.\n\nYou see, it’s not just the “extreme” ends of the disability spectrum that are the only ones impacted. The last thing you want is for people to leave your site feeling defeated. It happens to me every day, I come across a website where I cannot understand a featured video because it’s not captioned. I feel left out and it’s not a fun feeling.\n\n
- Remember, I asked you to think about who comes to mind with accessibility? I bet most of you thought: \n\n- It’s a person who is quadriplegic or in a wheelchair, \n- a person who is deaf and uses American Sign Language, \n- a blind person, or\n- a person with an intellectual disability. \n\nWe all have common assumptions about accessibility. \n\nBut. That’s not the only people who aren’t always able to access a website. So who else? I’m talking about those with what I like to call, “temporary disabilities:” \n
- And by “temporary disabilities” I mean that individuals find themselves suddenly unable to go about their everyday activities. \n\nLike the teenager who broke his wrist biking. Using a mouse is difficult and at times painful for his wrist. But he can use a keyboard to tab through a website -- Will he be able to use the keyboard to conduct his homework assignment which includes online research?\n\n
- Like the teenager who broke his wrist biking. Using a mouse is difficult and at times painful for his wrist. But he can use a keyboard to tab through a website -- Will he be able to use the keyboard to conduct his homework assignment which includes online research?\n\nOr how about the soldier returning home from deployment with mild hearing loss? His ability to understand speech has been impacted due to the war zone? He is not going to be likely to identify himself as having hearing loss, so how will your site reach him in ways that doesn’t separate him from everyone else?\n\n
- Or how about the soldier returning home from deployment with mild hearing loss? His ability to understand speech has been impacted due to the war zone? He is not going to be likely to identify himself as having hearing loss, so how will your site reach him in ways that doesn’t separate him from everyone else?\n\nOr a recovering brain trauma patient. She’s recovering, but her cognitive functions aren’t fully back to what it was prior to the brain trauma. Can she still access her county website to pay her water bill? Will she be able to easily and quickly find the bill payment link? I know i certainly have a hard time accessing Arlington County’s website to pay my water bill, and last time I checked, my brain was operating at full capacity! \n\n
- Or a recovering brain trauma patient. She’s recovering, but her cognitive functions aren’t fully back to what it was prior to the brain trauma. Can she still access her county website to pay her water bill? Will she be able to easily and quickly find the bill payment link? I know i certainly have a hard time accessing Arlington County’s website to pay my water bill, and last time I checked, my brain was operating at full capacity! \n\nWhat about the person who is in shock after a tornado came through his town and tore down his house. Can he easily use his smartphone to navigate to FEMA.gov and quickly understand what he needs to do in a disaster?\n
- \nWould you all agree, that these “temporarily disabling conditions” can surprise us at any time -- and just as equally need to be able to access websites when they need to? \n\n
- So, back to the first myth: “what are the chances that a blind person would visit my site?”\n\nWell, it’s 1 in 10 chances that someone who needs assistance accessing your site. That’s really significant.\n
- So, back to the first myth: “what are the chances that a blind person would visit my site?”\n\nWell, it’s 1 in 10 chances that someone who needs assistance accessing your site. That’s really significant.\n
- So, back to the first myth: “what are the chances that a blind person would visit my site?”\n\nWell, it’s 1 in 10 chances that someone who needs assistance accessing your site. That’s really significant.\n
- At its core, accessibility creates better user experiences that benefits everyone. \n\nIt’s about CHOICE. Giving people more ways to experience content. It’s about providing people with options on how they want to engage with a site, not cornering them into one way of interacting with a site. \n\nIt’s about CONTEXT: Giving more information about what they are reading, watching, or listening. You want to give our users the confidence that they’re going to get the content they are expecting.\n\nIt’s about CLARITY: What is the reader clicking, viewing, or watching? Can they easily understand and follow along? \n\nAll these things help each other out, and we’re going to go over a few examples in the following slides:\n\n\n
- How many of you are familiar with the “Read More” links that are often displayed on home pages of news sites? \n \n “Read More” links are not always clear. Users of Screen Readers may get a list of links that say “read more” “read more” “read more.” At Phase2, we changed it to be “Read [Content Type]” -- like “Read Full Blog Entry” or “Read Full News Release” and what’s hidden to the sighted user, but picked up by a screen reader is the title of the post that is being referenced.\n \n The additional benefit is, users on mobile devices can better understand what the “read more” is referencing, especially when they cannot see the section in view. We’re all zooming around in a mobile version of a website, so we can easily get lost with where we are on the page. Compare the “Popular Topics” on the left, on the full web view. It’s clearly labeled at the top, with the popular topic links beneath. Then it says “View all Popular Topics.” -- Compare it to the mobile web view, where your positioning and location on the mobile view does not clearly indicate you are within the popular topics section. You’d have to scroll up to figure it out. But rather than having our users scroll up to figure it out, our helpful “Read More” link improvement to “View all Popular Topics” provides that orientation and information that is most useful in this case. \n \n So do you all agree that adds helpful context to not just users of screen readers but to all of us? \n\n
- This is one of my favorite examples of how accessibility improves usability. It’s a pretty safe bet to say that most of us in this room have a smartphone, and we’re using it frequently to access information. \n\nContrast plays a pretty big role in this, especially on the mobile front. While Contrast is not a Section508 (legal) requirement, it’s actually included in the WCAG accessibility best practices. \n\nWhen a site has high contrast, it improves readability for people with low vision. It’s also really helpful for all of us, because when we’re using our mobile outdoors, likely under bright sunlight, high contrast is most helpful. If you had a site with white background and gray text, it’d be very difficult if not impossible to read on your mobile device while standing in line in front of your favorite food truck lunch spot. \n\nI’ve simulated an example here -- note how the Thomson Reuters London Olympics SIte has really great contrast -- black background with white text. That is the highest contrast ratio you can get. Then you go outdoors, and the contrast distinction has been reduced, but it is still readable. \n\n\n
- Large Link targets are another aspect of accessibility that has really great usability benefits. What I mean by a “large link target” is that there is an area of a site that is “clickable” -- as opposed to a single word that is linked, or a single line. In the example on TakePart.com on the left, you can click on the picture, the title, and even the description, and that whole area takes you to the same place -- to that article about “Getting Educated about Sunscreen.” \n\nThis is really great for someone who, like I mentioned earlier, Parkinson’s or hand tremors and has a hard time keying on one specific, small area of a screen with a mouse pointer. Rather they have a generous link target with their mouse and can click to read that article with less degree of difficulty. \n\nSo, when it comes to a mobile device, we’re all thankful for a large link target. It’s pretty difficult for all of us to have to click on one single line or word on a mobile device without pinch & zooming to make it larger. I often use my iPad on the elliptical in the gym to read news articles, and I’m definitely grateful for those large link targets especially since my whole body is moving on the machine! \n
- When it comes to accessibility, there’s no one size-fits-all -- and I love NPRs podcast site because they’ve clearly provided users with multiple ways to engage with their content. This is a snapshot from their “Wait, Wait, Don’t Tell Me” podcast, and if you’ll notice: \n\n- There’s the audio version, which they can listen from the computer, or they can download the podcast to listen to later. \n- There’s a Transcript of the whole show if someone doesn’t want to listen to the podcast, or if they’re deaf and can’t always follow along with the spoken dialogue.\n- and lastly, there’s a summary of the podcast if someone is just interested in a snippet about the Tollbooth author. And not only that, they also provide different text sizes for the visitor to optionally increase the size. \n\nI love NPR for this, they’re clearly demonstrating the importance of providing people with multiple ways to engage with their content in a style / manner that works best. This really goes along with what I was saying earlier about CLARITY, CONTEXT, and CHOICE.\n
- We see this a lot: descriptions about articles, videos, links that cal the user to view / visit. This is more of a content curation, usability aspect, but this is actually a great thing for accessibility. \n\nWhen you have clear descriptions about articles that make sense, a user is more inclined to make a confident decision on whether or not they want to engage with that piece of content. \n\nI’ll give you an example -- I was trying to listen to a podcast. There were two different podcasts on different sites. One’s description was: \n\n“National Lampoon’s Rapture Radio.” \n\nI had absolutely no idea what I heard in the podcast. I mean, I was listening out for words like Chevy Chase and the whole fear that the world was coming to an end last year. I didn’t have a clue what I was hearing. I was overwhelmed. \n\nOn the other hand, I came across a “How Stuff Works Podcast” and the description was: \n\nTitle: How Igloos Work\nDescription: Igloos were created by Inuit Indians as temporary houses to use on fishing and hunting expeditions. Learn about igloos and find out how to construct an igloo.\n\nBecause of this better description than “National Lampoons Rapture Radio” -- I knew that I had to pull out my 5th Grade Social Studies vocabulary to the time I learned all about the eskimos and their igloos, and focused on being able to listen for words associated with that. And I could understand the entire podcast.\n\nThat’s the power of a really good description, especially for those who may have intellectual disabilities, or rely on clear associations of words and language to better make the connections. \n
- You see. When a website has CONTEXT, CLARITY, and CHOICE readily available around a site, that really makes for a more accessible website. It doesn’t mean just a full list of links. It doesn’t have to be ugly, cumbersome, or an entirely separate experience. \n\nAn accessible website can still look like this: [Transition to White House Website]\n\nThat is, if you understand what kind of code to develop , what kind of requirements to put together, and have a good understanding the plan execution. \n
- You see. When a website has CONTEXT, CLARITY, and CHOICE readily available around a site, that really makes for a more accessible website. It doesn’t mean just a full list of links. It doesn’t have to be ugly, cumbersome, or an entirely separate experience. \n\nAn accessible website can still look like this: [Transition to White House Website]\n\nThat is, if you understand what kind of code to develop , what kind of requirements to put together, and have a good understanding the plan execution. \n
- You see. When a website has CONTEXT, CLARITY, and CHOICE readily available around a site, that really makes for a more accessible website. It doesn’t mean just a full list of links. It doesn’t have to be ugly, cumbersome, or an entirely separate experience. \n\nAn accessible website can still look like this: [Transition to White House Website]\n\nThat is, if you understand what kind of code to develop , what kind of requirements to put together, and have a good understanding the plan execution. \n
- Now that we know about the “who” and the “what” about accessibility. I’m going to spend the rest of the time talking about “HOW” you can budget, plan, and implement accessibility for yourself, your organization, and/or your clients.\n
- How many of you are familiar with Section508? How about WCAG 2.0? \n\nFIrst of all, as overwhelming as it may seem, it’s a great idea to familiarize yourself with Section 508 and WCAG standards. These were at one point really overwhelming to me, too -- but it really helps to read through these. I found that WCAG -- which stands for “Web Content Accessibility Guidelines”---use better language that is more elaborative on what is needed to make certain web elements accessible. It’s well over 200 pages but it’s really easy to glance through it and find out the standards for specific accessibility requirements. \n\nFor example, in 508, one standard is: \n\n(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).\nIt’s intentionally broad, as is with all legal standards to keep the door open for newer standards and tech developments. Compare that with what WCAG says about text equivalents: \n\nGuideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.\n\nIt’s also a lot more up-to-date than Section508, which is actually due for a “refresh.” Section508 was amended in 1999, so in the past 13 years, our technology has really changed, so there’s a lot of accessibilty needs that are not covered by 508, and that’s where this more-up-to-date WCAG best practices really comes in handy. \n\nWeb Content Accessibility Guidelines (WCAG) are a series of “best practices” published by the W3C, and features requirements as “test cases”, which are really useful for beginning to understand the accesibility requirements.\n
- I want to talk about budgeting for a minute. Let’s say that you have a 100 hour project: \nYou spend 10 hours planning the project, \n15 hours designing it; \n40 hours of development\n20 hours of testing\nand 15 hours of remediation. \n\nSounds pretty typical right? \n\nBut here’s what happens after you launch your site, and you did not implement any accessibility into your site: \n\n* Your planning time has doubled, you added on 10 extra hours to figure out what you need to do to implement the accessibility to the site. \n\n* Designing has an additional 10 hours because some of the design needs to be re-done, like the color contrast needs to be boosted, and larger link target buttons need to be made. \n\n* Add on an additional 40 hours of developing, doubling that initial budget, because you’re “retro-fitting” the existing work to make it accessible. This is the longer route - it’s like building a ramp into the front door of the house after you’ve put in the nice landscaping, and you have to change the traditional ramp a little bit as to not completely ruin all the landscaping. \n\n* Then another 10 hours of testing, gotta test that accessible code using the screereader and keyboard to ensure everything is accessible. It’s simply not always a quick and automated process. \n\nSo a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- But here’s what happens after you launch your site, and you did not implement any accessibility into your site: \n\n* Your planning time has doubled, you added on 10 extra hours to figure out what you need to do to implement the accessibility to the site. \n\n* Designing has an additional 10 hours because some of the design needs to be re-done, like the color contrast needs to be boosted, and larger link target buttons need to be made. \n\n* Add on an additional 40 hours of developing, doubling that initial budget, because you’re “retro-fitting” the existing work to make it accessible. This is the longer route - it’s like building a ramp into the front door of the house after you’ve put in the nice landscaping, and you have to change the traditional ramp a little bit as to not completely ruin all the landscaping. \n\n* Then another 10 hours of testing, gotta test that accessible code using the screereader and keyboard to ensure everything is accessible. It’s simply not always a quick and automated process. \n\n\n
- But here’s what happens after you launch your site, and you did not implement any accessibility into your site: \n\n* Your planning time has doubled, you added on 10 extra hours to figure out what you need to do to implement the accessibility to the site. \n\n* Designing has an additional 10 hours because some of the design needs to be re-done, like the color contrast needs to be boosted, and larger link target buttons need to be made. \n\n* Add on an additional 40 hours of developing, doubling that initial budget, because you’re “retro-fitting” the existing work to make it accessible. This is the longer route - it’s like building a ramp into the front door of the house after you’ve put in the nice landscaping, and you have to change the traditional ramp a little bit as to not completely ruin all the landscaping. \n\n* Then another 10 hours of testing, gotta test that accessible code using the screereader and keyboard to ensure everything is accessible. It’s simply not always a quick and automated process. \n\n\n
- But here’s what happens after you launch your site, and you did not implement any accessibility into your site: \n\n* Your planning time has doubled, you added on 10 extra hours to figure out what you need to do to implement the accessibility to the site. \n\n* Designing has an additional 10 hours because some of the design needs to be re-done, like the color contrast needs to be boosted, and larger link target buttons need to be made. \n\n* Add on an additional 40 hours of developing, doubling that initial budget, because you’re “retro-fitting” the existing work to make it accessible. This is the longer route - it’s like building a ramp into the front door of the house after you’ve put in the nice landscaping, and you have to change the traditional ramp a little bit as to not completely ruin all the landscaping. \n\n* Then another 10 hours of testing, gotta test that accessible code using the screereader and keyboard to ensure everything is accessible. It’s simply not always a quick and automated process. \n\n\n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- So a better way to approach this is, add a little bit of extra time and money and put it towards accessibility before you even start planning or development. I’m not saying that adding accessibility is easy and free -- it does require a little bit of investment on your part, in which you are educating yourself and doing the little bit of extra work to improve the site overall. \n\nWhen you have the right infrastructure in place over the long term, this pays off and you’ll become quicker and adding accessible code will become second nature. And your clients will have confidence knowing that the accessibility infrastructure is in place for continued input of accessible elements for the front-end of a website. \n\nSo let’s take a look at what that might look like from a budget perspective: You’re adding on an extra 5 hours for planning: considering what elements of the site need to be made accessible. Taking that plan and incorporating that into the design from the beginning, and there aren’t changes to the design budget because the vision was there from the beginning. Then development has a small increase in time, because the developer is including the accessible code within the development of all elements. So back to my ramp example -- the ramp outline was already laid out in front of the door before the landscapers came in. All in all, it’s an additional 15 hours on the budget--- just roughly a 15% investment. That’s a lot better than being 45% in the hole on a budget. \n
- It’s critical to think about accessibility in parallel with your user experience strategy planning. \n\nAn example is, for FEMA, we needed to feature a disaster map on the website. One of the key first steps in this process would be to figure out what kind of map would be accessible to a screen reader. For it to be accessible, it would need to be able to go INTO the map, read out each state, and let the user know if there was an active disaster.\n\nBefore I was involved in the process, the decision to be an SVG map was made. It was such a “modern” and “newer” way of doing maps, that it *surely* had to be accessible. Well. It wasn’t right off the bat. The issue is, the screen-reader won’t pick up the title of the links, so the user would have no idea what State they’d be clicking on within the map. I spent at least half a day figuring out how to make the SVG map accessible. I tossed ideas over to our developers, too, and we were all working towards a solution to make it accessible because we simply could NOT launch this site and have a person with a disability unable to find out how to find disaster information. \n\nIf I could do this again, I would say, “The map needs to be an image map, because it’s the most consistent way for screen readers to access the site. It would have looked the same, and performed the same way. The only caveat would be, it wouldn’t be as scalable as an SVG map, so that’s one drawback.\n
- It’s not just identifying WHAT Needs to be built, but HOW to build it. \n\nIn what ways can this be developed and re-used for future sites. In our case, we had a site that would sometimes have a left-hand navigation link, sometimes it would not. So automatically having a link with “Skip to Main Content” wasn’t the best practice. \n\nWhat if the user wanted to be able to skip to the left navigation, rather than to to the main content? \n\nOur navigation system uses blocks, so our developers created a “Skip Links for Accessibility” Module and submitted it to Drupal.org -- I love this, because it really takes advantage of the community collaborative experience of working together for an accessible website. It’s currently under development on Drupal, so take a look at it and feel free to implement this for your site.\n
- Testing early and often is absolutely important. \n\nIt’s incredibly useful to have a testing plan, a test script that includes all the elements needed to test a website for accessibility. At Phase2, I developed a robust, 40-page testing plan for each element of a site that needs to be accessible. I’ve organized it into areas of “responsibility” whether it’s an accessibility requirement that the developer needs to implement, and/or if it’s the responsibility of the editor. \n\nA basic example would be, that all images need to have alt text. It’s the developer’s responsibility to include the image alt-text field, and the editor’s responsibility to fill in that text field with a quality description. \nI’ve also divided up these into which standards the tests fall under -- is it a 508 (legal) requirement or simply a best practice? This is important to consider and note, so that when the timeline or budgetis under pressure and there’s an accessibility element that is *not* required by 508, then a decision can be made to develop or not to develop that bit of code for accessibility.\n\nThe best thing you can do is learn how to use the assistive technology devices. If you have a Mac, you have a built-in screenreader called Voice-Over. Just click Command+FN+F5 and your VoiceOver will be turned on and you can take a tutorial to learn how to use it. It’s really handy and a great tool to have in testing. I love it because it’s got a “captioned” bubble at the bottom that is pretty much reading out what the VoiceOver is saying -- Yes, we can state the irony: a deaf girl is testing a website by listening to voiceover! So I’m really grateful for the text-box to follow along with! \n\nAlso if you have a PC, there’s a free screenreader called NVDA. I’m not hugely familiar with it but it’s worth checking out. The leading screenreading software out there is called JAWS -- it’s for PC and on the expensive side: $800 for a single use license. So if you can afford it, I encourage you to get JAWS. \n\nIn addition to screen-reader tools out there, you can use “toolbar” testers that scans a page of the site and visually highlights areas where accessibility breaks down -- and one is called WAVE -- wave.webaim.org. It’s pretty handy but you’d need to take it with a grain of salt because it’s reporting more problems than there really are.\n\nThis testing plan is probably the most helpful artifact to have in the planning process, because you can plan ahead and envision how certain development aspects will be impacted by decisions. \n
- Now, this last myth of people saying, “I don’t have the time, budget, or expertise to build an accessible site” becomes more of a, \n
- “I can’t afford to not make the website accessible.” \n\nThat concludes these 3 Myths about Accessibility and how they are so, so, so very wrong. Any questions? Tweet me at @cmcnally or add comments to Slideshare!\n