Accessibility – what is it good for?

There are those days when you watch a discussion unfold on Twitter, and a point is reached where a statement is made that leaves you more or less speechless for a while.

In this case, it was a discussion started by a German web developer who had to review some applicants for his company, young minds who are supposed to enrich the team they’re joining. He himself is very versed in terms of accessibility, and infused the rest of the existing company with that spirit. He stated more than once how surprised he was how little these young applicants knew about even the most basic rules of web accessibility, such as headings, form element labeling, and alternative texts for images. Others chimed in, encouraging him to do what he was doing, and also advertising it, since it clearly is something that still sets this web dev company apart from many others.

Others chimed in as well, in particular the CEO of one web dev company who stated that accessibility hasn’t played a part in his thinking for over ten years, followed by an apology. He closed with the following tweet, which basically brought the whole discussion flow to an instant halt:

Accessibility isn’t part of the recent HTML5 and CSS3 movement. Today beginners don’t get in touch with a11y.

And this was the point that left me speechless for a while, too. Here I am, working at Mozilla, a not for profit organization that has accessibility in its manifesto, that aspires to keep the web open and accessible to everyone. I am fortunate to be a known speaker in the German-speaking world and beyond, and this particular person even watched me talk at a German web conference in December of last year. But still that statement!

I talked with my partner about this –we had also covered the general topic in the past–, and the statement confirms a feeling that is causing frustration among many web accessibility evangelists: We’ve all been teaching and preaching and begging for the basic principles since when? 2000? Even earlier than that? Let’s say for roughly the past 15 years. The HTML5 committees have how many accessibility-related task forces, working groups and what not? I lost track. And here, a web developer comes along and simply states that young people don’t get in touch with accessibility at all these days, and that it isn’t part of the recent HTML5 and CSS3 movement.

After asking him how he arrived at that conclusion, he confirmed my feeling that had dawned slowly, but that, for whatever reason, I had not allowed to reach the surface of my thinking completely:

Sure there’s discussion in the committees. But no mainstream HTML/CSS site is covering that. It’s not part of the current agenda.

And this is the problem! Right there! Accessibility is a niche. Even though 20 percent of the US population have one form of disability or another, and the number of elderly people is growing year by year, accessibility is, in the broad population’s thoughts, a niche. An extra feature that one can put on an agenda, a feature list that will never be dealt with, something to keep in mind if and when there’s time.

In addition, the accessibility community is keeping it there. There’s a circle of people who know all this stuff, who meet at four or five conferences a year and tell each other their newest discoveries, applaud each other, and then go on to fight about longdesc on the zillion W3C mailing lists.

But accessibility never reaches the mainstream. Books are published about accessibility specifically. None of these topics ever make it into standard best-practices books. There are special guidelines for web content accessibility, which is a check list that scares the hell out of everyone who just looks at the mere size of the document.

There are sites like WebAIM that document progress in web accessibility, or lack of it, in annual screen reader surveys that show roughly the same picture since they were first started in 2008.

Yes, there have been some advances in some content management systems that incorporate more semantically correct and guideline-conformant coding here and there. And yes, Flash is slowly dying, replaced by Canvas which needs a lot of extra work to make it accessible.

This blog post is by no means about diminishing the accomplishments the accessibility community has made. But we need to go beyond that! We need to leave our comfortable niche and turn the accessibility extra way into the standards way. Make people use headings, correct form element labeling, and other stuff just because it is the right thing to do that benefits everyone, not because “it’s an accessibility requirement”. Accessibility needs to finally shake off the smell of being an unloved burden to meet some government criteria. Every book any web dev buys must simply state as a best practice, without mentioning accessibility at all, that for labeling an input one uses the label element, and that the for attribute of that label element needs to point to the id of the input to be labeled. As a test case, state that this way, a user can also click on the label to get the cursor right. Don’t bother people with screen readers at all. They don’t need to know for these things.

We must get to a point where teachers give their students lesser grade if they deliver semantically incorrect work. An excuse like “but it works” should not be enough to get a good grade.

If we don’t do that, if we do not manage to kick ourselves and each other in the butt and get the accessibility movement into the mainstream world, if we do not manage to make it transparent except maybe for the edge cases, if it does not lose its scary aspects, its smell of the black sheep, if it stays in its niche and we meet at the same conferences in five or ten years still, then the lines from that Bruce Springsteen song will indeed ring true: “What is it good for? Absolutely NOTHING!”


35 thoughts on “Accessibility – what is it good for?

  1. While we shake our heads at the lack of accessibility knowledge, I think the problem is less about our “niche” and more about the abstraction of basic web standards.

    How many new developers have built a web site from scratch? WordPress, jQuery, YUI, BluePrint, Drupal, etc have converted developers into tool manipulators.

    How can we expect developers to understand semantic markup, progressive enhancement, and accessibility if there’s no understanding of the core.

    I used to teach photography and see the same pattern with the new generation of Instagram users that have little to no concept about exposure, contrast, selective focus, and even dodging/burning of an image. Without those fundamentals, they’ll rarely move beyond snap shooters.

    So how did we convert WYSIWG hackers to coders? Can we do the same to get our library snap shooters to become coders?

  2. Hi, I’m Mathias, author of the cited tweets. I should probably explain my short statements a bit. 🙂

    – Personally I’m coding JavaScript and Ruby on Rails most of the time. I’m focussing on JavaScript application development nowadays. There’s much graphical programming in it as well as audio/video content. As a side note, I’m not a CEO but just a mere developer.

    – I have been following accessibility discussions quite actively some years ago. I’m still subscribed to several accessibility blogs (like this for example). Since then the topic got way more complex. I didn’t actively follow the progress in the last couple of years because I shifted my professional focus. Therefore I have no deep knowledge of recent accessibility standards like WCAG 2 and WAI-ARIA. I could not build WCAG-conforming web app without taking a significant amount of time to catch up and learn current techniques.

    – Of course I’m applying my basic accessibility knowledge every day, like semantic markup, accessible forms and so on. Because I know it’s the right thing to do. But that’s probably just 10% what it needs for a site to be accessible. I know the WCAG2 requirements roughly and I cannot claim that the complex web apps I’m building are accessible to everyone.

    – Regarding the statement that accessibility isn’t part of the HTML5 and CSS3 hype, well, that’s just descriptive. It’s my general perception. I don’t say we shouldn’t support and strive for accessibility. We definitely should! Also I didn’t mean to depreciate the work of accessibility evangelists. The point is, there is a lack of coverage and awareness. Accessibility isn’t a core topic for sites like Smashing Mag, A List Apart, HTML5Rocks and other popular web development and design sites. I’m mostly active in the JavaScript community. As far as I can see, most of the JavaScript developers are not aware of accessibility issues. Unfortunately.

    The majority does not consider accessibility as a crucial part of HTML5 (as an umbrella term). People are building huge apps and interactive experiences with HTML5. Accessibility isn’t necessarily a built-in feature. When people talk about HTML5, accessibility isn’t naturally included. Of course I wish it weren’t an extra feature.

    Given these circumstances it’s unlikely that beginners get in touch with accessibility. Of course there are great blogs and conference talks. From what I can tell, the accessibility crowd is huge and active. But since accessibility doesn’t go without a saying, everyone has to educate oneself actively.

    I know the basics just because I really dug into the topic some time ago. I subscribed to all blogs I could find. I tinkered with assistive technologies, used screen readers, used the keyboard for navigation, worked with color contrast analyzers, screen magnifiers etc. I don’t see the majority of web developers in the field doing that, which is regrettable. But I have to admit it’s hard, time-consuming (and mostly unpaid) work to catch up with the latest requirements and techniques.

    I would definitely like to see accessibility back on the mainstream agenda.

  3. When I (not intentionally) posted on twitter ( I couldn’t imagine what I was starting. My accessibility work is mostly done by the framework (self build) and the snippets I am using, so it means close to no extra work in my development process.
    Perhaps wai-aria and wcag guidelines are not enough. Do you remember the times when people proudly put some badges on their sites saying “this site is aaa conform”? Perhaps we need a new, easy label for accessibility like HTML5 stands for all these new and fancy technologies these days.

    Thanks Marco for catching that thought and bringing it to another level!

  4. I think the problem is that there have been no one that knew anything about accessibility (e.g. because they were — or had experience with somebody that was — disabled), that have have spoken about the basic accessibility dos and don’ts.

    The “cool kids” that have spoken up and formed the common wisdom, have e.g. said that the alt-text should always be filled out, leading to stuff like description of images, parts of filenames and copies of captions or titles (see small images in left column) being used for decorative images, that probably should have an empty alt-text. At least those are annoying to listen to. They have also told us never to use tables for layout, when there seems to be ways to mark a table as being used for layout.

    On the other hand the people that know something about this have, as you point out, nitpicked on w3c mailing lists or produced giant lists of esoteric features.

    So what are the top 5 or 10 pragmatic dos and don’ts? That is, what things will actually help real disabled people and not just be a checkbox-feature for cool kids (adding role-attributes to every element is not an option).

  5. It’s a loaded topic and there are a lot of things to consider before citing with any one particular point. However…
    It is sometimes important to remember during those gloomy days, :), how much the field of accessibility has matured, thanks to Apple, Microsoft, Mozilla, Yahoo!, Google, Web Aim, TPG, BBC (the list could go on).
    Technology changes, young developers come onto the scene, and accessibility has to keep up with both. I don’t think the formula will ever change.
    Yes, we will have to keep on fighting the fight and, sadly, many of the battles will be about the basics. Yet, somehow, we are constantly moving forward, not backward.

  6. I think that accessibility shares many goals and requirements with
    – mobile first
    – content first
    – progressive enhancement

    These concepts already do have significant mind-share. It might be easier to hitch your carriage to another train rather than convincing people to board your own.

  7. I agree with your tweeter. Speaking as not-quite-a-web-dev, accessibility is nearly invisible to me. The only motivation I would have to Do The Right Thing from an accessibility point of view is guilt, and that’s a notoriously bad motivator.

    I would think that, beyond the library and framework integrations you’ve already mentioned, that tools would be critical to getting more uptake. A nice “lint”-like utility that reported all of the things missing would be low enough activation energy for me to use, especially if it was integrated into Firebug or the builtin Firefox dev tools or the Chrome tools or whatever.

    That’s still on the negative side, though. What positive incentives are there for someone who does not have a screen reader or anything else that makes use of your ARIA roles or whatever they are? You mentioned getting the mouse cursor to the right point? Anything additional here would be enormously useful in just getting onto webdev’s radar.

    I think you’re using the wrong percentage value. 20% may have some disability, but far fewer than that would be helped by an appropriate use of ‘label’ attributes. On the other hand, I bet well over half of all users use the web in severely impaired conditions, generally much more impaired than the vast majority of “disabled” users. I am speaking, of course, of smart phones. Anything that would improve the (currently rather poor) user experience there would provide good incentive to filling out accessibility metadata. Nice pop-up lists of available links so you don’t have to play Operation (or zoom) to click the right link would be great. Screen reader-like technology to navigate without looking at the display could be enormously useful for in-car use (which is commonly done, legal or not.)

    I don’t buy your argument that declaring things to be the right way to do things is going to have much of an impact. My experience with stuff on the web is that people will do anything and everything wrong as long as it appears to work with their own browser, screen size, language, etc. Even people who start out trying to do the right thing will hit some point where they’re trying to get something to work, will randomly mutate things until it does, and then fail to undo any of the intervening mutations as long as they don’t visibly matter.

  8. I think you’re using the wrong percentage value. 20% may have some disability, but far fewer than that would be helped by an appropriate use of ‘label’ attributes.

    There you have it. This attitude causes all the a11y problems we have. Using a label element and linking it correctly to the proper input element is not a just question of a11y. It is a question of following given (and useful) standards, a good coding style and knowing your territory.

    Now I see what all the other a11y guys from twitter meant.
    The war is not over. It seems like it has just begun.

  9. What I miss most in my everyday work (of which a11y is a very small part only) is a ressource where I can look up things (think of it as an improved SelfHTML for a11y).
    I know you and others have written a lot on this subject, but it’s not a solution to read a dozen of blog posts just to get an idea which roles to place on which element of a search suggest box. Honestly, I can’t afford the time. We are a small company with me being the only webdev. Bugging you on twitter, as I often do, isn’t a solution either.

    How to implement accessibility has to be accesible for those of us who are not able to spend hours everyday on this topic. Currently it is not.

  10. In my opinion there are two fields, that are important fort he spreading of accessibility: education and ready-to-use-products.

    I’m thinking too, that that we can achieve a lot more, if we move accessibility out of its “niche”. Most of accessibility is just craftsmanship, solid craftsmanship. Who’s witing semantic code, respecting webstandards and caring about the quality of his results, is already doing a good job for accessibility. If institutionalized education would be up-to-date and teachers would care abaut the quality of their student’s work, there surely would be some more good websites.

    From those who want to use Bootstraps and ready-to-use wp themes, because they just want to blog, we can’t expect that they dive into the code to check up the quality of the selected theme. In this case we have to get connected with the producers of the theme or the wp core developers and care for fitting accessibility in and getting it delivered with the standard theme.

    And of course there should be a central ressource with 10-x best practices, where interested developers can easy get in touch with the basic facts of accessibility.

  11. What’s missing is something along (perceived) instant gratification. Why do many devs nowadays use heading elements? Because they’re told, that this enhances their Google rank. In many cases they haven’t even heard of accessibility implications of that decision (let alone the HTML5 document outlining algorithm). Why do they use table-less designs? Not because of a11y, I reckon.

    The corollary is, that a11y needs a hook, something to bring it to the front of developers’ toolboxes. Some lever to help them in project deadlines and marketing meetings. There is no or too little direct feedback (like a Google Analytics field: “Your website got 43% more blind users this month”) possible for following a11y standards and recommendations.

    One such hook, just off the top of my head, would be to list and explain Javascript-less interactions based on good a11y techniques. How many devs know, that, when you click a label, the according input gets the focus? We think of this as common knowledge and forget in the same moment, that there are hundreds of young new developers coming next, who by chance have never noticed that browser default. Or mention the “required” and “readonly” attributes more prominently as a way to guide users through forms without catching key strokes in scripting.

    PS: Thanks Janet for getting the music quote right. I was about to post the same remark 🙂

  12. Addendum: Another great problem with Accessibility is, that you can get it wrong in a thousand places rendering your site useless for people though acting in good will. ARIA roles can be dangerous (body role=”application”), just to pick one, and the usual dev has no means of testing her decisions.

  13. Here are some comments from a bottom-rung front-end developer.

    The kinds of stuff in Steve Fink’s comment is absolutely important: THIS is what we need to look at. This is exactly along the same lines as what colleagues of mine say: if I mention stuff isn’t keyboard accessible (and by that I’m only talking about, I can’t see where I’m at when I hit Tab due to lack of :focus styles… not talking about weird Javascript whatevers here), and they say “well we’re not going to spend time working for that small percentage of weird people who use the keyboard; we’ve got a long list of stuff that needed to get done yesterday already.” They have a point, and they also miss the bigger one.
    Mathias(molily) is *exactly* right. Other than in some SitePoint books I’d gotten long ago (and good for them! Javascript Anthology is one example of consistently mentioning accessibility), in general accessibility is not considered a basic part of web design/development. It’s just not. Look at the “headings” of lists in Twitter Bootstrap. That could be fixed, though now it would break backwards compatibility, so they probably wouldn’t want to. But it was released that way, and it’s an example of a *very* popular framework targeted specifically at developers who don’t want to play around with front-end styles that much if at all. It’s meant to be thrown in and Just Work. That means nobody who isn’t a front-end developer is going to go in there and “fix” it to have real heading semantics, for example. I did, for a client who didn’t really care either way, but I wouldn’t push it to GitHub. I’d be rocking the boat, breaking backwards compatibility, being a cowboy, and who the hell am I anyway? Some minimum-wage code monkey whining about cripples. If they’re not saying that, they’re thinking it.

    Also Fink is correct in explaining how an “average” (not really into a11y but still trying because all the gurus keep saying it’s a Good Thing) web dev would try to get things working. And I agree that ARIA as far as landmark roles is almost purposefully limiting itself by not being available outside of actual AT software (sighted keyboarders without AT could really get good use of landmarks… hint hint browser vendors). And that mobiles bring out most of the same frustrations in the general web-surfing population that the disabled community has gone on about for years. Mobile is probably the Web’s one chance to get “average” developers on board.

    Maik Wagner brings up a good point about ready-to-use. Rian Rietveld, who’s been working on Accessible WordPress stuff, said “imagine if the plugins people add to WP were automatically accessible, out of the box?” As a developer you like to know that when you add some plugin, not only has someone already tested it on 600 browsers and devices, but also gave it a decent accessibility test? Plugins are marketing themselves over their competitors by stating that they for example “work down to IE7!” and similarly there was an announcement on some Twitter Bootstrap plugins (font icons). As a developer you’re more likely to choose the plugin who is labeled as “works cross browser”. Imagine if they were also tested with AT as well. Or at least built to the specs even if actual bugs with AT aren’t known: you at least know the markup and JS and fallbacks aren’t cruddy.

    Lastly, while I’m a developer who *does* give a rat’s ass about accessibility, I don’t currently work for a company who does. I’m surely not the only one. When “the top SEO guru in the country” tells a client of ours that using pictures of text insead of real text is “doing it right” (pictures can’t be seen by Googlebots, and if every page has the same footer/sidebar/whatever text, then it’ll “dilute the google juice” or some damn thing), there’s no way in hell you’re convince them otherwise. Same with making non-headings headings and styling other things as headings instead of letting real ones “drag down the importance of some other thingie on the page we want to rank well”.
    Low-wage code monkey versus a “top SEO”? Code monkey loses. Every time.

    Low-wage code monkey verus a top graphic designer/design group, for whom the client has paid a *lot* of money for and whose design uses 8px and 9px font sizes to make the (increased for SEO reasons) content fit in a small, px-width container? Code monkey loses. Every time. Especially when the client is extremely pleased with the design they got.

    So to list and then build on Maik’s points:
    – we have to reach average web developers, by making accessibility a basic part of web design and development, maybe mobile helping here. This would mean reaching out to all the big sites, books, etc people go to for webdev knowledge. If it’s not even mentioned, the web dev doesn’t know it even exists. I too remember the first time I heard of a screen reader. They were mystical machine thingies nobody seemed to know anything about.

    – we have to give web developers a few (preferably only one or two) places where they can get most if not all accessibility knowledge where they can look it up, dive deep into specs if they need to, but also have access to plain-English (and hopefully plain-OtherLangs too) versions describing the problem, the solutions, and the techniques. Someone asked a good question on the SitePoint forums: how do I make an accessible (conform AA) overlay? There are lots of things regarding those out there, some good examples here and there, demos at places like Paciello Group and Filament Group, but no one *single* good, big resource (and no, WCAG and W3C pages are not readable to average devs, unless you speak spec-ese). Suppose Mozilla’s MDN or similar had a section, or Opera Dev pages, except bigger and more well-known to all web developers.
    Guess who’s still known to all web developers?

    – As Maik said, we need frameworks, designs, plugins and script snippets that not only “just work” cross-browser, but are also built to specifications regarding accessibility. What jQuery has done (made a pre-built version of just about every javascripted thingie people like to plop on pages: carousels, dropdown nav bars, styled forms, tweet/weather widgets, hide/show, etc) could be done for the things listed above: accessible (as much as reasonably possible and doable) version of these things. Like Filament Group made a jQuery form “slider” which automatically incorporated aria-roles (which I understand jQuery itself had done since 1.9?) and gracefully fell back to a select element. It was a demo, but stuff like that? All together in one resource? Would be awesome. Some client says “I want a slider there!” The web dev should ideally be able to go “It’ll be there in 5 minutes!” and it’ll work cross-browser, cross-device and with varying levels of JS support, CSS3 support and AT. Not entirely a dream, right?

    – we need a resource for developers like me where we can figure out how to sneak accessibility into stuff. Yeah, we shouldn’t, but frankly we need to. Super Secret Accessibility. Tricks for people working with templates, CMSes, frameworks and whatnot. Maybe a secret forum and secret handshakes. I’m only half kidding.

    Wish list, I want a p0ny for Christmas:
    – CMSes that didn’t suck. Don’t think one will ever exist, because they’re only really nice and useful when they’re very, very specific to a type of user and a type of content. But a girl can dream.

    – A disabled/AT-using testing pool. God I know some developers who’d give up a first-born to pay into some system where disabled testers from around the world tested websites and web applications and gave all levels of feedback. Some third-party would have to set this up: developers pay some regular fee in. Testers are not volunteers but part-time (or full time?) workers who get paid to test websites. That means they would get at least some minimal training about testing (ideally a lot of good training). And each feedback post would have to contain the hardware, software, disabily(ies) and Internet-user-level of each tester. And probably the ability for the developers to communicate further with testers for better clarity.

  14. I am also a front-end dev in a company where accessibility is not tested, and not a leading factor in architectural or design decisions. The team *wants* to do the right thing, but their attention is elsewhere, so I’m constantly inserting as many best practices as I can into the markup.

    The main problem, having been invested in the accessibility community since 2003, is that accessibility is seen as a checklist. Legislature such as Section 508 promotes this way of thinking — “make sure you check 0ff this, this, this and this and boom your site is accessible”. Checklists are easy to reference. Developers love them because lints and validators can be written against them.

    The reality is that accessibility is a philosophy. It is a mindset. A strategy. A tenant. This is the brilliance of WCAG2.0 that most from the sidelines fail to grasp. It uses words like “perceivable” and “understandable” — abstractions that try to convey that accessibility is foundational, not something that cannot be tacked onto the end of a project.

    This is why a11y never gains real momentum in the industry. It is not sexy. It’s not a jQuery plugin, it’s not “responsive”, it’s not new, it’s not something that impresses others or provides glitter in a portfolio, and worst of all, it can be “safely” ignored without any “real” consequences. But most of all, it requires a developer to stop testing against devices and browsers and think about testing against humans and that requires patience and empathy that is simply too scarce.

    I don’t buy any arguments about not having resources from which to learn, or not having time to invest. That’s a bullshit cop-out. There are hundreds of sites on the topic, and a day of real deep dives will change a front-end developer’s outlook forever. A developer needs to want to learn.

    Marco, great article. but I personally disagree with this:

    But accessibility never reaches the mainstream. Books are published about accessibility specifically. None of these topics ever make it into standard best-practices books.

    My book on business websites published by Apress had an entire chapter on the importance of accessibility, before any discussion on how to actually build a site.

  15. Accessibility will become mainstream only when it is considered a core “product requirement” for the webside / Web application.
    The requirements / design specs for a website / application should consider accessibility on par with other specs like functional , usability, “look and feel”.
    When functionality is broken the transaction cannot go through and it becomes a show stopper.
    Likewise when the look and feel is not right, the managers will refuse to launch the website.
    But poor accessibility today is not a show stopper and the site gets launched or there is pressure to get only the hurriedly identified “glaring / critical issues” fixed right now.
    This is because an accessible site may appear no different from an inaccessible one to the ordinary user who does not rely on accessibility features of the browser / assistive technology.
    CIOs and project managers may not understand or be able to “see” where the hours spent on making a application keyboard-operable or a Web page expose structure and reading order correctly really went.
    Then for developers too, working on accessibility resolution / fixes or even design is not a highly visible or rewarding task.
    Given this, accessibility awareness and education at the upper echelons of an org becomes important.
    The ability to sustain the accessibility initiative after it is launched requires effort and drive.
    It needs to be internalized … not person-dependent.
    It is the legal mandate that will make upper management not lose sight of accessibility when they are under pressure to produce higher revenues and profits.
    Sailesh Panchang

  16. Hi, I’m the type of guy who gets frustrated when I can’t use the keyboard to navigate a site. Here are some thoughts I got when I read this excellent blogpost

    I created a11ymemes a while ago, It was really funny and there were many other contributors as well (who had left the zillion mailing list). One thing I thought of (just the other day actually) is that it wasn’t that many issues that got mocked. It was the basic stuff that you’ve already mentioned here like labels, headings, tabindex and keyboard navigation. Basic I say? yes in my humble opinion, these are the basics of accessibility.

    Where can we teach new, young developers about these basics? why not use the or/and create stuff like, short informative onepage sites that describes the actual a11y problem.

  17. @icaaq the memes are a place where I can just vent frustration; very nice, thanks.

    I notice that’s becoming a “thing”, these one-issue or one-property sites. Like and similar. But as a developer I don’t want to scurry around everywhere looking for this and that.

    I don’t buy any arguments about not having resources from which to learn, or not having time to invest.

    It’s not that there aren’t resources, it’s that there’s a bazillion resources, each with a little bit here and there, and then sometimes out of date. Even when I’m willing to spend a half-hour looking for the best solution, such a barrier guarantees that other developers will skip over it. I believe developers will use a resource more if there’s one, or a very small number of very trustworthy and easy-to-find-stuff-in sources, preferably that contains (almost) everything. (Or maybe not, since finding stuff in a huge pile of information can be difficult…)

    But most of all, it requires a developer to stop testing against devices and browsers and think about testing against humans and that requires patience and empathy that is simply too scarce.

    And money. Like all user testing. It costs money and that will always come out of the developer’s personal pocket when they don’t have anyone backing them. Even Steve Krug said testers should get a small gift, or lunch; after all, it’s costing their time and effort. This would have to come from my minimum-wage, and would have to be on Sunday or in the evening because it would be done in my free time (and testers’ free time). Finding people willing to do something like this (for free or even if for lunch) is difficult. Finding disabled ones is even harder.

    I wish it really were as simple as just having enough patience and empathy. User testing is not easy, especially doing it on your own, and empathy alone will not get you through it. It’s not a “cry harder, Simba!” thing.

    Sailesh says “It needs to be internalized … not person-dependent.” Yeah, that would help immensely.

    None of the above is any excuse not to do user testing, because it’s worth it. But it’s certainly an important *reason why* it doesn’t get done though.

  18. I wish it really were as simple as just having enough patience and empathy. User testing is not easy, especially doing it on your own, and empathy alone will not get you through it. It’s not a “cry harder, Simba!” thing.

    You’re right. User testing is time-intensive, and it takes a lot to convince an organization to spend money on it. This cannot be overstated.

    I was thinking of a slightly simpler tactic when I wrote my original comment. There are many tests a developer can do solo — before a prototype graduates to actual humans. Try tabbing through the site — are all nav elements accessible? Try turning off styles — does the content and image information read in the right way? Try disabling JS. Try turning off images. Try blowing up the font size to max in IE7. Try using Mac’s voiceover technology. Try using it on an iPhone with accessibility turned on. None of these tell the complete story, but they go a long way in fixing the obvious problems.

    My point was that developers test the graphical display of a page over and over in browsers and devices, but the real challenge comes in trying to access content from the inside out, stress-testing the markup to see if there really is separation of content from structure.

    Like you said: this does not replace humans. Nothing does. But these are basics that should be written into every plan just like checking a page on an iPad.

  19. @Kevin: ah. Agreed fully with your comment; I call that kind of testing (with/without images, css, js, different screen contrasts…) situation-testing. I’d also like more developers to do that, but first we don’t know how to convince them that such testing is important; that there are people in “this situation” and “that situation”. That there really are people without any problems or bad hardware or whatever who use the keyboard to navigate things (because for some reason, once you say “someone without a mouse” it seems some devs decide that’s some tiny ignorable percentage of non-people, whereas phrasing it as “there are people who use keyboard because it works best for them” seems to help imply a (possibly large) unknown number). Convince someone that the site might get loaded without images (slow public wi-fi connections for example), and they’ll want to test for the no-image situation. I would think.

    Similarly, on the mobile front, it’s most often than “it was tested on mobile and looks okay” means only latest Android and some iThing. As if that’s even the majority of mobiles in use (a speaker asked at the Fronteers conference “who here has an iPhone?” and almost every hand went up. Maybe developers assume that because *they* have iThings, everyone does?).

  20. Hmm…. my feeling is that accessibility tends to be presented as something separate, not as an integral part of the design and construction of web sites and web applications.

    You buy a book on web development, and it probably doesn’t say all that much about accessibility – there’ll be some other, separate book on that, but most developers probably won’t buy it unless they have some specific reason to do so. They need to be the same book (or web tutorial, or whatever) – accessibility needs to be taught as an integral part of web development – and not just as an ‘advanced’ section near the end, either.

  21. Marco, I think you touch on a very important subject. And you are certainly right to underline the fact that accessibility, as a discipline, has failed to become accessible to the people who make the Web.
    Now, I have given a great deal of thought to that question, and have shared various opinions and ideas with some of my peers, specifically regarding the idea of an a11ybok, for accessibility body of knowledge (see here: and there: for instance). As Stomme Poes, I’m a strong believer that people who look for any given piece of information about accessibility should be able to find it quickly, with a good level of confidence and reliability, and if possible, for free. Some may argue that the WCAG are that one source of everything you need to know about Web accessibility. But of course, if that was true, then we wouldn’t be in the current state of things.
    Now, it’s easier said than done. Various initiatives have been started, and some can be considered close to it (see my own collection here on Quora: – contributions appreciated). It requires a coordinated effort; but the debate around that idea has revealed that defining exactly what should be done, is already a subject in itself. And as for today, this question remains to be solved (if it can ever be).
    One of the comments calls for a simple list of 10 things to do to make things more accessible. Interesting idea, that has been considered by many practitioners already. But it raises a major question: what constitutes the 10 most important things to do for Web accessibility? If you want to serve all users equally, then you’ll probably come up with a list of probably around 50 best practices that can’t be discarded without creating barriers to access. And each best practice can be addressed in different ways. Sometimes, what is a solution for one recommendation creates issues regarding other subjects. And so on.
    If specialists spend so much time discussing details, it’s not for their masochistic pleasure; it’s because they understand the underlying complexity, and know that what seems good for John will be bad for Jack. Accessibility isn’t simple; it’s complex by nature. We need to recognize this complexity, and live with it.
    A direct consequence of this complex nature is that what seems straightforward to some, will seem cryptic to others. A couple of years ago, I was commissioned to write internal guide books for an organization, detailing ways to make images, videos, and other components accessible, with respect to WCAG2. They wanted to know everything about each topic – yet it was forbidden to use technical terms, even the term “HTML” was not allowed. I couldn’t either refer to any given CMS, it had to be “agnostic”. Possibly one of the most challenging works I’ve done in this area… It resulted in 80-pages-or-so booklets, one for each topic. Because, paradoxically, it had to be “simple” yet comprehensive, it induced a great deal of complexity.
    That said, accessibility is complex, but it isn’t difficult, most of the time. Given enough time and effort, any reasonably competent web maker, be it a developer, designer, or writer, can deliver fairly accessible content. It’s like painting a wall. With appropriate tools and instructions, anyone can do it, more or less. The difference will be in the time spent in delivering a satisfying result. The tools won’t do it for you, yet without good tools it will be a pain. Some materials or textures will be more challenging; this is where you call in a pro. For most of the works, the basics will suffice. But don’t expect to have a fully professional result, by definition.
    The issue with accessibility, is that you have not really finished until everything works fine (all the details are well painted, up to a professional level); which involves to encompass a broad range of skills to deal with all the various subtleties you will encounter.
    In conclusion, I appreciate and hear the fact that there’s a call for simplification. But in reality, accessibility is complex, and it can’t be reduced to a 10-point checklist. Besides, difficulty or complexity are not necessarily the real issues. All this can be tackled with enough motivation – and this is where the problem lies. Most people won’t put in that extra effort because they don’t understand why they should do it. Once they have, all obstacles seem more legitimate.

  22. If we want to get accessibility into the mainstream we’re going to need good examples of accessibility failures regularly brought to our attention. Not legal threats over compliance, but human stories of failed interactions with real world consequences.

    Accessibility is usually an integral part of the development process in organizations that can afford to (or can’t afford not to) have an integrated process. But these are in the minority, and most new developers are simply innovating as fast as they can to get the job done and on to the next project or buzzword. Accessibility doesn’t matter to them, even if they were taught the techniques, because a) no one is enforcing it as a matter of process, and b) they cannot put a human face on why “doing it right anyway” is so important.

    I’d love to hear case studies of frustrated users whose lives were saved by an alt attribute. I’m as guilty as anyone of lazy coding practices when I don’t think they matter much.

  23. Marty wrote: “I’d love to hear case studies of frustrated users whose lives were saved by an alt attribute”.
    I don’t have one at hand; yet I have seen sites where the contact phone number was displayed through a background (CSS) image, of course with no replacement text in any form. Had this number been dedicated to emergencies, it would have been a serious issue.
    That said, I know at least one example where accessibility in communications has actually been a matter of life and death. When the French sanitary authorities launched massive prevention campaigns against AIDS, in the 90’s, they omitted to provide signed versions for the Deaf. As a result, many young people who communicated solely through sign language, were not aware of the vital need for protection. Some even thought that, since the campaigns were directed only to hearing people, they had to be related to a disease that only affected hearing people. From an outsider it makes no sense, but if you understand a bit the Deaf culture and state-of-mind, it’s only too logical.
    Can’t think of the number of people who got infected by the HIV just because nobody told them the message while taking their needs into account.
    So, yes, the lack of accessibility has actually killed, in this instance.
    I hope it helps you understand why laziness, or even time or budget, can not be an excuse for not making some contents accessible.

  24. Hi all

    Great discussions and points to consider.

    A11y is considered a niche because it’s generally positioned too low on the food chain as a functional requirement. To echo Kevin’s comments, A11y should be viewed as best practice in strategic business management that is delivered through the ITC function. In the most advanced forms of accessibility adoption it really is a wholistic process that affects most parts of an organisation.

    Web accessibility as a process, is about the organisational adoption of a set of principles and values that result in systemic culture change, which can never be achieved through checklist thinking.

    Australia is suffering from a checklist mentality (amongst other things) but that is part and parcel of where we are in the Accessibility Maturity Model:
    “Just give me a checklist and I’ll tick the items off…”

    As stated by other commenters accessibility is complex and checklists in complex environments only work when the person checking off the list understands the operating environment and the interrelationships within it. If you don’t believe me, then let me go into the cockpit of the next airplane flight you take and see how far a checklist mentality will get us!

    So my advice to all the developers who are frustrated is to keep your a11y fires burning bright, keep creating code in aligment with best practice and standards, keep waling the talk as much as you can because I’M LETTING YOU OFF THE HOOK!

    Although A11y was born in the realms of web/ITC it should never have been your responsibility to lead the charge. To take something out of the theory and into the business world takes entrepreneurs and thought leaders who aren’t afraid of being called crazy when they want to champion a new organisational initiative.

    These thought leaders in business are few so that’s where environmental forces come into play such as the threat of litigation and government mandates for accessibility. Litigation is a real concern and don’t think large corporates are ignoring it. I recall when the first passive smoking legislation was passed in the US – the large international bank I was working for in Australia promptly announced the VERY NEXT MORNING that our organisation would become non smoking within 90 days.

    That tells me that they had been planning this for months and the anecdotal evidence I’m seeing is that large companies and government departments are doing the same with web a11y. In fact the smart ones are openly embracing it because they’ll find it easy to capture 20% extra market share.

    We just need to be patient. Patience doesn’t mean waiting passively – it’s knowing when to pick your battles.

    So I’m doing my bit using a good old fear campaign – all your corporate and government initiatives that espouse ENGAGEMENT, INCLUSION, EQUALITY will fail if a11y is not adopted as an organisational principle.

    You can never achieve any of these principles if you don’t offer accessible digital experiences. In fact you are only paying lip service to these values because inaccessible digital experiences support DISENGAGEMENT, EXCLUSION AND INEQUALITY.

    In fact all the business cases for digital experiences that have ever been developed where a11y was NOT on the agenda and are citing cost savings will be grossly inaccurate because when a user with a disability cannot access the information they were told is on a website, they will make a phone call. When they make that phone call and the Indian call centre is unable to assist them, they will make a complaint or require additional assistance. All these instances (20% of the population and growing due to the silver tsunami) will create enormous inefficiences, cost blowouts and reduced satisfaction because of the extra work required to satisfy a consumer’s request that could not be fulfilled by the digital channel/touch point.

    In relation to the comments about not having access to a disabled user testing pool, there are two resources I know of:
    1. Loop 11 is an Australian company who in conjunction with Knowbility have set up a database of users who have various disabilities. From memory there are over 100 people in their database. Please note that this is not a technical audit against WCAG 2.0.

    2.0 The Disability Accessibility Centre in Wales have experienced testers who do both user journeys and some technical testing (although I believe they work in conjunction with a specialist accessibility auditor).

    Just a note about users with disabilities – they’re actually people wanting to live their life fully just like you and me. I work with colleagues who are profoundly deaf, legally blind and mobility impaired – they’re not asking for much, they’re just like you and me wanting to buy tickets to the latest concert without the form timing out because when the page was increased to 800% in the screen magnifier, the submit button was hard to find and used an image of text.

    There were some comments about not having much time to learn about all the nuances of a11y. To this I would respond “How much effort have you put into learning HTML5 so far?”

    Web a11y is just frustrating because there’s not one place to “get the answer” and the authoritative source is written in a style of language that supports the description of standards.

    So here’s my shameless plug: Access iQ is developing these resources. I know there are other places on the web where you can gather to discuss and share and get free information and they’re important in expanding our knowledge and
    awareness. But we’re a social enterprise which means a not for profit who trades to fulfil its mission (which ensures we’re sustainable) and to ensure we can work towards our mission of a web without limits, we need to be financially sustainable. No one’s buying a yacht here…

    I’m mentioning this because we’ve invested a lot of time in slicing and dicing WCAG 2.0, understanding it and explaining it in plain english as it pertains to the different job functions in the web development lifecyle. All because that’s our overarching reason for existence, to advocate equal access to media and technology for users of all abilities.

    You would know that an accessible form is both the responsibility of the designer and developer. So we discuss the relevant success criteria for forms from a designers perspective and from a developers perspective.

    At this stage we’ve completed everything to know about accessible content, now we’re writing the information for developers and early next year, the designer resource will be available.

    The resources are technology agnostic – we’re teaching you abou the underlying principles you need to understand first and then you can add the technology layer over the top. Having said that there’s nothing like a good code sample to cement the information home so I’d be happy to offer free access to anyone who has the suitable knowledge and skills to develop code samples and examples.

    If you’re into going to the authoritative source, WCAG 2.0, my colleague Sarah Pulis has lovingly catalogued all 500+ success criteria using a kick-ass metadata schema. That means, using the facets on the right, you’ll be able to find all the relevant success criterian you need to consider when designing forms or researching colour contrast.
    You’ll find the link at the bottom of our homepage – Web Accessibility Wizard – have fun!

    OK that’s enough from me – I obviously have alot to say on the matter (perhaps it’s time for my next rant on our own site). If you do too, I’d personally love to hear from you. firstname at accessiq dot org
    I promise to keep making this a senior executive issue so you’ll look like a bloody genius and god send when the next manager comes in puffing, looking slightly pink and waving a bunch of W3C printouts saying “this site needs to be accessible!”.

  25. Amajjika: “Loop 11 is an Australian company who in conjunction with Knowbility have set up a database of users who have various disabilities.”
    I’d seen Loop11 before and I thought it was a paid-for usability testing service. Good to know they do accessibility too!
    The website happens to be mentioning a “fatal error” at the bottom.

    Why is Australia the progressive country here? 😀 Europe needs a kick in the butt.

  26. As a web developer, if the numbers showed that your existing website would be accessible to more people by including more non-english languages, would your re-prioritize your work break down to focus on including non-english than getting the wcag done right?

    For facebook, a global social networking site, it’s in their best business interest to be accessible to the most number of people as possible, and yet they seem to have put more priority on including other languages over wcag. Do they have it wrong? Do we say that facebook is an inaccessible site because it doesn’t have semantic headings, etc? Or do we say that this website is inaccessible because it doesn’t have it’s content available in hindi, etc?

    (Just to be clear, I’m in very strong support of accessibility, and think every web dev needs to be aware of it as part of their job function. And I’m a fan of ALL people having access to the richness of the web, disabled or not.)

  27. Stomme Poes said: “Why is Australia the progressive country here? 😀 Europe needs a kick in the butt.”
    Actually Europe and the UK is where I draw alot of my inspiration from.
    Despite geo political barriers, web accessibility is truly a global concern. But thanks for the compliment!

    My interest (and capability) is in embedding web accessibility principles into an organisation because that’s where it’s going to “stick”.

  28. You certainly kicked off a great thread.

    I just wanted to mention that “introducing HTML5” by Bruce Lawson and Remy Sharp has accessibility snippets sprinkled thought like good seasoning. An excellent approach in my opinion.

  29. Firstly, thanks to Marco for such a great article. As a user who ticks three separate impairment boxes, and who consults on information accessibility issues, I’ve been banging on about accessibility merely being best practice for a few years now. After all, there’s always at least one other great reason to include alt-text, semantic markup or any so-called accessibility feature you could name, besides including a minority of users. In fact, I could talk accessibility features without mentioning disabled people at all. And this is quite apart from the fact that a global ageing population is going to require more of these features in the future.

    Now, how about accessible documentation?

  30. So here’s the thing.

    I’ve been talking about accessibility for most of my (13 year) career. You might almost call me puritanical, or at least, I was at first. Then I started to notice that the puritanical attitude shown by myself and many other advocates was actively putting people off, or so they would claim.

    So I tried to embrace a wider view, a view that says accessibility is about everyone, not just the needs of people with disabilities. I tried to sell it in terms of extra benefits, like support for mobiles and older browsers, better SEO and reduced bandwidth that comes from cleaner markup, all that stuff.

    But what happened? It had exactly the opposite effect? By selling accessibility in terms of those extra benefits, people had the freedom to say, “well I don’t care about those extra benefits, therefore I don’t have to do that stuff”. Which of course misses the point entirely. You have to do that stuff because it’s legally and morally obligatory, the extra benefits are just, well, extra benefits.

    So now I’ve come full circle, right back to where I started from. And web accessibility is running in the same, endless circle. Everything you say in this article is true, but it’s all been said before, and every response to it has been said before, and every reaction to that has been said before. Nothing ever changes.

    Most people just don’t give a monkey’s about accessibility. There’s no business case for it, and business has no time for moral arguments, its only interest in accessibility is meeting the letter of the law, hence the checklist mentality.

    Yet it runs deeper than that. Some people actively oppose accessibility, seeing it as unfair discrimination, an issue I explored in The Angst of Accessibility. The comments are all over the place, and I really lost it; in fact I stopped blogging for a year and a half after that.

    So sorry if I said jaded, but that’s because I am. Now I just focus on doing the best work I can personally do, and talking or writing about accessibility only in very specific terms (eg. to remind people that flat UI design can’t rely on color). But I don’t live in hope that the general attitude of the industry in general will ever change.

    @Stomme poes — I’m glad you liked the book, it was a pleasure to write 🙂

  31. When I put HTML5 Bones together I made sure I included WAI-ARIA roles (only a part of accessibility I know – but it’s a start) and explained them to the best of my ability. I also included an example of how to use WebVTT to provide video subtitles. The main reason behind this was to introduce people who might use the template to their existence and importance. The “world’s most popular template” (HTML5 Boilerplate) fails in this regard (but succeeds in many others) so I would like to see that change.

    We have also covered some accessibility topics in the past over on HTML5 Doctor, we even have the mighty Steve Faulkner in our ranks, but perhaps we should concentrate some more on this topic. Any specific suggestions?

  32. I think the flavour of the comments posted here from the young ‘uns on the coal face sums up the problem: it’s too damn complicated at the moment.

    Having fought the battle with local government accessibility testers for 10 years, I have seen the confusion. Like the guy who failed our system because our s had only one . And the endless arguments about title= and alt=.

    Then there is the eternal tension between W3C validation, security measures, and accessibility. You know – turn off auto-complete as the security guys say, and fail the HTML validation. My code, alas, has to run under the DOCTYPE of the customers site – so adding a role= on an HTML 4 site and again failure, if I remember correctly.

    Its all too damned hard. It was easier programming assembler on VAX-11. They were beautiful and thought out. We need more of that please.

    1. The essentials needs to be a core part of HTML, not bolt ons. ARIA should not be separate.

    2. The recommendations need less caveats. You know less of the ‘until suitable user agents’ and stuff.

    3. …..and not written like an academic paper. I’ve got a maths degree, but I really don’t want stuff in terminal font written to bore the pants off you. We shouldn’t need a11y to tell us about use of title=, it should be obvious from the W3C stuff.

    4. Give us somewhere that is universally accepted that we can go and get a ‘tick’ on accessibility syntax. I know there’s no universal panacea, but give us a baseline that it testable and universally accepted. Integrate it into the W3C HTML validator, then there’s not argue. Add tick box so you can turn it off, but default it one.

    5. Give us a W3C validator that will cut us some slack on using newer accessibility options on older doctypes. After all, the old browsers don’t care, by and large. I know this is re-writing history, but would it hurt?

    I think all mortals are completely stumped about what they should be doing about accessibility on snazzy jQuery. This is a massive problem, because we need this stuff to sell our systems. The first part is simple:

    4. Go to the guys who produce the 50 most used jQuery add-ins – I’m thinking TableSorter and Chosen etc – and help them make all these as accessible as you can. Then write up the experiences so others can learn from them.

    The bottom line is always KISS. You can’t dump endless complexity on to the guys cutting the code an expect it to turn out all roses.

  33. (whoops! I posted an earlier comment but it had a typo of my email address. Post this one instead)

    quote: “4. Go to the guys who produce the 50 most used jQuery add-ins – I’m thinking TableSorter and Chosen etc – and help them make all these as accessible as you can. Then write up the experiences so others can learn from them.”

    Our e-commerce sites use a plugin called RateIt. It makes little stars and you can set a rating by clicking on little stars.

    I wanted it to work with keyboard, and then while I was at it, make something available to a screen reader (ideally I wanted also some text for when the image didn’t appear, for sighted image-free users, but didn’t get that far).

    I added crazy stuff to a plugin I didn’t understand (got it working but rewrote lots of stuff because I had trouble reading the higher-end Javascript the plugin writer used), then contacted the plugin writer on Twitter.

    He went right at it, and now there’s a friendlier version of RateIt available– a clickable div became a button, the keyboard is now listened to in addition to mouse clicks, and there’s some extra offscreen text available. He even went so far as to try testing in VoiceOver, while I think he may have known little to nothing about screen readers before I contacted him. He also asked questions.

    That was pretty cool. We just use way too many plugins to do it with all of them. My next stop is probably one of the modal-dialog or lightboxy things. Managing focus is a bitch, but it needs attention.

    Plugin writers who are showing they keep updating their plugins are usually good places to go. They often welcome improvements.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.