By James Edwards

The Angst of Accessibility

By James Edwards

There are many things in the world of web-development that are contentious, controversial, or provoke a passionate response. Some people’s feathers are easily ruffled by talk of legacy IE support, some by whether vendor extensions to CSS are a good idea; for some, you only have to mention HTML5 to get a tirade of exasperated complaints!

But no subject quite provokes the same response as accessibility.

I’ve seen developers get all kinds of worked-up over the how, whats and wherefores of a hundred-and-one different subjects, but it’s only in response to accessibility that I’ve seen anger at the mere suggestion.

So to follow-up my earlier post, The Art of Accessibility, I’d like to consider for a time — just what is it about accessibility that gets some people so inflamed? Why should an issue so clearly rooted in improving the user experience, provoke any objection at all, let alone such a strong one?

Let’s examine a few possibilities.

We all have a job to do

I can’t deny that I’m something of a workaholic, and I have the time to be — I can devote extra time to learning new skills, and practising those I already have, with personal projects and test-cases. But our industry is filled with people who don’t have that kind of freedom, who are far too constrained by time and resources to spend any time at all on things that don’t directly benefit their primary user-base.

It’s my view that providing for good accessibility is a fundamental part of our professionalism. It’s an important part of our job, and if you can’t or won’t give it the attention it requires, then you don’t deserve to call yourself a professional developer. But how do you say that to someone with a family and children to support? Is it any wonder that people would feel affronted by an attitude like mine, when they’re just trying to have a job and provide for their dependents?

Especially when the results may seem purely serendipitous! The main result of good accessibility is a better user experience for people with disabilities, who browse using access technologies, or have specific interactive or cognitive limitations. But are there any such people visiting your site? Probably yes, but honestly, you don’t really know. So why should you spend time and effort catering to a group of users who might not even exist?

I do have an answer to that, and we’ll come back to that later. For now, we can take it as read that the afformentioned issues are a source of chagrin to many jobbing developers, and ultimately, can provoke an angry response.

But such responses don’t come only from this group, they come from all kinds of developers in all kinds of circumstances. So this can’t be the whole story.

Anger breeds anger

There’s no doubt that, in some cases, angry responses are caused by angry proposals. Those developers who’ve invested the most in accessibility, and who are most vociferous in its support, tend to get frustrated at others’ lack of interest. Once you’ve decided for yourself that something is important, it’s understandable to feel frustration at those who don’t share your view.

So we can see how strong proponents of accessibility would get angry at developers who aren’t prepared to consider it at all; I know I have. But that doesn’t really excuse it, because anger breeds anger, and if you get too worked-up about a subject you’ll inevitably provoke a similar response in others. People will get angry at you, because you got angry at them.

Yet even when the proposal is free of all such baiting, angry responses still come; there was nothing at all antagonistic or patronising about my previous post on this subject, but it still provoked those kinds of responses. Clearly, this is not the whole story either.

No, I think the real answer cuts much, much deeper — right to the very heart of what we think of as fair.

What does fair mean?

Politicians are notorious for throwing-around words that sound good, without giving any clear sense of what they actually mean — of what exactly is fair and unfair? In fact they mean different things at different times, because there are two kinds of fairness.

The first kind of fairness is treating people equally. A lottery is an example of this kind of fairness — everyone who enters has the same chance of winning.

The second kind of fairness is treating people unequally to acheive an equal result. The income tax of most countries is an example of this second kind of fairness — as your income increases, you pay not just a larger amount of tax, but a larger proportion of your income as tax.

Catering for accessibility means spending extra time and effort on the needs of a minority, and doing so because that minority is disproportionately disadvantaged to begin with. Even though accessibility is not especially time-consuming, it does nevertheless take more time than the proportion of people who benefit would otherwise justify.

So accessibility is an example of the second kind of fairness — treating people unequally to acheive an equal result — which in other situations would be called positive discrimination.

How positive is positive discrimination?

In my view, the most significant reason why some people object to catering for accessibility, is that it amounts to discrimination, and they don’t think that’s fair.

In broad terms, I don’t approve of positive discrimination, because I don’t think the ends are generally justified by the means. I think there are many inequalities in our society which begin as well-meaning attempts to counter an imbalance, and end by creating a counter-imbalance that’s just as unfair.

But the web in particular, and IT in general, is a special case — because technology is the best hope for accessibility.

It’s not like the physical world, where there are good, tangible reasons why some things can never be accessible. A person who’s blind will never be able to drive a car manually; someone in a wheelchair will never be able to climb the steps of an ancient stone cathedral. But technology is not like the physical world — technology can take any shape; technology is our slave, and we can make it do what we want.

For anyone who’s isolated — such as by disability, geography, mental or physical illness, or the need to care for others — the internet is a life-line. It’s our job and our responsibility keep that life-line strong, because without it, some people would have no contact with the world at all.

That’s why accessibility matters, and why — in my view — it is necessary and justified to spend a disproportionate amount of time and effort in making in better. But I also understand why this is so difficult or impractical for many developers.

I think the best thing that accessibility advocates can do is to step-down from their soap-box, stop preaching so puritanically, and accept that many developers simply can’t meet their expectations. And the best thing that jobbing developers can do is just to try and be aware of the issues, and focus on the quick and simple things we can all do to improve accessibility — write meaningful alt text for images; use headings logically and with an eye to the overall structure they create; don’t use JavaScript to generate primary content.

But most of all, what everyone can do, is avoid responding to bad-attitude with more bad-attitude — it just increases the overall amount of bad-attitude in the air, and that’s not good for anyone.

  • kaf

    A lot of accessibility issues are averted just by trying to stick to certain standards when coding. Thats not an issue.
    But any significant amount of extra work to make a site accessible needs to be paid for by the client. We have to stop treating the sites we build as ours because they are not. They belong to the client and they deserve the option to not spend the extra money on accessibility if thats what they choose. Any thing else is like forcing people to recycle. What gives us the right to force our sensibilities onto others and make them pay for it?

  • Deathshadow

    In a way you are right about the escalation of hostility that can occur — but increasingly it’s like people have no skin whatsoever when it comes to a negative comment… for example, a simple statement like:

    “The absurdly undersized fixed metric fonts are an accessibility /FAIL/ as at the very least the content areas should use a dynamic font via %/em. This is why you do not declare the effectively useless 10px as your font size on body much less paragraphs. Likewise the color contrasts between text and background are well below accessibility norms and in many places make the text effectively invisible.”

    I’ve repeatedly had simple statements like that taken as a personal attack — Where the blue blazes is the personal attack in that? That’s usually when it devolves into the personal attacks when they respond back like Johnny Torch, and I end up in “Christmas on a cracker, grow a ****** skin” mode. Things usually don’t go well from there. You deal with that two or three times a month, you end up in the pattern of just assuming that no matter how you put it people are going to take offense, so screw it… Let’s just say what we are actually thinking.

    Regionalisms play into it too — what’s acceptable speech in New England will have people start screaming profanities at you in the deep south and reduce west-coasters to tears — what’s acceptable behavior in Florida will get your face punched in on the streets of Brooklyn.

    Now, there is a tendency for accessibility advocates to attribute NOT bothering to do simple things like dynamic fonts, fluid width layouts, accesskeys menus and a host of other good practices as being “laziness” on the part of the developer. I know it’s the first thing that enters my mind, which is when I start referring to “sleazing out pages any old way”. I’m guilty of that a good deal…

    BUT — Is it really any more or less “effort” to code the page either way? Repeatedly you’ll have alleged “professionals” out there run their mouths about “target audience doesn’t care”, “it’s too much work” etc, etc, over all sorts of good practices — this isn’t limited to accessibility. Code validation, separation of presentation from content, progressive enhancement so as to maintain graceful degradation, even simple consistent code formatting — all things the people “sleazing out websites any old way” repeatedly badmouth, take issue with, and often say “its too hard” or worse “it takes too long”; when said techniques don’t take ANY longer to deal with — and in most cases not only provide accessibility, but smaller and easier to maintain code that takes LESS time to write!

    It’s where I LAUGH at the idiotic markup from things like WordPress — as if somehow more code, redundant code, and bloated code is EASIER to maintain and learn to work with? Gahugafugah?

    But then I suspect this is why I can usually take something some other developer has been struggling with for weeks that’s a disaster ignoring all of the above, throw away ALL of their existing code and belt out a more accessible work-alike in the time it takes for Domino’s to deliver a pizza.

    As such, the “lazy” aspect isn’t what’s going on. I’d blame it on ignorance, but once we’ve told them what they’re doing wrong and they keep on doing it…

    When it’s not laziness as if they put in the effort to practice it development is actually EASIER, it’s not ignorant because they’ve been told hundreds of times, that leaves only one thing… stupidity.

    Or web rot — JHVH knows 90% of the websites out there and books on shelves on the subject of writing HTML need to be removed for having their head permanently wedged up 1997’s backside…

    Which explains a LOT about the HTML 5 specification.

    • Claire

      A little bit of tact goes a long way in situations like this.

      Deathshadow, you say “I’ve repeatedly had simple statements like that taken as a personal attack — Where the blue blazes is the personal attack in that?”

      The answer is that your statement (2nd paragraph) contains words that are usually considered judgmental — “absurdly undersized”, “effectively useless”. What you are saying is true, but by saying it in that manner you convey the implication that “you are a doofus for even thinking of putting something like that in your code.” So yes, it is a personal attack — or could be construed as one.

      If you were to say the same thing tactfully, in a way that implies you are simply reminding them of something they already know and planned to do anyway, you are far more apt to get people to respond with cheerful compliance. And I think that was part of James’s point.

      • I agree, Claire.

        Deathshadow, I wonder whether you even got the entire message of this piece. The sentiment that James ends with here is applicable not just to discussions about accessibility, but also about standards, favourite video format, my-CMS-can-beat-up-your-CMS, Mac-vs-PC platform wars, and all the other hot topics for righteous nerd rage.

    • Cliff Tyllick

      As Claire and Raena have said, Deathshadow, wording your comments gently will go a long way towards getting them accepted.

      I share your frustration. But which is more important: to show that frustration to everyone, or to get people to understand that creating accessible content and apps is often *not* more, but *less* work?

      As you correctly put it, “[S]aid techniques don’t take ANY longer to deal with — and in most cases not only provide accessibility, but smaller and easier to maintain code that takes LESS time to write!”

      To that, I would add that the resulting content takes less effort to curate and is far easier to reuse in other settings.

      But to make that happen, I have to back off from my anger with the status quo and even from expressing general principles. What works is to calmly show customers better solutions to their problems — solutions that also happen to be highly accessible.

      You are right — creating accessible content and apps is in our customers’ best interests, and almost always without even having to consider the ramifications for people with disabilities. As important as those ramifications are, don’t let a debate over them get in the way of helping a customer do what’s best for everyone.

      To sell it to your customer, focus on the benefits the customer will appreciate. Just like Mom got you to take your cherry-flavored cough syrup by gently pointing out that it tasted good, not by telling you that it was utterly ridiculous of you not to want to take medicine that would cure you of your deplorable condition.

  • PeteW

    Very nice, balanced post James. I particularly like your conclusion, which shows that there is a third, more ideal form of fairness – that which comes from combining “Do as you would be done by” with “Moderation in all things.” Thanks for being a voice of reason. :-)

  • Tommy Olsson

    Yes, the developers who need to make an extra effort are people with families to feed and clothe.

    Those who are hindered, shut out and made feel unwelcome if the developers don’t make this effort are also people, and may have families to feed and clothe.

    We don’t put in extra work for the benefit of screen readers or suck/blow interfaces; we put it in for fellow human beings. That’s the important thing to remember.

  • Marjorie Clark

    I’ve always looked at accessibility as best practices for web development because search engines are blind. Clean code and labels on everything are good for everybody and every bot.

  • lori

    So this is all great, but what would really be useful is if you could list the right books and articles to guide developers who would otherwise “sleaze out pages” mostly because of ignorance? Thank you.

  • AnilG

    “I do have an answer to that, and we’ll come back to that later.” I presume you mean in a later article, because I can’t see an answer to that question in this one.

    Deathshadow mentions ignorance of techniques as a cause of lack of accessibility in sites but correct me if everyone thinks that implementing accessibility doesn’t take significant extra effort.

    It would be fair to include in the definition of professional developers a list of non-sleazy good coding practices that increase reliability, reduce maintenance costs and even reduce development time, but James’ made the point in his last article that it has “taken years” and “a great deal of time and hard work” (I quote) to get to the point where he is able to implement accessibility “features” (we’re not allowed to call them that).

    kaf makes this point too (although a lot quicker than I am doing here).

    It’s not “fair” to define “professional developers” in terms of whether they include accessibility features for the following reasons:

    1. Developers who implement accessibility in their own time, without charging the client, are amateur developers, since they are not being paid.

    2. Developers who implement accessibility during development and charge for the time it takes without mentioning the additional cost to the client, are defrauding their clients and can hardly therefore be called professional.

    3. Developers who implement accessibility, paid for with the agreement of the client, presumably have an audience that includes accessibility needs. Great! But why do developers working on projects without those needs somehow become “unprofessional”?

    The real point remains, as kaf again points out, that what is implemented for a site continues to be the choice of the client who pays for it. It’s up to the client to decide if their target audience includes accessibility needs, and even if it does, whether it’s cost / effective to provide for the fraction that does. If there’s a point to be made about accessibility it needs to be made to the clients, not the developers.

    For many intranet corporate sites there is no such audience and for many public sites the client may already be struggling to justify the cost of the site in the first place. Don’t be surprised if a 5% increase in cost for an audience fragment of 0.01% doesn’t actually work.

    I’ve believe I’ve seen some anger and ‘holier than thou’ ‘attitude’ from the “accessibility crowd”. There’s a lot of space used on the question of ‘anger’ in this post. Personally I’m not angry about it at all, but in all these posts I’ve yet to see the real question actually focussed on and answered.

    At least in this article James’ mentions the question is there. How about an answer in the next article? How should accessibility implementations be paid for? Government grant to developers? Pay me for my time to go on accessibility training? Government subsidies to companies commissioning web sites to include accessibility “features”? Charity begins at home (an /amateur/ initiative)?

  • John Foliot


    “Developers who implement accessibility during development and charge for the time it takes without mentioning the additional cost to the client, are defrauding their clients and can hardly therefore be called professional.”

    There is a fundamental flaw in this statement that I think needs to be examined. And that is that accessibility in web development should not be considered a “feature” or an enhancement that costs more, it should just be part and parcel of how a professional does their job. Cutting corners to save a few dollars is not very professional: how would you react if your dentist reused their latex gloves to save some money, or your car mechanic didn’t bother checking the correct torque tightness of bolts on your car, as it takes longer, requires additional equipment, and thus adds to the cost of having your car serviced? Many clients aren’t up to speed on what ‘accessible web development’ means, or how it may or may not affect their final product – that’s why they hire professionals to do the work: they depend on the professional they hire to be, well, pros.

    As long as developers continue to work with the mind-set that ensuring accessibility is something *extra* they need to do, they are pretending to be professional, but they really aren’t acting professional. Is working to ensure your web content is accessible really any different than checking your web content in various browsers, and even platforms? You wouldn’t deliver a ‘finished’ project that didn’t render properly in Safari on Mac would you? Yet somehow if it doesn’t work for users accessing the same content with Adaptive Technology, somehow that’s OK?

    I just don’t understand that.

    • AnilG

      If a mechanic doesn’t tighten the bolts the wheels fall off, but if he’s going to charge me an extra $100 for a cardboard car freshener I’m going to tell him to skip it.

      Why is delivering a project that doesn’t render in Safari different to delivering a project that doesn’t work for adaptive technologies? Because my client told me that 20% of his users use Safari and 0% use adaptive technologies. For him extra work on adaptive technologies isn’t even as good as an air freshener.

      This is the same regular paradigm that is normally applied to browser testing, or am I wrong here again? Does everyone still test in IE5 because the single user who actually still uses IE5 is really worth the extra time?

      I think for this “not a feature” idea to float we have to be sure that accessibility does not take significant extra time. Otherwise why should I force my client to drop features that he does want in order to keep the accessibility he never asked for?

      I’m trying to understand accessibility as “not a feature” John, but opinions seem to conflict about whether it takes significant extra time or not.

      • John Foliot

        Does doing a good and professional job take longer than a slap-dash crappy job? Yes. If time = money then does doing a good job cost more? Yup. You’ve identified a truth – sorta.

        But here’s the deal: as many others have pointed out, the majority of what you need to do to ensure accessibility also has additional benefits that you client gains, like better usability, better SEO, and well, happier users, which means your client shines, and you shine.
        But if you’ve never worked on a project that required you to think about ensuring accessibility, well that will take longer too, as you need to learn as you go. But that extra time, the “cost” of that extra time, should be a cost borne by you, not your client, as it is an investment in your career – it’s skills training that will serve you well across all future projects, not just the project you are working on today.

        Creating accessible web sites is a mind set, it’s a way of doing things, it’s an approach that you as a developer should adopt because it’s a good thing to do; it makes you more marketable as a developer, it builds goodwill for your clients, and thus you as well. Once you acquaint yourself with the basic principles and have spent a bit of time learning about what creating accessible content really means, you will come to find that in the grand scheme of things, ensuring accessibility is no more complicated or time consuming then optimizing images for faster download, or looking to minify your JS and CSS for faster page loading: if you do those types of things now, do you ‘charge extra’ for that, or do you do those things because you’ve learned that they benefit your clients, even if they have no idea what minifying JS and CSS even means?

        Working towards WCAG 2 isn’t something that should be seen as a ‘feature’, or something that should be approached as scary or onerous, but rather a best practices attitude that you as a professional simply adopts, because you know instinctively that doing those things makes you a better developer. If you love what you do (and most of us in this industry do) and you are proud of what you do, then why would adopting these ideals be considered ‘costly’?

    • AnilG

      Thanks, John, but I’m just hearing more of the same.

      I’ve quoted James’ earlier article where he uses the phrase “years of hard work”. In this article he poses the question “So why should you spend time and effort catering to a group of users who might not even exist?”. No-one has actually answered that question and I wonder if they ever will, but it’s still clear he thinks meeting accessibility needs *does* take extra effort, *and* accessibility needs is provision for a disabled audience, *not* a raft of benefits that other users will also appreciate.

      You’re trying to tell me, and certainly other posters also argue that accessibility *doesn’t* take years of hard work, or any extra effort. Some are even arguing that accessibility has nothing to do with the needs of disabled users!

      So it’s a little unclear what we’re talking about and whether indeed it takes effort or not.

      You say “a professional job takes longer” but you’re moving the goal posts. We weren’t talking about “a professional job” we were talking about “accessibility needs”. Can someone clarify whether “meeting accessibility needs of disabled users” requires extra effort or not? And still, it it does, why should I force my client to pay for it if his audience doesn’t have those needs?

  • Deathshadow

    You know, I’m looking at some of these responses, and something occurred to me…

    MOST of the “good practices” mentioned involve NOT doing things. Let’s cover what I consider the top miserable /FAIL/ures at web design… Mind you, my disgust is already boiling over on this because IT’S SO MALFING SIMPLE!!!

    1) using PX for fonts. DON’T!!! The ONLY time you may be ‘forced’ to do this is when you have a image interaction, in those cases just make sure it’s 14px or larger so large font/120dpi users aren’t COMPLETELY BONED by your putting PX on there. It’s that simple – don’t use PX on content. Thats it… Don’t declare fonts in px on body, don’t declare px on fonts on your paragraphs — as the WCAG says, used %/em so it automatically resizes to the system metric. HOW HARD IS THAT?!? (lands sake even PT is superior in that regard as at least it obeys the system metric!)

    2) Using images for text with no images off fallbacks. DON’T!!! For small items like buttons, image replacement techniques like Gilder-levin exist for a reason; USE THEM… for large sections of body text like your actual content — you may actually be expected to *SHOCK* USE TEXT?!? OMG you mean we might actually have to use text for a page full of text?!?

    3) Non-semantic markup… DON’T!!! Is it REALLY that hard to put heading tags around *SHOCK* headings in a logical cascading order?!? Paragraphs around actual PARAGRAPHS (A sentence or more) instead of omitting them for double breaks or worse, putting them around non-paragraph elements? LABELS in your forms? List around *SHOCK* lists? That’s basic HTML and people can’t even seem to manage that correctly!!! OMG, not that!?!

    4) Color contrasts below norms… DON’T!!! White on grey? red on blue? Dark grey on black? #888 on #777? Is 50% luminance (using the additive formula and not the subtractive) REALLY so hard to remember?

    5) Using flash for text content and to handle site navigation. DON’T!!! People using flash-limited devices (iPhone/iPad much) will get nothing, it breaks normal site navigation via forward/back, prevents direct linking to your subsections that on a REAL website would be separate pages, and is a bandwidth/resource hog. Leave flash for what it does well — Video playback and games, and stop using it for everything else.

    6) Crappy little stripe or too big for the display fixed widths. DON’T!!! MAYBE it’s just me, but I never found coding to fixed widths easy to do (you waste so much time checking that everything fits and calculating values). Fluid or semi-fluid layouts are generally simpler to create once you wrap your head around the concept of “Wait, we can have columns change size?” — It’s pretty easy to go min-width, max-width… and the new media queries to target small screen aren’t exactly rocket science. To me, fixed width layouts have ALWAYS been a miserable failure not only from an accessibility standpoint, but from a web design point of view as well.

    The kicker of what I consider the top five, is the top four are things that are easily enough avoided by simply NOT DOING IT… They should be part of how every developer builds a website, and if you are NOT practicing those, that is NOT professional grade work. Those are SIMPLE things that take NO extra effort to implement, Some like #3 result in smaller code and/or better caching, and frankly the mere CONCEPT charging extra for ANY of those that is one of the SLEAZIEST things I’ve EVER heard — as failing to follow those means you have no business CHARGING for your work in the first place!!!

    Accessibility isn’t something a website should ever “not need” — and frankly the mere notion of omitting it is where I’d be pointing the finger so far as “defrauding the client” goes.

    I mean really, how hard is it to NOT use PX, NOT use images for text, NOT use color combinations that are illegible, NOT use flash, and NOT use fixed width? Last time I checked, NOT doing things is easy!

    The only one that really isn’t a “not” as there might be learning involved is #3, semantic markup. Frankly, if you don’t know the HTML tags and don’t know how to use them properly, WHAT BUSINESS DO YOU HAVE SELLING YOUR WORK TO OTHERS!!!

    Which is why every time I see the idiocy of a paragraph with class=”heading” with bold tags inside it, I feel the need to backhand someone. If you don’t know what’s wrong with the code I just described, do the world a favor, back away from the keyboard, and take up something less detail oriented like macramé weaving.

    • Andrew

      Being totally blind and using a screen reader, I am part of that supposed tiny percentage who benefit from “the extra effort of building in accessibility”. Deathshadow is right – the vast majority of accessibility issues arise due to poor coding. It is so often the case that when I complain to a sighted friend about a website’s poor accessibility, their response is that it’s hopeless for them as well. All this extra effort for providing an accessible site is a bit of a misnomer. Colleagues will discuss for vast quantity of staff hours what colour something should be – not to make something accessible but to impress the visitor. While there are exceptions, the vast majority of people visit the vast majority of websites not for the uplifting experience but to get information. When website developers and owners grasp that, the cost of development will plummet and all in the known world will benefit.

    • Darkwater23

      I see the truth in your responses, but I can’t help but giggle at you. The article made points about how to discuss this issue and that ‘anger breeds anger’, etc. and you seem like you’re losing your mind!

      I’m a professional web developer myself and I can remember when I as annoyed at accessibility because accessibility was not in the tutorials and example I read online. I learned how to do mark up incorrectly, basically. I made sites that were well designed (graphically) and rendered well for visual users using popular browsers, but then I’d read a post like yours an and come away with “Nice try, but WRONG!” That was very frustrating.

      Now, accessibility is just the way I code. It’s not a line item on the bill, it’s not an extra cost, it’s just how I do it. I write the very best mark-up I can for SEO, accessibility and it looks good, too.

      In truth, what messed me up in the beginning was the graphic design firm that my first employer partnered with. They were the ones that wanted 10px fonts. I’ve worked on more than one design that really hard to do “right” because the designed was thinking more along the lines of print work than web work.

    • kaf

      What do you have against fixed width sites? Thats just weird. I just don’t see how thats an accessibility thing. Most sites are fixed width as its the only way to ensure consistent design and positioning of elements across pages. Different sites lend themselves to different methods. eg Amazon is best as fluid layout because they are trying to fit as much crap on the page as possible. Whereas Sitepoint has fixed layout because it provides more consistant layout and design and less visual adjustment across pages.

  • graphicus

    The spread of repsonses here illustrate neatly the truth of the original article. Deathshadow asks “where’s the blue blazes is the personal attack?” in his comments which include words like “absurd”, “useless”, and “FAIL” in unnecessary shouting caps. The immediate move to expletives as soon as anyone takes exception is revealing too. Criticism should be calm, factual and professional no matter where in teh world you live.

    But on the issue of substance: it is true that those who are paying the fees set th eterms of refernce. If I am working for a client in a very niche engineering market they are going to say that they don’t have deaf/blind clients. But the breakthrough comes when yo stop beating them over the head with a stick and simply point out that writing code for accessibility is effectively the same as writing for SEO. A robot is essentially a screen reader, and Google, among others, increasingly reward well written code and content constructed for accessibility norms. So it always pays to follow best practice in the long run, no matter what your target audience.

    It all depends on whether you are really interested in communicating or just bad mouthing other people.

    • Cliff Tyllick

      Yep. And, by the way, at Google’s last check-up, what did the optometrist say its vision was? And how was its hearing? ;-)

      In other words, just in case clients don’t get the point about robots essentially being screen readers, it might work to point out to them that their greatest ally in getting people to their website is blind and cannot hear.

      So, if their information isn’t accessible, Google won’t be able to be that potent ally.

      For some customers, you might not even mention the accessibility that you’ve built in until they call you again with concerns about complying with a law.

      And you’ll be able to tell them that the code you wrote that improved their SEO also happened to make their site reasonably accessible. And, if they have any specific use cases in mind, that you would be happy to review their site from that standpoint just to be sure that code that *should* support accessibility actually *does* in that particular case.

      • It’s totally not correct to say that “a robot is essentially a screenreader”. Robots and screen-readers are not the same thing at all, and you can’t cater to one and expect to satisfy the other.

        A robot doesn’t parse CSS or JavaScript, and reads your page by processing the source-code.

        A screenreader does parse CSS and JavaScript, and reads your page from the rendered output. Although it does dip-into source meta-data in places (like reading the ALT text of images, if so configured), for the most part, what a screen reader sees of your page is no different than what you see.

        Think of it like somebody looking at your page in another room, then reading it out to you over the phone. That’s a far closer analogy than comparing it to a robot.

  • Kate

    I think one of the problems is that people are talking/treating “coding for accessibility” as something separate; an extra activity that adds a specified cost.

    If you simply treat it as “the way you code” then it is integral to what you do and deliver; it’s part of the basic package.

    In terms of where to learn and read up… there are lots of excellent sources available at the end of a quick search. Some I’d recommend are: , , and of course SitePoint ;-)

    • AnilG

      I think this point is central to the question. It seems that some view “accessibility” not as something that provides benefits for disabled users but as something that has value for all sites. If so, fine, let’s stop calling it “accessibility” and call it something more appropriate like “quality” and we can then happily harangue “sleazy” developers who don’t use it. The way we all code should always be “quality”.

      However, the author of the article says that “accessibility” is something that requires extra effort solely to provide benefits that accrue to disabled users only. Ok, in that case let’s call it “accessibility” and in order to prevent additional unnecessary costs to our clients we can hope that “professional” web developers will ask their clients if they have a disabled audience before spending the extra effort.

  • Anthony Rose

    Your ‘second kind’ of fairness is not really *fairness*, as you seem to acknowledge, but giving, loving, caring. As such it is good and right to do, but must remain voluntary, otherwise it becomes unfairness: taking someone’s life (time), liberty (choice) or property. No one has the right to repair their misfortune at the expense of others by force.

    As it is a charitable motivation, you can inspire people into it, but you cannot force them into it.
    Grab the imagination, not the rule-book or the uniform. Like, personal stories of people helped by accessibility.

  • Mexican Red

    Thank you James for a great article.

    I try to stick to W3C guidelines wherever possible and always explain the importance of accessibility to my clients. I don’t give them the option of having a ‘non-accessible’ site.

    I also explain to them that the very practices required to make a site accessible to people with disabilities, also make the site more accessible to the search engines – this usually gets them on board.

    And I charge for all of my time spent on a project.

    There is always compromise in this business. At the end of the day the most accessible website will be plain black text on a white background with no pictures! Nobody wants that. The important thing is to try and stick to the guidelines and give every user the best experience as possible within the constraints of the brief.

    Yes it’s hard learning new stuff all the time, but when I’m sick of learning (and I am quite certain that day will arrive sooner or later), I guess I will go and do something else. There are so many good resources out there on the web nowadays – Sitepoint is one of them, and there are many more if you do a quick search.

    Get involved with other developers, discuss, exchange ideas and techniques – this is how we move forward.
    The question shouldn’t be “Why should I make this site accessible?” – the question is “Why not?”.

    • AnilG

      If the question is “Why Not” then the answer is “because it will cost my client more for something he doesn’t need”.

  • Interesting discussion. Here are my thoughts:

    1. Accessibility is not about blind, deaf or disabled users. It’s about ensuring your site works on a broad range of devices — whether that’s Chrome 11, IE3, a mobile phone, the Googlebot, or a screen reader. It’s impractical to test everything but most accessibility recommendations are common sense.

    2. Accessibility should not be sold as a bolt-on extra. (Neither should SEO.) They are simply good practices. You’re being hired for professional expertise; most clients don’t know or care how it’s completed, they just want the project delivered on time and on budget. If they want it quicker/cheaper, you can remove features … accessibility is not a feature.

    3. If you require considerable extra time for accessibility, you probably misunderstand it. If you have no interest in evolving your skills, that’s fine — but you’ll be competing against novice agencies charging $99 for non-accessible sites developed in FrontPage Express.

    • Julie Romanowski

      “…most clients don’t know or care how it’s completed, they just want the project delivered on time and on budget.”
      And most clients assume the product will be accessible to the largest group of users possible.

      • Clients make lots of assumptions but, in my experience, accessibility doesn’t cross their mind unless they’re educated about it.

        Most people don’t know what a browser is. They’re not aware of competing applications, so they certainly don’t consider the implications of search engine bots, screen readers or other devices.

        That’s why you’re being hired.

      • You’re both right. Unaware clients don’t think about accessibility, but at the same time they really do assume that everything’s OK until they’re shown how this might not be the case.

      • AnilG

        In my experience they just want the site delivered in the shortest possible timescale. Their schedule is already unrealistic. If I can deliver 8 hours earlier by dropping something they don’t need, they’re interested.

        They’re not at all interested in “the largest group of users possible”. They usually have a specific audience and if I start doing something out of scope that takes extra time they’ll be asking me why.

      • Julie Romanowski

        I should have been clearer in my reply. When I wrote “most clients assume the product will be accessible to the largest group of users possible”, I meant for the audience they are targeting. Clients typically would not know if anyone in the target audience has a disability, and even if they knew that no one in the target audience had a disability, there is no guarantee that someone will not develop a disability in the future.
        In my experience as an accessibility consultant, when developers tell me the client does not care about accessibility, they really mean they have not talked to the client about accessibility. I have yet to talk to a client who does not care about accessibility after I have explained the issues to them.
        When meeting with clients, I ask them who their audience is and what they want the user to accomplish with their site/application. They may want the user to be able to do A, B, and C in order to purchase product D. I have never heard a client say something like, “The user should be able to do A, B, and C to purchase D, but only by using a mouse. We don’t want the business of those keyboard-only or screen reader users.”
        As others have mentioned, education is key. If people do not understand why accessibility is important, then they will continue to think of accessibility as a feature instead of a requirement.

  • Ralph

    As others have said, making sure your web pages are accessible is not an extra task, but rather a way of going about your work. It doesn’t take much to find out how to modify your modus operandi to account for accessibility issues. Just take Deathshadow’s 5 pointers for starters.

    Adding to what John Foliot pointed out above, it seems web development lacks a recognized benchmark for professional practice. It’s strange to be making excuses for inaccessible, spaghetti code. When an earthquake hits and we see buildings tumble down that really should have stayed standing, we shake our heads and expect those responsible to lift their game; or we sue the negligent dentist, or confront the dodgy car repairers. Less often to we see the personal disasters caused by inaccessible code, so it’s a problem more easily ignored.

    I’m striving to get a better grasp of accessibility. Why? Not because clients ask for it, because I haven’t found one yet who cares in the least. But I do value the idea of the web being accessible by all, and want to be able to create something I can take pride in, too. Otherwise I have no right to criticize others doing substandard work.

  • AnilG

    So accessibility is “a better user experience for people with disabilities” but also “not about blind, deaf or disabled users”.

    Also accessibility does take “time and effort” but it is also apparently “malfing simple”.

    How about Deathshadow is commissioned to write the next Sitepoint tutorial on accessibility?

    • Many people equate the term “accessibility” with blind users. They’re a subset but the implications have a wider reach.

      Most clients are concerned with the look of a website. You don’t require technical skills so anyone can have an opinion. In that respect, the needs of blind people don’t seem important.

      However, what if you tell them that their content can’t be indexed by Google? Or perhaps 10% of users can’t access the site? Accessibility then becomes a far more important issue.

      You could consider dropping the term “accessibility” when meeting clients. Perhaps refer to it as “wide-ranging device access” or similar.

      • AnilG

        Thanks, Craig. I wonder if you’ve noticed that your point directly contradicts what the author says about accessibility?

        He says “The main result of good accessibility is a better user experience for people with disabilities, who browse using access technologies, or have specific interactive or cognitive limitations” and “why should you spend time and effort catering to a group of users who might not even exist?”

        James seems to be talking about specific coding work that requires additional effort only to target disabled users. You are talking about generic coding practices that benefit all users and site owners as well.

        These are two very different things and of course therefore have very different implications. After two articles and a lot of discussion I’m surprised we haven’t yet defined this difference with two different terms by now.

        Would you agree it’s more appropriate to call your general coding practices “quality” instead of “accessibility”? Would you agree it’s very important to clear up the difference here?

    • With respect to time and effort, anyone who’s spent months or years practicing accessible techniques will do it automatically and it won’t take extra time.

      Those new to accessibility will struggle more and it doesn’t seem as vital as, say, learning HTML or CSS. All I can suggest is that you investigate accessibility at the same time.

      • AnilG

        I am certainly very interested in doing all I can to build efficient robust maintainable code that meets the directly stated needs of my client with the minimum of development time. That’s normal. I do investigate that and hopefully will continue to do so. I just don’t see why I have to start talking about disabled users when I do so?

        This is like the elephant in the room. Is there some politically correct thing I just don’t get? Why is it so hard to answer:

        1. Are we talking about (A) benefits specifically and only for disabled users OR (B) general benefits for a range of users?

        2. Are we talking about (A) specific additional effort to obtain those benefits for disabled users only OR (B) disabled users getting benefits as part of the general benefits at no additional time/cost?

        From the arguments posted here it really seems like the answers are both B so I just don’t get why everyone has to pretend they’re doing something special for disabled users.

  • Vlad Alexander

    >accept that many developers simply can’t meet their expectations.

    That is a symptom of the problem. The question is why can’t expectations be meet? Is it because browser/tool vendors don’t make it easy for Web developers and content authors to ‘see’ how alt text is actually used? Is it because large app vendors set the bar by using bad practices such as using JavaScript to generate primary content? Is it because designers of HTML5 introduce inaccessible features such as canvas and make other accessibility features optional?

    I don’t think accessibility advocates get angry at website developers. I think the anger is directed at large companies that build browsers/tools or set trends that make it more difficult to build accessible websites for developers.

  • Sphamandla

    I think positive discrimination is a good thing but only to A certain extend, I mean its only makes sense for those with very high income to pay slightly more than the average to try and balance equality among the population.

  • graphicus

    “Most clients are concerned with the look of a website. You don’t require technical skills so anyone can have an opinion.”

    That’s an all too common misconception about visual design. Fro sighted people, who will always be the majority of users, color, placement and visual hierarchy and context are key factors in the communication of information. These are not just matters of opinion, they are based on extensive field testing with laser tracking of eye movements, user responses and actual conversion rates.

    This does not mean that we should ignore the needs of other users who need to access information in other ways, but visual layout is not just a matter of taste and aesthetics – it is also a matter of accessibility. The real challenge is to ahcieve a page and site coding that can adapt to the maximum number of available machine devices and human needs.

    The basic of doing this are well established and should not take extra time because, as others have pointed out, it ought to be the way you work anyway. But it is always going to be a moving target as new devices and possibilities come on stream. However, lets’ not return to the old coder v. designer nonsense of dismissing visual layout as just unnecessary concern with “making things pretty”.

    • I hope my comments didn’t come across as dismissing visual layout. I’m saying that, to most clients, the visual layout is everything. It’s often subjective so everyone gives their opinion. They rarely know or care whether it’s coded using best practice techniques because they’re a sighted user with a modern browser.

      Most people are blind to accessibility concerns. They’re unlikely to change their attitude unless they understand the impact accessibility has on sales, i.e. poor SEO and user restrictions.

      • Cliff Tyllick

        Craig, you’re on target. Often, clients think that because they can see they know everything they need to know to make a decision about visual layout. It’s much like anyone who has been to school thinking they’re an expert on education or anyone who has ridden in a car, bus, or train thinking they know all the answers to urban transportation problems.

        I’ve found the mobile phone and, now, the tablet to be my strongest ally in convincing people that they need to make their content accessible. They need their code to support the display and retrieval of their information in whatever format their customers consume. And in this rapidly developing medium, the best chance you have of achieving that goal is to create content and apps that also happen to be accessible.

  • KiwiJohn

    To those who suffer “angst” over the poor accessibility standards of others I ask, what is your minimum criteria that must be met in order to avoid that angst?

    Conformance with WCAG2.0 Level AAA?
    Conformance with WCAG2.0 Level AA?
    Conformance with WCAG2.0 Level A?
    Deathshadow’s 5 points?

  • Bruce

    By the time I have built a site that works across browsers, works on mobile devices, and works for older readers (with both money and less-than-perfect eyesight), and assuming I have done that by good coding rather than a collection of hacks, the great majority of accessibility issues are already dealt with.
    As others have said, do it right for all the above ‘valid’ reasons and accessibility is a free benefit.

  • Lynn Holdsworth

    Someone asked me yesterday for an example of an accessible UK ecommerce site. Two years ago I could have reeled off four or five, but now I can’t find a single one.

    My supermarket has just launched a funky new site, and it now takes me 3 hours to do my food shopping where it used to take 1.5. I thought things might be better on the iPhone app, but the product images don’t have alt text so I can’t use it.

    The clothes shopping site I’ve used for years has employed a funky mouse-driven drop-down menu where there used to be a select box, so now I can’t choose a clothing size.

    What ho, I’ll now have to pay someone to go to the supermarket and clothes shop with me. And all because a bunch of developers couldn’t (be bothered to?) learn to program properly.

    Your work is affecting people’s lives. As a blind user and a developer, I know how frustrating, but also how rewarding, it can be to get accessibility right.

  • xzyfer

    @Craig, personally being a big fan of the site point course, now learnable, could I suggest developing such a course outlining accessibility best practices? This is something I would be very interested in.

    I feel as though accessibility is one of those things a lot of people think they know about but either mistaken or lacking in knowledge. Although I try to follow most best practices, I can personally say that I wouldn’t be comfortable saying I knew the cruxes of accessibility.

  • kaf

    This is a weird discussion. Most of you seem to be arguing the same point. The main disagreement seems to be about what accessibility is!?

    I have to say I’m confused. A lot of you are talking about semantic and standards compliant code as if thats an accessibility thing?! WTF! Thats just a good practice thing, and if it happens to overlap with accessibility then thats besides the point. To me accessibility is any extra work.

    For example one client wanted me to add text plus and minus controls on their site. That is an extra and they paid for that.

    Another one is text failovers for images that are text. We’re only obligated to put in alt text in this case – as is the standard. Anything else and the client has to pay for it.

    If all you mean when you say accessibility is standards compliant code then why don’t you all just say that so we can avoid these useless discussions?

    • HTML was designed to be accessible, and so — yes, if you write compliant pages, you’re a big part of the way towards building an accessible site. But it’s not the whole story. For example, an image will be valid if its ALT text is “foo bar insert text here”, but that’s not exactly accessible is it? It doesn’t serve the same function as the image, which is what ALT text should do.

      Your example of text-size controls is not actually a great one. Such devices are not considered good-practice, because they undermine the browser’s native control over font-size. It’s better to apply fonts that are natively resize-able by the browser’s own controls, so that users have a consistent mechanism and don’t have to look around each new page for a unique, site-specific way of controlling it.

      • kaf

        So it sounds to me like we are more or less on the same page.

        As I work with a CMS it’s not really my responsibility to make sure images have relevant alt text. My CMS allows the content manager to add all of the relevant meta data (such as description) for an image asset when the image is uploaded, and my CMS automatically puts that description in the alt text.

        As for the text-size control example. I agree. Not good practice. But then the client asked for it….

    • AnilG

      That’s the precise point, kaf. I agree. Can we please use a more appropriate term for “accessibilty”? or can someone admit that generic useability and good coding practice provides all the accessibility that disabled users need anyway?

      And *if* that is the case then why is everyone pretending they’re doing it for the disabled users like some kind of charity? Why all this talk about “extra effort” for disabled users?

  • Thanks for all the comments. Some excellent arguments have been made, and I don’t think there’s a great deal for me to add. I’d just like to summarize what I think are the most significant details.

    If you’re in the position of never having had to consider accessibility in any of the sites or applications you’ve developed, then it is going to be some work for you, to shift your experience and mind-state. Learning the skills and techniques necessary to build decently accessible sites WILL take work and effort; perhaps equivalent to the effort required to convert from table-based to CSS layouts; perhaps less than that, it’s hard to say. But YOU have to cover the cost of that, because it’s an investment in your career, and it’s not reasonable to make clients cover the cost of your learning curve.

    But once you’ve acquired those skills, the effort and cost required to implement and maintain them is minimal. And in that situation, it is indeed your clients who pay. The analogy that John Foliot made is spot-on — you don’t consider it excessive to spend time minifying your scripts and stylesheets, and you don’t necessarily itemize that in the bill you present to clients; you do it because you know they will benefit, even if they don’t actually understand what it is you’re doing.

    But building accessible websites is NOT significantly more expensive or time-consuming than building inaccessible websites, once you have the skills. And this is why accessibility is not a feature — it isn’t that you musn’t refer to it in that way, as though the word “feature” were insulting; it’s simply that accessibility ISN’T a mechanical feature, any more than tabs and line-breaks are a feature of CSS, because the things we do to ensure good accessibility are INDIVISIBLE from the underlying process.

    When you look at a PSD and think about how to write the markup — is your thought process a feature of the implementation? Do you charge clients extra for the fact that you had to think about it at all? Of course not! You write the best semantic markup you can. You write lists using <ul> instead of a two-column table with graphical bullets. You break-up long chunks of text into paragraphs, instead of one big <p> with lots of <br/> in-between. You write your headings as <h1> and <h2> instead of <p class="heading">.

    Simple examples, yes, but ultimately, THOSE are the kinds of decisions that make the difference between an accessible and inaccessible site. Accessibility is not a feature, it’s a process.

    The last thing I want to mention is the point about browser-share and audience size — if we don’t cater to IE5 because of its tiny audience, why should accessibility, with an even tinier audience, be any different? Well, the difference comes down to CHOICE.

    People who surf with IE5 have made a deliberate choice, to continue using that browser despite the existence of better, and free, alternatives. There’s no reason why we should spend time and effort catering to the whims of a stubborn minority; they’ve made their choice, and they must take responsibility for it.

    But people with special accessibility requirements have made no such choice; they didn’t choose to need a screen-reader, didn’t choose to be blind, or to have limited mobility, or whatever else it is that makes it difficult to access resources. They had that choice thrust upon them through no decision of their own.

    When I read comments like those of Tommy Ollsen and Lynn Holdsworth, I can’t help but feel humbled; and I honestly don’t understand how anyone can NOT feel that way. We’re talking about real people, real human suffering, and we have the capacity to help alleviate that suffering, in a small but significant way.

    And so I started this post trying to reach-out and sympathise with developers who are constrained by logistics or resources and find it difficult to implement accessibility. I’ll help anyone I can to improve their skills and do things better — and all I ask in return is the motivation to try. You don’t have to tick every accessible box that exists; you don’t have satisfy a particular number of “A”s to get me on-side; you just have to make an effort, to WANT to do things properly.

    If you’re not prepared to make the effort — if you know the problem exists but you just don’t care — then you don’t deserve to call yourself a professional web developer. HTML was DESIGNED to be accessible, and to ignore that is to ignore the intent of its creator and undermine its purpose. Making inaccessible websites is like fuelling your car with vodka — it may go, but only at the cost of a cloud of black smoke and fundamental damage to the engine.

    In fact, in my opinion, if you’re not prepared to make the effort, then not only do you not deserve to call yourself a professional, you don’t deserve to call yourself a human being.

    • AnilG

      I don’t understand how you can summarise with “there’s not much more to add”, James, when there are such obvious contradictions in the assumptions of the various arguments made. We haven’t even got an agreed definition of what “accessibility” is.

      My own conclusion is that most posters are talking about generic quality coding practices that benefit a wide range of users and are appreciated by their clients as reaching an additional audience of around 10% (Craig Buckler). It seems that no-one is spending significant additional effort just to reach a fractional percentage of disabled users.

      Meanwhile the final line of your conclusion very carefully massively insults a group of web developers that may only be confused about what on earth everyone is talking about.

      If there was “there was nothing at all antagonistic or patronising about [your] previous post on this subject” I think you’re going to have great difficulty arguing that about this one.

      You haven’t answered your question “why should you spend time and effort catering to a group of users who might not even exist”, but I think you’ve provided an example answer for your question “just what is it about accessibility that gets some people so inflamed?”

      Meanwhile a balanced conclusion that this is all about generic useability on many devices and platforms and not about disabled users at all really, seems to suggest that there’s quite a lot of smoke blowing about somewhere.

      • I’m not insulting anyone dude, except people who refuse to care.

        People who do care but don’t know what to do — I have endless respect and time for such people. I only dismiss those who just can’t bothered.

  • KiwiJohn

    As kaf mentioned, a lot of what has been discussed here is to do with semantic markup – which affects accessibility, but is really a separate issue, i.e. markup should be semantic even if you don’t consider accessibility. Aside from that, there has been little specific information on what developers should be doing.

    For someone new to accessibility, it can be quite daunting to go through sites like WCAG. There are so many things there to consider that it can become overwhelming.

    It would be helpful to have to see a list of the most important things to consider AFTER ensuring markup is semantic.

    • Let me put together a list of helpful links, and I’ll post again in a while.

  • Let me be clear about my point of view here — then anyone who wants to can argue among themselves without dragging me into it :-)

    1. Accessibility is all about people with disabilities. That’s what it’s about.

    2. However, the things we do to improve accessibility also benefit various other groups of users in other ways (for example, a zoom layout also benefits mobile devices, as I’ve mentioned elsewhere).

    3. Accessibility advocates have seazed on the second point to try to “sell” accessibility, and in a way that’s unfortunate, because it’s totally muddied the water about what accessibility actually is; hence, there’s lots of confusion. But allow me to dispel the confusion, by re-iterating

    1. Accessibility is all about people with disabilities. That’s what it’s about.

    4. The reason you should care about accessibility is that the law says you have to. Or, the reason you should care about accessibility is that it’s morally the right thing to do. Take your pick.

    5. The reason why providing for accessibility is part of professionalism, is that HTML was designed to be accessible. The web was designed to be accessible. Building an inaccessible web is defying a part of its its core purpose. Why was it designed that way? Because of

    4 … and why is law and morality anything to do with it? Because of

    1 … it all comes back to 1 – people with disabilities are suffering disproportionately with the rest of humanity. Every day. In ways you can’t even imagine.

    AnilG — let me ask you this in the nicest possible way — what exactly is it with you? Why do you object so passionately to what I’m saying?

    • AnilG

      Look James, I’m not trying to be difficult, honestly. You are the one using swear words and if you can’t see the insult in telling an undoubtedly human being that they don’t deserve to be called a human being then you need to get recalibrated. I can’t think of anything much more severely insulting and obviously incorrect to say to anyone.

      Also, you don’t seem to have noticed that I’ve actually defended your points. When Craig Buckler, for instance, contradicts your point #1 explicitly, I have raised that as a question and asked for clarification (which no-one seems to have).

      Why is it only kaf and myself who seem to understand this? It’s like the elephant in the room or perhaps the emporer’s new clothes.

      I’m not objecting passionately. I’m dispassionately pointing out the logically inconsistencies and, so help me, I can’t give in and pretend it all adds up when it just doesn’t.

      As kaf said, this is more a question of what “accessibility” actually is. I feel I’ve learnt something from a number of the comments posted but many of the posters seem to differ in their definitions to you. Craig Buckler being a clear example of the trend.

      I’ve made the point so many times I rather expect you to be uninterested in hearing it again but if you’re willing I think I can demonstrate the issue by example with reference to zoom layouts that you mention above. Examples always help to make things more concrete.

      I think I’ve found my answer about accessibility by reading the comments and I’ll just go away quietly and research anyway. But co-incidentally, if I’ve read correctly, the inconsistencies reveal that some individuals are confused about their morality. Raising these inconsistencies then touches the raw nerve of confused morality. I think this is the real answer to the main subject of your article. This is where the Angst of Accessibility comes from! But you’re probably not going to like me saying that :-)

      I’m not actually claiming to be correct here, I don’t have a position. I’m only here because of my ignorance about “accessibility”. That’s why I read the article. I’m actually seeking information. I expect you as the author to be an authority on “accessibility”. I’m actually just seeking to learn on a technical basis. I’m trying to avoid the morality and psychology as much as possible, but you twisted my arm.

  • Fair enough mate, but you don’t come across like someone with no position who’s just trying to learn — you come across like someone who’s firmly entrenched in opposition to accessibility, who resents being asked to spend time and money on it, and who seems to regard accessibility advocation like some kind of conspiracy that’s trying to waste your time and money on implementing something unecessary, like they’re trying to sell you accessibility under false pretences.

    That’s just how you come across. Surely you can’t have failed to notice how a substantial number of comments in this thread are people explaining things to you? And a substantial number of your comments are you rejecting and nitpicking every argument and encouragement that’s put your way.

    This “elephant in the room” you talk about — it simply isn’t like that. You talk as though people who advocate accessibility in terms of the needs of disabled people are lying to you, when it isn’t about that at all. I’ve said it several times, but I’ll say it again:

    Accessibility is about people with disabilities. It also has benefits for many groups of users, but that’s just incidental, happy co-incidence — the real point is to cater for the needs of people with disabilities. There are people who disagree with that definition — those people are WRONG, okay? :-)

    I just wish you could be a little more constructive in your arguments. Far from being dispassionate, you’re being incredibly cynical — when you talk about things like “emporers new clothes”, “blowing smoke” and “logical inconsistencies” — all you’re really talking about is the fact that people disagree. Well sure, people disagree. People disagree about what disability is, never mind what accessibility is .. but why does it matter so much? You think you’re the only one who’s spotted this, and that no-one else is prepared to talk about it. Well maybe it’s just that nobody else sees it as such a big deal. What if you had an answer — a firm definition of accessibility that everyone in the world agreed with — what difference would that actually make to your attitude?

    And the reason why accessibility advocates get so frustrated, and annoyed at people who endlessly nitpick the minutae … is that it only serves to distract us from the real point; to move past the obvious truth that accessibility is important and is our responsibility, and get onto how we actually do it. That’s the real “angst of accessibility” — that we have to waste our time and energy having arguments like this.

    For all I may critisize your attitude, I do respect your open-mindedness — but there’s a whole world of people out there who simply do not give a toss about people with disabilities. That makes me really angry, so forgive me if sometimes my anger is misplaced!

  • AnilG

    That’s ok, James. I appreciate your willingness to bare your soul.

    I’m clear you’re saying other people are wrong on their definitions (including Craig Buckler). Far from disputing that I had just hoped someone would be man enough to unite the two viewpoints with a consistent explanation.

    Far from failing to notice that people were “explaining” to me, it seems it was you who didn’t notice that the very explanations they gave mostly contradicted your own. I didn’t reject them, but the contradictions made me look for a consistent view that would also resolve against your own view. Otherwise I can’t understand what I’m supposed to be doing.

    It seems you’ve misunderstood me entirely. I haven’t been “wasting my time”. I’ve been seeking a genuinely comprehensive resolution of all the viewpoints. I believe I’ve found that. But I also think that the reason you are full of so much angst over this is because your own limited view is not comprehensive. If you were able to incorporate the factors that people like Craig are mentioning without labelling them “WRONG” you’d be able to help others more to provide accessibility features and support, which I wish you well in doing.

    Practical, not cynical.

  • It’s really interesting that you should make that point. The fact is, I used to have that point of view exactly. I used to be the person I described in this post, who felt that focusing on the needs of people with disabilities is a kind of unfair discrimination, and that really, what matters is the needs of *all* users; that what accessibility really is, is an attempt at what you might call “human interoperability” – to make things that work for everyone, including of course people with disabilities.

    The zoom layout is a great example. The original idea was to promote the needs of users with severe sight difficulties, who use very large text or screen-magnifying software. But the technique also benefits mobile users, legacy browsers, and a few others as well. Now isn’t that great — and if we can sell those extra benefits, then more people will do it, and that will ultimately bring about the desired accessibility benefit.

    But that isn’t what happens! What happens is that people see that, and think, well if all we’re talking about is broadening our user-base, then it’s a waste of time and money, because we know who our user-base is and they don’t need a zoom layout.

    So it gets dismissed, because the focus is wrong. It’s not about those other benefits at all, it’s about people with disabilities, because they’re the ones who are actually suffering. People who use old browsers, or ipods, or whatever — they’ve made a choice, and it doesn’t necessarily behove us to support that choice. But people with disabilities have made no choice — they’ve had a restriction thrust upon them.

    So eventually I realised that these two ambitions are disparate. And that promoting the wider view actually dilutes the original purpose. So I changed my mind and my attitude accordingly. ]

    Accessibility is about people with disabilities. That is what it’s about. Period. I know it sounds puritanical, but you have to draw a line somewhere. You know, sometimes, by being open-minded you deny yourself the chance to learn the truth :-)

  • AnilG

    James, I get the feeling that you and me are the only two left in the room on this discussion. I have some responses to this but I see I can whole heartedly agree with your last point, so that’ what I’m going to do.

    The truth has this effect on people: when they know what the truth is, they suddenly becoming extremely narrow minded. And that’s good. Because if you know what the truth is, there’s no point in wasting time with the lies. An open-minded person, is someone who hasn’t realised the truth yet.

  • Exactly :-) And that can be a difficult thing to admit to, because to anyone who doesn’t share that perspective, it just looks like small-minded stubborness. But it isn’t that at all (as long as you realise this only applies to things for which the truth is knowable ;))

    I’ve been thinking about why I so totally misunderstood where you were coming from with this, and I think it has to do with attitudes to disagreement. I make a point, someone else steps in and disagrees with part of it, and then you come along and draw attention to that conflict, to try to reconcile it and find the truth within it.

    But I never noticed the conflict, because I only focused on the part of what I said that they *did* agree with.

    If people are on the same page when it comes to accepting that accessibility is important and then doing what’s required in practical terms, I don’t think it really matters why. Whether they’re doing it for disability access, or they’re doing it because they see it as a part of wider usability for everyone — it doesn’t matter, as long as they do it :) It’s only when they’re not prepared to do it, that it becomes a complex argument, touching on morality, the law, professionalism and professional ethics, time management, resource constraints, client expectations etc. etc. Does my head in.

    You’re right though — nobody else but us is paying attention any more :-) There might yet be another post in this though — something else accessibility related that starts with an “A”!

  • Sally

    This is also interesting for many of us who are not professional web developers, but end up doing some of this work in our organisations because we’re a non-profit etc, and really do want our sites to be accessible. (There’s also the double worry of being an amateur and creating something that works to contend with!)

    Webaim and sitepoint have a lot of really useful resources, but for more than the basics, we’re in trouble – issues like where do I find/how do I build an accessible carousel, tabs etc. seem to crop up on some of the mailing lists I subscribe to an awful lot. We really do want our sites to be accessible, but sometimes searching down helpful information is extremely tricky, especially when there’s so much conflicting information. I can implement something feeling confident that I’ve done the right thing and it’s accessible and I’ve evaluated it according to all the criteria I’ve found, and then find out later – really it’s not.

    This I think is part of what’s frustrating about trying to do the right thing – getting up to speed certainly is, but it’s the things beyond the basics that are the most frustrating. (Pretty much anything to do with javascript and how screenreaders interact with it.)

    Anyway, that’s my two cents.

    • Yes indeed, and RIAA is a source of particular frustration. It purports to be the solution to accessible dynamic scripting for screenreaders, and yet, no user research has ever been conducted to establish whether this aim has been successful; whether screenreader users are comfortable with RIAA enhanced apps; whether indeed they work at all! And how can ordinary developers — who are not experienced screenreader users — possibly test it themselves to establish this?

      It’s hard to embrace a solution when nobody knows if it works!

  • Anthony Rose

    Popped back in to see where it all went. Really enjoyed the last few posts winding up the discussion, thanks!

    Just like to add one thought: James, those with disabilities who try to access a non-accessible site are not “having restrictions thrust upon them” by the web-site. Theirs is the restriction already, thrust upon them by life.

    Now I agree with you that we should be compassionate. But you can’t take your compassion and morally thrust it upon someone else, because that in itself is also a moral crime. As an example, if you were to pass a crippled beggar in the street, and toss him some cash, and notice that others are not doing so, and then get help in forcing passers-by to give, you would in essence be robbing them.

    Morally, the best way to resolve the angst is by INSPIRING people, not forcing them.

    This entire planet is a giant experiment in handling disabilities of the people around you without becoming one of the problems yourself. “Do unto others as you would have them do unto you.” i.e. be kind, and don’t force.

  • That’s exactly the restriction I meant — life has thrust that disability on them, not the website. But because the website has the ability to help, it should.

    You’re right when you say that you can’t force people to do things, and that forcing someone to accept your morality is itself an act of immorality. Your beggar analogy is not quite the same though, because the law doesn’t require people to give money to beggars.

    When I wrote this post to begin with, and the previous one (art of accessibility), it was very much intention to be sympathetic with the barriers that developers face in trying to cater for accessibility; to be inspiring and gentle-handed about it, and try to reach-out and encourage. But somewhere along the line I became extremely angry at frustrated. For which I apologise.

    But there’s only so far you can go to inspire people — they have to want to be inspired, and some people are just too stubborn to change (not that I’m making that accusation of anyone here). When it comes to something as important as accessibility, it is hard to remain even-handed in the face of that.

    “do unto others …” is a fine maxim, as long as you remember that, just because you treat other people the way you want to be treated, it doesn’t mean that they will in fact treat you the way you want to be treated!

    • Anthony Rose

      Thanks for clarifying that for me! A fine summary! I like that you feel so strongly. At the end of the day, I personally believe that people will have to justify the way they acted, so it will all be straightened out in the end. What goes around, comes around.

Get the latest in Front-end, once a week, for free.