For many years now I have been involved in User Interface development and have always followed W3C guidelines to the last millimeter.
Reasons for this have been:
- To achieve cross-browser compatibility
- Make code easier to maintain
- Make sure my sites work well over long period of time
- Ensure that everyone can access my page without any problems
My aim in this article is to try and argue against engineering massive accessibility into your web solution and give reasons why this might be a very good idea.
Current beliefs about accessibility
Within web standards circles accessibility has become a subject matter which nobody seems to want to contend with.
It seems to be the overarching feeling and belief that ‘more accessibility we build into our solutions the better our solution will be’.
The above statement, however, is becoming less and less true as time passes and in some circumstances is almost totally irrelevant.
When accessibility matters
There are clear circumstances within which accessibility is incredibly relevant and should be implemented by all means possible.
Some of these circumstances may be:
- Government sites where legislation states that AA or AAA accessibility compliance must be achieved to give every citizen equal chance of accessing Government data and/or service
- Company wants to achieve high search engine ranking and wants to make it really easy for search engine bots to find, index and crawl their web sites
- A company cares about their users, wanting to ensure a wide as possible accessibility in order to avoid customer complaints, negative feedback and generally increase their changes of higher profits by ensuring everyone can buy goods from their web site without problems
If you are working within an environment where the above circumstances are in place, ‘the accessible route’ should be followed without questioning.
If there is a good enough business case for accessibility, it should be implemented.
Accessibility is irrelevant
Today we are smarter about the approach through which we develop web presences.
User Experience Design (UXD) approach (if utilised) means that we identify the target market for which the given web site is relevant and cater our solution for that target market.
This is all in order not to waste company’s money and resources on implementing a solution which does not meet users’ requirements.
For example, if a high level of accessibility without JavaScript is not required (based on UXD research), it should not be implemented as target users are most likely to have fully featured browsers with good support for JavaScript.
There are many circumstances within which accessibility might not matter much at all and can therefore:
- Act as a potential development burden
- Increase time spent on coding a solution
- Create unnecessary overload on testers
- Complicate matters and
- Generally delay the time-to-market date without achieving any benefits whatsoever
Circumstances where accessibility may be highly or totally irrelevant when:
- Developing applications for an Intranet where target browser(s) support is very well known and the solution ‘resides’ within a controlled environment
- Developing for specific audience(s) with advanced browser support
- Search engine ranking does not matter as much (e.g. FaceBook or Google)
Accessibility matters after all
An important additional aspect of accessibility today (compared to some 10 years ago) is the incredible proliferation of various mobile devices, which might be the future way in which we access the web.
We may well find ourselves in a circumstance today where a given application needs to be accessible for ‘typical’ desktop user (e.g. using FireFox or Internet Explorer 8), but also needs to be accessed via BlackBerry Bold 9000 mobile device.
In this scenario we are better off implementing a solid W3C compliant solution for desktop users and another, parallel solution specifically targeted at BlackBerry Bold 9000.
This way both our target user groups will have very nice experience through their devices, while overall accessibility (according to WCAG1.0) might be very low in both implementations.
This approach hopefully helps clarify the overarching thinking behind WCAG2.0 guidelines which do see JavaScript as a ‘legitimate’ web technology which is part and parcel of many users’ browsers.
Written by Jason Grant on 29th January 2010
I cannot say I agree with your article.
Basic accessibility should be built in from the ground up.
You appear to be considering “graceful degredation” instead of “progressive enhancement”
While it is unlikely for anything to be truely 100% accessible what level of attainment should depend on the audience, enviromment and application.
Your final point on producing separate output for specific devices is exactly what should not be done.
But that’s only IMHO.
mike foskett
mike foskett on 29th JanuaryMike, thanks for your comment.
In his recent presentation to London Web Standards, Phil Archer from W3C, the author of Mobile Web Best Practices, it was pretty clear to me that Mobile Devices need separate provision in order to provide maximum UX for the mobile user.
Mobile connections are very slow and mobile screens are very small, only catering for 1 column layouts optimally.
This means that our 100KB web pages, which most blogs pages weight these days due to ’spinkles of JQuery’ and such wonders, are far too big for a mobile device to download in a meaningful time.
The only solution is to design for mobile where only relevant data is served to mobile pages, narrowing down the weight to some 3-4KB per page, using minimal JavaScript (especially relevant for BlackBerry devices which have very poor JavaScript support).
Bottom line? You are wrong.
Jason Grant on 29th JanuaryYour provocative title masks a clever, and spot on, accessibility endorsement. I agree that “some” of the cases where “accessibility is incredibly relevant and should be implemented by all means possible” include sites for businesses that care about their customers and/or their search results. Well done!
Nick Stone on 29th JanuaryI agree that there are cases where target audiences will PROBABLY not require accessibility tweaks/solutions, but remember that us blind ppl have varied interests just as the rest of the world. In general, blind-comp-users should try to obtain modern tech to help them access the web, but one needs to consider a couple of pointss.
Burt on 29th January1. Although there is now a fine free open source screen-reader available for V.I. comp-users, there are still languages that are not supported. Commercial screen-reading and even magnification software is vary expensive, so expensive that it is out of the question for many ppl in developing countries, (where there are more blind ppl per cappita than in more “first world” countries due to lack of basic health care issues).While web content evolves, screen-readers are in a constant game of catch-up to make content accessible to the blind user. (again updates are not free!)
2. There are many older ppl losing their sight every day. These folks are less likely to have the experience with IT, and adaptive tech in particular to quickly adopt the newest accessibility solutions.
For these and other reasons, one needs to consider a balance between delivering content to visually impaired users and timely and economicly practical updating of websites. The oparallel approach can often hold the key. To many ppl, and especially to the blind, the delivery of information is the bottom line. A txt only sight, or some other simplified format that can also be easily accessed by mobile devices is one starting point. For most blind users txt only is not even needed anymore, but proper labeling of links for example is. Web-developers and web-masters should consult with experts in the field of access, and when delivering all the bells and whistles to potential v.i. site-visiters is impractical offer a basic version of the web-site in question. A simple warning saying something like “the following section of our site may not be accessible by screen-reader users”. (less than ideal, but a short-term midigation tactic)
Burt Henry
You seem to confuse quite a few concepts here. First, you seem to equate accessibility with WCAG 1 and in particular with its old no-javascript mindset. As you note right at the end, we’ve moved on from there to WCAG 2.
“Developing applications for an Intranet where target browser(s) support is very well known and the solution ‘resides’ within a controlled environment”
I take it you’re mentioning this in light of javascript support. Now, that may be true, but even employees with disabilities use intranets, so I wouldn’t say accessibility is irrelevant…only the lowest common denominator approach of WCAG 1, maybe. But my company doesn’t have anybody with a disability? Not now perhaps, but what happens if somebody new joins the team? Or will the organisation simply say “you’re qualified, but we can’t hire you as you wouldn’t be able to work with our systems”? That wouldn’t fly.
“Developing for specific audience(s) with advanced browser support”
Ditto.
“Search engine ranking does not matter as much (e.g. FaceBook or Google)”
Users with disabilities don’t use Facebook or Google, in your opinion? Don’t confuse accessibility with pure SEO.
Accessibility is usability for people with disabilities. So yes, UX is important. Making sure you build the most appropriate site/functionality for your target audience is important. But you may find that your audience will naturally include users with a variety of physical/cognitive abilities.
“Act as a potential development burden
Increase time spent on coding a solution
Create unnecessary overload on testers
Complicate matters and
Generally delay the time-to-market date without achieving any benefits whatsoever”
Welcome back to 1990. Even the most basic accessibility consideration, which is simply part of common sense and best practice, can make a huge difference between having a completely inaccessible site and one that is quite workable. Stop seeing accessibility as a binary switch…it’s not either/or.
As for mobile sites (sorry, but completely different topic which seems to muddy the waters of your argument here) : you bemoan the fact that accessibility can potentially be burdensome and require more development, yet advocate building a completely separate site based on devices? Sure, if you have the time and resources, you’re of course free to do it. There are, however, modern techniques that quite easily allow a site to be built in a flexible, and most importantly adaptable, way (CSS3 Media Queries, feature detection and conditional loading of resources, etc).
patrick h. lauke on 29th JanuaryMy apologies but I’m slightly confused. Are you suggesting that accessibility should cease to be a concern to web designers/developers when it becomes too expensive or tiresome to consider it?
One of your opening statements seems rather amusing too. You’re saying that accessibilty definitely does matter if you care about users, SEO or you are the government. In my experience, it is reasonably rare to develop a site for a client who doesn’t care about the users.
The fact is that accessibilty doesn’t seem to matter to many people. I’m specifically thinking of the proliferation of many incredibly “creative” but almost utterly unuseable sites. 2Advanced Studios’ site is a prime example, looks incredible, runs entirely on Flash but is close to impossible to use effectively.
In terms of requiring Javascript for a site to be accessible, I was alway told (and I think very wisely) that using Javascript is great and it can be an extremely powerful tool BUT make sure your site works with it disabled.
You MIGHT be able to convince me that less thought can be given to applications within an intranet but, even then, you run into problems if the company changing or updating browsers (although judging by the percentage of them still using IE6, this may be a ridiculous thing to consider).
It’s an interesting article and thank you for posting it but I really could not agree less. It may be a nightmare at times and optimising for older browsers is especially time-consuming but I believe it is a web developer’s responsibility to provide accessible sites.
Luke Sheppard on 29th JanuaryI would not agree with you totally I am afraid.
Consider a good number of internet users have some form of disability. Be that colour blindness or bad eyesight.
Now consider, your website is your shop. Not making it accessible is like have a shop that is shut for a number of people is like not having a shop at all. Also consider that we have an aging population. As we age our eyesight naturally deteriorates.
Additionally, as people get older so their disposable income increases. Children leave, mortgages get paid off, we have more money to spend.
So, by not making information inaccessible you now have a closed shop to an ever increasing number of people with a larger portion of disposable income available to them.
I would not go all the way and say everything must be 100% accessible to all guidelines. However, it does make sense to make the best possible efforts, as is the law in England, and it will make more sense in the future.
York Hotels on 29th JanuaryWhen accessibility matters
There are clear circumstances within which accessibility is incredibly relevant and should be implemented by all means possible.
A company cares about their users, wanting to ensure a wide as possible accessibility in order to avoid customer complaints, negative feedback and generally increase their changes of higher profits by ensuring everyone can buy goods from their web site without problems
Enough said i think
Luc on 29th JanuaryRegarding mobile devices:
don’t forget the consumer-level and older phones most people have out there, many of which do have browsers that can read html – most of these don’t do javascript at all.
If you are aiming at the general public you WILL also have to deal with ancient browsers.
Asking people to upgrade is more likely to annoy users than actually get them to upgrade, and in some cases where ancient hardware is being used they may not be able to without some expense (think about people with low incomes, etc – I’m not surprised at all to see that there is still lots of IE5/Mac, IE6/Win98, etc traffic on websites aimed at the general public. Yeah we all hate it but its a fact of life as long as there are still lots of people out there using old machines and old operating systems – they don’t always need a perfect rendering, they just want to be able to use the site!)
Regarding search engines: Since when was Facebook a “search engine”?
Michael on 29th January(but yes, nice meaningful markup can help sites like Facebook display information from your page too)
Nice Article. I come here because the e-mail.
Bluray on 29th JanuaryThanks everyone for commenting so thoroughly. Much appreciated.
I wasn’t trying to state that FaceBook and Google are both search engines or that disabled people use them. I was trying to say that they are both sites who do not care much about SEO, as their means of promotion are of a more viral nature (word of mouth and so on), so Google will not care about being No. 1 search engine ranked on … Google (even though they are!). So clarification there.
Regarding accessibility, my overall argument was that today there exist extra development overheads for mobile solutions and such like which didn’t exist before, where extra accessibility needs to be provided.
In order to balance development resource it’s OK to deliver this extra accessibility through selective and strategic ‘deterioration’ of accessibility within the main/desktop solution of the site based on UXD research based principles (i.e. still providing all the necessary accessibility for the target audience).
So rather than providing AAA accessibility for the sake of it and no mobile solution, we should be able to get away with single A accessibility and a solid mobile solution instead. This approach is much more appropriate and paradoxically much more accessible.
So I can finally understand the principles behind WCAG2.0.
Jason Grant on 30th JanuaryAmazing what a provocative title will do for your comment count! Haha. I salute you sir.
Luke Sheppard on 30th January@Luke You are 100% right! Why was I not doing this from the day 1?!
Jason Grant on 30th JanuaryMy recent blog post cause a micro-avalanche of opinions.I think I was somewhat misunderstood, but it was interesting! http://www.flexewebs.com/semantix/access...
flexewebs on 30th Januaryvia Twitoaster
@flexewebs Well done, your blog got them snapping! Also you get a http://oo00.eu/ for commenting ‘Bottom line? You are wrong.’ Hilarious!
mattsbrain on 31st Januaryvia Twitoaster
Ha ha ha, you should post more often
mike foskett on 1st FebruaryThe Human Rights Act and the Disability Discrimination Act always matters. Through websites being accessible and functioning for the disabled, we provide them with more independence and make life easier for those who have to care for them. Being accessible helps make the disabled ‘abled’.
The sad reality is sometimes even government doesn’t meet the AA or AAA requirements, and I’d encourage people to provide feedback to those who don’t.
Squishy on 7th FebruaryIn conversation with Sandi Wassmer (blind accessibility consultant, who can only see 10cm away from her eyes) at London Web Standards on 15th Feb 2010, we seemed to reach the same conclusion that implementing accessibility is all about doing our best with the resources we have available to us (money, time, knowledge, skills, etc.).
Most of the accessibility ‘evangelists’ who rant on about implementing WCAG1/2 to the tee are far removed from the realities of the real, commercial world, within which clients rule with their requirements, based on their (lack of) knowledge about the given subject matter.
More about Sandi’s highly experienced view on the matter here: http://www.londonwebstandards.org/2010/02/lws-february-move-over-web-accessibility-inclusivity-is-heading-straight-at-you-live-blog/
Jason Grant on 17th February