Think accessibility isn’t a big deal, and is only one of those issues “the other guy” has to deal with?
So did Target. And now they’ve lost $6,000,000 because of it.
In case you hadn’t heard, Target was sued by the National Federation for the Blind because its website was inaccessible for visually-impaired web surfers. At issue in the suit was whether the same accessibility standards for brick-and-mortar stores applied in cyberspace. The verdict: yes, most definitely. The suit became a class-action lawsuit, and yesterday Target settled the case, agreeing to establish a $6 million fund to pay out settlements.
Any web developer worth their salt will tell you this situation was completely avoidable. Roger Johansson, Derek Featherstone, and Jeremy Keith (among many, many others) have been advocating progressive enhancement principles that prevent this kind of inaccessibility for a few years now. It’s amazing to me that companies as big as Target have effectively said “so what?” to such a significant number of potential customers.
Accessibility in e-learning
As an e-learning developer, I spend a lot of time wondering how the various learning management systems (LMS) have managed to skate by accessibility requirements. In my experience, almost every LMS I’ve seen uses outdated coding techniques (or over-the-top ajax) that make their system partially, if not completely, inaccessible. I often go through great pains to make my courses as accessible as possible, only to be forced to load them into a completely inaccessible LMS.
If U.S. Federal law (Section 508) requires federally-funded websites to be accessible, doesn’t that include many educational websites and web services such as LMSs and online courseware? Section 508 is ten years old already… why are so many of our LMSs and courses as inaccessible now as they were in 1998?
Probably because developers who code with accessibility in mind are still considered specialists in a small niche, when we should really be at a point where they’re a dime a dozen. Accessibility best practices should be a no-brainer, taught in entry-level web development classes alongside standardized (x)HTML markup and valid CSS.
Accessibility is essentially a non-conversation in e-learning. LMSs rarely use accessibility as a selling point, and e-learning course development tools often completely ignore accessibility (especially the Flash-based tools). This has to change, but as we all know, until there’s strong pressure or some kind of impetus to change, nothing will happen.
- There are very few technical standards in e-learning besides SCORM, and SCORM doesn’t address accessibility; thus there is no technical enforcement for accessibility standards.
- The e-learning development industry hasn’t felt pressure in the marketplace, so there’s no financial incentive. (Quite the opposite, actually; the industry has been leaning more and more towards inaccessible Flash-based courseware, hoping that Adobe will save the day by making Flash more accessible.)
- The Feds haven’t really been enforcing 508 (I bet very few Fed employees even understand accessibility well enough to know what to look for), so there’s not much government pressure.
Eventually a big player in the e-learning field is going to get slapped with a lawsuit just like Target did. If that’s what it takes to wake people up, I’m hoping it’s sooner rather than later!
Comments
Ethan wrote on August 28, 2008 at 1:55 pm:
Phillip, can you expand on Flash lack of accessibility? I go over to their site and find this: http://www.adobe.com/accessibility/products/flash/
Seems that there a lot of options in the ide or via actionscript to add it. What areas are deficient in your opinion? My company does work with state governments and flash has played well with JAWS to cover their needs. We had to add all the actionscript coding but it's pretty easy.
Philip Hutchison wrote on August 28, 2008 at 3:01 pm:
@Ethan
Nice to hear someone tests in JAWS! 🙂
I've read Adobe's statements (I <a href="https://pipwerks.com/journal/2008/03/16/make-your-captivate-movies-more-accessible/" rel="nofollow ugc">wrote</a> about Captivate's accessibility once).
Yes, Flash can be made accessible, and Adobe is going through great strides to become more accessible. But for now, there are still some major shortcomings, especially when you use out-of-the-box solutions with little or no access to the underlying ActionScript (Captivate, Articulate, FlashForm, etc.).
I think the biggest issues with Flash (and JavaScript-heavy HTML) are dependence on a particular device (mouse or keyboard), and dynamic updating of content, which may or may not be noticed by a screen reader.
Adobe has stated [link no longer available] "A second issue for designers of Flash content is device independence. The Flash movie must support keyboard- and mouse-based interactions. Creating this kind of content may require guidance for novice developers."
My biggest beef — today anyway! — is not with courseware so much as LMSs. For instance, SumTotal TotalLMS requires an e-learning course to display in a frame within a popup window. Since many non-Flash courses are built with frames, this means the course might be in a frame within a frame inside a popup window! Very difficult for some assisstive browsing devices to navigate.
[Note: this comment was edited; I erroneously posted accessibility information for the Flash CS3 IDE, not Flash Player. Here's the <a href="http://www.adobe.com/accessibility/products/flashplayer/" rel="nofollow ugc">Flash Player Accessibility page</a>. ]
Philip Hutchison wrote on August 28, 2008 at 3:15 pm:
A little more on Flash: Remember also that 3rd-party developers who use Flash may create custom components or interactions that don't have the same attention to accessibility as Adobe's components.
When it comes to commercial e-learning software vendors, one would expect them to have as high (or higher) a level of detail as yourself, including adherence to best practices and standards. As I <a href="https://pipwerks.com/2008/02/04/rapid-intake-where-are-the-standards/" rel="nofollow ugc">wrote</a> about Rapid Intake a while back, sometimes you'd be surprised. (Granted, my blog post was about their website, not their products, but I think it's fair to take their website as an indicator of their attention to detail.)
For what it's worth, I'm not picking on Rapid Intake, they're basically about equal with other vendors.
Ethan wrote on August 28, 2008 at 7:01 pm:
Phillip, thanks for your insight. Yes-i tend to avoid the easy bake oven tools-you have better chance at support if you build it yourself in a ide so you can edit the AS. It's even worse when tools like captivate have to import already built swf's.
Ian wrote on September 2, 2008 at 2:58 am:
I understand the issue, but it does concern me that a company is forced to payout $6million. Where does this money go?
I work in developing software for people with severe behavioural and learning difficulties. As such the accessibility options covering switch-access control, visual impairment and cognitive learning difficulties and many other accessibility issues.
I enjoy this work and get immense satisfication in help people who are less able. But, I am deeply worried that I could get sued for not making my software accessible to a certain individual's needs.
For instance, this could lead to ANY website being sued by the Motor Neurone Disease Association for not including switch access control with pre-acceptance delay options.
If this sueing happens more, I think developers are going to be very scared to do anything, it will stifle uniqueness and creativity, and everyone will need massive amounts of imdeminity insurance.
Its all really depressing as I can't do a perfect job and yet could be sued for trying.
Philip Hutchison wrote on September 2, 2008 at 9:18 am:
@Ian
Good point. As we all know, we can't please everyone. Where do you draw the line?
Ideally, lawsuits wouldn't happen. If they do, I hope they're only allowed to proceed if the course/site/LMS developers haven't made a <em>good-faith effort</em> to make their work accessible. The question you ask is: how accessible is enough? My personal feeling is that a developer should follow basic web accessibility best practices, but leave the really detailed and 'beyond the call' stuff up to the developer's preference.
Regarding fairness, what's not fair for many developers is that many of the assistive browsing devices are (according to articles I've read and seminars I've attended) not robust enough to handle functionality "Web 2.0" websites. Many would argue that web developers wouldn't need to worry about accessibility if the companies that manufacture assistive devices/software would make their products more robust. (Cognitive accessibility is a whole other topic.)
In the end I think it's a 50-50 responsibility. All I'm asking is that people at least <em>think</em> about accessibility and make a good-faith effort to clean up their code and use basic web accessibility best practices.
OK, so people will ask: What constitutes "basic web accessibility"? Start with little things like using alt tags, not using tables for layout, using semantic markup, avoiding inline CSS and JavaScript, using progressive enhancement principles, and perhaps providing alternate stylesheets for low/high contrast or larger fonts. This is not an exhaustive list (I'm no expert on the topic), so for anyone interested in learning more, just <a href="http://www.google.com/search?q=web+accessibility" rel="nofollow ugc">google</a> it. 🙂
Scooter wrote on September 16, 2008 at 9:23 am:
So if someone can't reach the top shelf at Target… they should sue because everything is in reach. Or because the packages don't have braille lettering, or don't talk to the shopper… What do people with impairments do in these situations? They get some help. Somehow the internet provides a unique license for independance not granted in the real world.
So by that logic – let the lawsuits stay virtual. Or bring things inline… This is a thinly veiled attempt by the legal clans of America to wring another buck out of their frightened prey.
508 opened the door for litigators to poop on the system. Whiney liberal BS that dictates that everyone (and particularly minority groups) can voice their grievance and act as they want to and everyone else just has to BOHICA.
I've argued that why use multimedia at all if we can describe something in text adequately for a screen reader to 'get the point across' let's just rewind the freaking clock back to 1984 and be done with it. That was sarcasm… but isn't there a point there?
I, for one, am getting pretty tired of this garbage rule that says everyone has to be happy with everything. And forget about the fact that we have no idea how many people in our audience have impairments or what their needs are. Nor do we have great models for implementation of '508 compliant stuff'. So we are stuck 'guessing' at what people are going to need, stabbing at the generalized rules and hoping that someone isn't going to beef about it.
On the other hand, there are SO MANY good reasons to build tools and information in cleanly accessible ways. And I'm not talking about appeasing the groups of folks that might or might not exist with impairments (or their legal representation). Better reasons… Like future proofing deployments and making things usable for EVERYONE.
Dasein wrote on October 9, 2008 at 1:33 pm:
Alrighty then.
I went looking for information about what other "professionals" thought about SCORM and found a lovely rant on whiney liberals and demanding minority groups. Could we keep the political and social bias at home and just talk technology, please? It helps not to say things online you wouldn't have the guts to say in a room full of people.
Anyway…as to the issue of accessibility… I don't think there's a need to guess or hope you've discovered what users want. It seems really simple to me: create a 508 Info section on your site and discuss what you've done to offer accessibility, what you're looking into, what isn't currently feasible from a business standpoint and allowing people to offer suggestions. That would go a long way toward chasing away the trial lawyers and you'd set a good precedent for other developers to follow.
Just as someone who couldn't reach the top shelf at Target would "get some help," so can we do the same by ASKING OUR USERS what they think we can do to improve accessibility. There is no one-size-fits all approach but at the very least you address your own constituency. In any business, if you want to increase sales to your customers, you ASK them what they want. Why should it be any different with respect to accessibility.
As for the fear of developers being sued – Let's bear in mind that Target has over 1,500 stores and over $59 billion in ANNUAL revenue… I don't think lawyers are going to be tripping over themselves to sue Joe Developer Six-Pack over accessibility issues. It's simply not worth the cost.
Philip Hutchison wrote on October 9, 2008 at 1:48 pm:
And a reminder to all: If you use basic (BASIC!) web best practices you will already have made the biggest steps towards accessibility.
My original point in this blog entry was that Target could have avoided the entire mess — with little or no additional cost — simply by using best practices from day one. After all, it really doesn't take much effort to make your materials accessible at the most basic level.
A little more on Flash: Remember also that 3rd-party developers who use Flash may create custom components or interactions that don’t have the same attention to accessibility as Adobe’s components.
When it comes to commercial e-learning software vendors, one would expect them to have as high (or higher) a level of detail as yourself, including adherence to best practices and standards. As I wrote about Rapid Intake a while back, sometimes you’d be surprised. (Granted, my blog post was about their website, not their products, but I think it’s fair to take their website as an indicator of their attention to detail.)
For what it’s worth, I’m not picking on Rapid Intake, they’re basically about equal with other vendors.
Phillip, can you expand on Flash lack of accessibility? I go over to their site and find this: http://www.adobe.com/accessibility/products/flash/
Seems that there a lot of options in the ide or via actionscript to add it. What areas are deficient in your opinion? My company does work with state governments and flash has played well with JAWS to cover their needs. We had to add all the actionscript coding but it’s pretty easy.
@Ethan
Nice to hear someone tests in JAWS! 🙂
I’ve read Adobe’s statements (I wrote about Captivate’s accessibility once).
Yes, Flash can be made accessible, and Adobe is going through great strides to become more accessible. But for now, there are still some major shortcomings, especially when you use out-of-the-box solutions with little or no access to the underlying ActionScript (Captivate, Articulate, FlashForm, etc.).
I think the biggest issues with Flash (and JavaScript-heavy HTML) are dependence on a particular device (mouse or keyboard), and dynamic updating of content, which may or may not be noticed by a screen reader.
Adobe has stated [link no longer available] “A second issue for designers of Flash content is device independence. The Flash movie must support keyboard- and mouse-based interactions. Creating this kind of content may require guidance for novice developers.”
My biggest beef — today anyway! — is not with courseware so much as LMSs. For instance, SumTotal TotalLMS requires an e-learning course to display in a frame within a popup window. Since many non-Flash courses are built with frames, this means the course might be in a frame within a frame inside a popup window! Very difficult for some assisstive browsing devices to navigate.
[Note: this comment was edited; I erroneously posted accessibility information for the Flash CS3 IDE, not Flash Player. Here’s the Flash Player Accessibility page. ]
Phillip, thanks for your insight. Yes-i tend to avoid the easy bake oven tools-you have better chance at support if you build it yourself in a ide so you can edit the AS. It’s even worse when tools like captivate have to import already built swf’s.
I understand the issue, but it does concern me that a company is forced to payout $6million. Where does this money go?
I work in developing software for people with severe behavioural and learning difficulties. As such the accessibility options covering switch-access control, visual impairment and cognitive learning difficulties and many other accessibility issues.
I enjoy this work and get immense satisfication in help people who are less able. But, I am deeply worried that I could get sued for not making my software accessible to a certain individual’s needs.
For instance, this could lead to ANY website being sued by the Motor Neurone Disease Association for not including switch access control with pre-acceptance delay options.
If this sueing happens more, I think developers are going to be very scared to do anything, it will stifle uniqueness and creativity, and everyone will need massive amounts of imdeminity insurance.
Its all really depressing as I can’t do a perfect job and yet could be sued for trying.
@Ian
Good point. As we all know, we can’t please everyone. Where do you draw the line?
Ideally, lawsuits wouldn’t happen. If they do, I hope they’re only allowed to proceed if the course/site/LMS developers haven’t made a good-faith effort to make their work accessible. The question you ask is: how accessible is enough? My personal feeling is that a developer should follow basic web accessibility best practices, but leave the really detailed and ‘beyond the call’ stuff up to the developer’s preference.
Regarding fairness, what’s not fair for many developers is that many of the assistive browsing devices are (according to articles I’ve read and seminars I’ve attended) not robust enough to handle functionality “Web 2.0” websites. Many would argue that web developers wouldn’t need to worry about accessibility if the companies that manufacture assistive devices/software would make their products more robust. (Cognitive accessibility is a whole other topic.)
In the end I think it’s a 50-50 responsibility. All I’m asking is that people at least think about accessibility and make a good-faith effort to clean up their code and use basic web accessibility best practices.
OK, so people will ask: What constitutes “basic web accessibility”? Start with little things like using alt tags, not using tables for layout, using semantic markup, avoiding inline CSS and JavaScript, using progressive enhancement principles, and perhaps providing alternate stylesheets for low/high contrast or larger fonts. This is not an exhaustive list (I’m no expert on the topic), so for anyone interested in learning more, just google it. 🙂
So if someone can’t reach the top shelf at Target… they should sue because everything is in reach. Or because the packages don’t have braille lettering, or don’t talk to the shopper… What do people with impairments do in these situations? They get some help. Somehow the internet provides a unique license for independance not granted in the real world.
So by that logic – let the lawsuits stay virtual. Or bring things inline… This is a thinly veiled attempt by the legal clans of America to wring another buck out of their frightened prey.
508 opened the door for litigators to poop on the system. Whiney liberal BS that dictates that everyone (and particularly minority groups) can voice their grievance and act as they want to and everyone else just has to BOHICA.
I’ve argued that why use multimedia at all if we can describe something in text adequately for a screen reader to ‘get the point across’ let’s just rewind the freaking clock back to 1984 and be done with it. That was sarcasm… but isn’t there a point there?
I, for one, am getting pretty tired of this garbage rule that says everyone has to be happy with everything. And forget about the fact that we have no idea how many people in our audience have impairments or what their needs are. Nor do we have great models for implementation of ‘508 compliant stuff’. So we are stuck ‘guessing’ at what people are going to need, stabbing at the generalized rules and hoping that someone isn’t going to beef about it.
On the other hand, there are SO MANY good reasons to build tools and information in cleanly accessible ways. And I’m not talking about appeasing the groups of folks that might or might not exist with impairments (or their legal representation). Better reasons… Like future proofing deployments and making things usable for EVERYONE.
Alrighty then.
I went looking for information about what other “professionals” thought about SCORM and found a lovely rant on whiney liberals and demanding minority groups. Could we keep the political and social bias at home and just talk technology, please? It helps not to say things online you wouldn’t have the guts to say in a room full of people.
Anyway…as to the issue of accessibility… I don’t think there’s a need to guess or hope you’ve discovered what users want. It seems really simple to me: create a 508 Info section on your site and discuss what you’ve done to offer accessibility, what you’re looking into, what isn’t currently feasible from a business standpoint and allowing people to offer suggestions. That would go a long way toward chasing away the trial lawyers and you’d set a good precedent for other developers to follow.
Just as someone who couldn’t reach the top shelf at Target would “get some help,” so can we do the same by ASKING OUR USERS what they think we can do to improve accessibility. There is no one-size-fits all approach but at the very least you address your own constituency. In any business, if you want to increase sales to your customers, you ASK them what they want. Why should it be any different with respect to accessibility.
As for the fear of developers being sued – Let’s bear in mind that Target has over 1,500 stores and over $59 billion in ANNUAL revenue… I don’t think lawyers are going to be tripping over themselves to sue Joe Developer Six-Pack over accessibility issues. It’s simply not worth the cost.
And a reminder to all: If you use basic (BASIC!) web best practices you will already have made the biggest steps towards accessibility.
My original point in this blog entry was that Target could have avoided the entire mess — with little or no additional cost — simply by using best practices from day one. After all, it really doesn’t take much effort to make your materials accessible at the most basic level.