A few weeks ago A List Apart published my article about web accessibility and the UK legal requirements surrounding it. The article provoked a heated discussion and what seemed like a lot of confusion surrounding web accessibility, which is what led me to write this follow-up article.
What follows will be familiar to many ALA readers but new to a few. As with all overviews, it is somewhat oversimplified and does not cover exceptions and edge cases. The editors and I hope that it will provide a useful touchstone for those readers who have been standing at the shores of accessible web design, fearing sharks where there are only gentle waves.
About this article#section2
This article will not tell you how to make an accessible website. That’s already been done by Mark Pilgrim in his excellent Dive into Accessibility and by Joe Clark in his extensively researched and beautifully written Building Accessible Websites.
Although they can be vague and confusing in places, after reading Pilgrim and Clark you might also want to check out the W3C accessibility checkpoints. I’m not going to preach at you about the benefits of accessibility — I’ve already done that elsewhere. Instead, this article will tell you who you need to consider when making your website and what their unique requirements are. So, let’s get started …
Disabled users#section3
Blind users#section4
Web users who have no sight at all may utilize a screen reader, which reads the content of the web page, or rather the HTML, back to them. This software, which sits between the user and the browser, sifts through the HTML markup and the technology deciphers what needs to be read aloud and what should be ignored.
Windows users, try it yourself with the IBM Homepage Reader, which you can download for a free 30-day trial. (You’ll need a recent version of Microsoft Windows and a fairly capable PC with Pentium processor or equivalent.) Once you’ve downloaded it, go to your website, turn your monitor off, and try to navigate.
Open source screen readers for Linux include Emacspeak and IBM ViaVoice.
The next major revision to Mac OS X will include built-in spoken interface technology. Mac OS X users who complete a brief questionnaire may be able to download and use a preview version.
Partial/poor sight#section5
To take full advantage of the Internet, users with partial or poor sight need to be able to enlarge the text on web pages.
As this magazine’s readers know, Opera, IE5 Macintosh Edition, Mozilla/Netscape/Firefox, Konqueror, Safari, and all other modern browsers but one provide text resizing widgets that work no matter what method a designer has been used to specify type size.
But for IE/Windows users to be able to resize text, you must specify the font size in terms of %, em or a relative value (small, medium, etc.) as this magazine does, or use a basic or advanced style sheet switcher to provide this functionality.
Users with poor vision may also use a screen magnifier. You can download a screen magnifier for free and try it for yourself.
Color blindness#section6
It is estimated that one in 12 men and one in 200 women have some form of color blindness. You can check how Internet users with different strains of color blindness are viewing your website with Vischeck.
Deaf users#section7
Deaf users are able to access the Internet in much the same way as non-deaf people with one key exception — audio content. If it’s a key function of your website for people to be able to hear a message, then be sure to provide written transcripts at the very least. (To do more than the very least, see Chapter 13 of Joe Clark’s Building Accessible Websites.)
Keyboard/voice only users#section8
Some of your site users don’t have access to a mouse when browsing the Internet. Try putting yourself in their position by navigating your website using only tab, shift-tab, and the return keys.
Other users#section9
Other people who may access your website that have disadvantages include:
- Epileptic users who must always be careful to avoid seeing flickering between 2 and 55 Hz
- Web users from outside your industry who may not understand industry jargon or acronyms
- Web users whose first language is not English and who may not be able to comprehend complicated language
To really put yourself in the position of one of these web users try out the DRC’s inaccessible website demonstration.
New (and old) technology#section10
PDAs and mobile devices#section11
The number of people accessing the Internet from handheld devices is increasing at a massive rate — almost three million PDAs were sold in 2002 in Western Europe and in 2008 alone there’ll be an estimated 58 million PDAs sold.
Handheld devices generally have ropey support for large images, JavaScript, Flash and (too often) even CSS. Their width can be as small as 120px with horizontal scrolling not an option. Read Webmonkey’s last-ever article which was about small screen web development. You can also check your website’s accessibility on a handheld device for free with the Wapalizer.
WebTV#section12
WebTV has a maximum width of 575px and horizontal scrolling isn’t possible. You can download the free WebTV viewer and see how your website looks on a TV screen.
JavaScript#section13
Approximately 6% of web users are surfing the web with no support for JavaScript. This could be because they’re using a browser that doesn’t support JavaScript (such as the text-only Lynx browser) or they’ve turned JavaScript off for security or to avoid popups.
Slow connections#section14
Broadband isn’t nearly as widespread as you’d expect. In the UK, for example, just one in six Internet households were hooked up to broadband this time last year. Users on slow connections might turn images off to enable a quicker download time. Some browsers, such as the Lynx browser do not display images at all. Make sure you put in those ALT attributes!
And finally …#section15
Any web developer with basic HTML and CSS design knowledge, and a bit of time on their hands, can easily learn and implement web accessibility — it’s not brain science after all. Web accessibility is all about following design standards and then adding in a few simple accessibility features. It’s not just about disabled users being able to access your website — it’s about everyone being able to access your website.
Great overview of web accessibility and the type of users we should pay attention to when designing accessible web sites.
I just wish there were lower-cost developer versions of popular screen readers such as IBM Home Page Reader and JAWS.
http://www.diveintoaccessibility.org/ is the ultimate real-life guide to web accessibility. I reccommend it to everyone that has any interest in this ALA article.
Good overview.
But 2 points:
1) Categories.
In “other users” area we cannot found:
# Web users from outside your industry who may not understand industry jargon or acronyms
# Web users whose first language is not English and who may not be able to comprehend complicated language
… as far as they are not disabled.
My first language is not English and I don’t have any kind of disability because of that. 🙂
Maybe we can talk about mentally disabled people here too but I have no info neither knowledge about this subject.
2) Flash. I miss some words about the current situation of Flash accesibility for disabled users.
I have found an old article here, http://www.alistapart.com/articles/flashmxmoving/
Web accessibility has always been on the edge of my mind when I build a website, but lacking motiviation I’ve never actually looked deeply into the subject. This is a great rundown of everything a developer needs to keep in mind.
Hi, although I’m not mainly targeted on the english-speaking webuser, I found it very interesting to “get kicked” in my mind the problem regarding WebTV – I didn’t know this technic is so limited in viewing – thanks for this hint – I always try to design websites like if the user’s having my old slow connection from years ago (I think it’s helpful to have a personal “internet-past” while designing – the kidz designing today often don’t even know the problem of slow connections I think). Greetings from Germany & please excuse my non-perfect-english, thanks Dave.
I was reviewing the findings of some usability testing of a UK site yesterday. We’d focussed specifically on the content and navigability of the site among users with different disabilities and a few surprising things emerged which aren’t covered in the article:
– though it makes sense intuitively, it’s not correct to say that “Deaf users are able to access the Internet in much the same way as non-deaf people” except for audio content. That’s fine for those deaf people who learned a spoken or written language, but for those whose primary language is sign language, large blocks of text are intimidating and difficult to deal with
– how about learning difficulties? Again, there’s a significant portion of the web audience who struggle with large blocks of text, in some cases because reading words in order is difficult, or for others because the text appears to ‘shimmer’ when they look at it. There are steps designers can take through colour combinations and paragraph structures to help these users
– how about user with multiple disabilities?
The W3C specs and checkpoints are tricky, but their case study/typology examples are great – I found them a great way to avoid the trap of thinking about accessibility solely from the point of view of technical solutions.
One of the main reasons I always include DDA requirements into sites I develop is that the biggest ‘blind’ users are search bots. If you follow structured mark up for your content adding extra peices for accessability should come as second nature.
thanks. this article helps in reminding that semantic markup doesn’t equal accessibility, though we’d like it to because WE CAN SELL accessibility while having our css fun.
sadly but truely, the article implies it ain’t free. I mean, can a customer buy you an accesible website?
Maybe so if it’s a 10 page site. But what about a large + periodically updated one? Does it need an accessibility-wise person in charge? Fine, you’ll say “educate someone, pay a qualified person”, etc. Hey, you can even convince a client to do that! (doug and dan come to mind)
But what if it is a non-profit, NGO, where volunteers might
1. work part-time, not having time to write good alt text at least
2. change so often you can’t teach them the basics?
maybe someone can share some experience here *ahem* amnesty *ahem*
Beautiful article.
To be honest, this article and a few related previous articles provided the oppurtunity and also direction to some of my lastest work.
But usually I faced a lot of head-scratching over the idea of: “selectively degrading a display to show the content in a proper and legible format for a given display and requesting device”. Usually from my clients who come with a idea of having – Rich GUI website (and have no clue what it is all about)
So I would suggest a sample case-study, where a rich GUI is made standard complaint and accessible – with possible inputs and tips from the various experts here.
Would be a great help, especially to say: “.. and if you still have any doubts, check out this link which does all this…”
😉 food for thought – article 3 maybe…
Of those 6% I’d say that only 2% are real users. The other 4% are search engine spiders and/or spambots.
I liked how you said that 6% of UAs have JS turned off without ranting about how only silly script kiddies use it and that any site that uses JS is innaccessible. Good job, Trent.
Great overview. Many of those links will or have proved useful. It is good to get the information in one spot.
WAI (Web Accessibility Initiative), in coordination with organizations around the world, pursues accessibility of the Web through five primary areas of work: technology, guidelines, tools, education and outreach, and research and development.
SEO India
I have been involved with issues doncerning web site accessibility, and I find this article very informative.
Even tough there is some issues with client side scripting, it is still very useful for most visitors. As long as the content is available for all it is nice to use javascript for cosmetic effects.
Recently I found myself in a situation were I felt temporarily disabled. The simple task of writing and sending an e-mail took me 10 minutes.
I was in an airport, having to communicate fast to warn of a delay, hooked in a pay-internet kiosk, found myself with a slightly different keyboard, no mouse to speak of, and a very weird pointing device. With a 10mn connection ticking away.
Trying to use that kind of device is very enlightening.
An excellent overview of an area which indeed is not rocket science. Accessibility is really quite easy to realise as long as you do not cling on to old ways of doing things (lots of fancy and usually meaningless eye candy, JavaScript used for things HTML and CSS can do).
Thanks Trenton for a fine summary and a list of excellent links.
This article does not mention Dyslexia and other related disabilities even though they are far more prevalent than blindness etc. The Uks DDA and SENDA laws cover these whereas W3C/WAI does not. Anyone limiting themselves to just catering for the obvious physical disabilities will find that they could still fall foul of the law.
Since cases are being settled out of court, ‘case law’ is not yet confirming any specific rules or guidelines but it will not be too long before it does.
I would recommend any site offering a service to make use of a style-switcher to provide appropriate fonts, colours and background that improve readability.
A sans font with a rounded ‘a’ not horned is required, like comic-sans, with a slightly yellow or cream background would be one option. I know comic-sans is not a favourite of web designers but it is the customers that count.
Personally, I think using a style-switcher is a waste of time – your site visitors will all have their own unique needs and it’s impossible to please them all. If people find websites hard to read then they can use their own stylesheet. After all, the main reason for using stylesheets is so that users can adjust the font/colour/size according to thier own needs.
So if you’re a dyslexic web user you can set your stylesheet to always render text as Comic Sans. This will work for all websites that use stylesheets to generate the font.
You seem quite knowledgable about web accessibility and dyslexia, Dave. Is there anything else you’d recommend doing to cater for this group of people?
Another great read not yet mentioned with a great intro to accessibility is on the WebAIM site: http://www.webaim.org/intro/
At the bottom of that page are links to 4 categories of disabilities (Visual, Cognitive, Hearing and Physical) and the implications of each category on design.
Taking the time to understand things from the perspectives offered in this article can provide extra incentive to a designer to take the time and effort to design accessible sites when other benefits may seem lacking.
I agree with Dante.
It’s good to see Accessibility and articles related on accessibility come to the attention of others.
Speaking for myself, you’d be surprised how many companies in here in Canada are either not aware or cannot be bothered to look into such issues. I had a chance to talk to a certain Tourism office run by a certain Provincial Government about what they could do to enhance their existing site. I showed them the facts of their existing site with all of it’s nested tables, non-validating, non-accessible markup and mocked up a home page for them in XHTML, CSS and meeting WAI-AA that looked almost the same as their existing home page.
Needless to say, they thought I was very enthusiastic and all that jazz. They said to me ‘Well, it doesn’t really meet the qualifications of our focus right now. But thanks for the information….etc.’
Perhaps if some major companies here tried to make accessibility more into their focus here in Canada, it would be better off all around and more importantly, show an example to the rest of the businesses as well.
It will be interesting to see the scrambling that happens if Canada imposes something similar to Section 508….but who know when that’ll happen. Probably in another 5 years, or so.
i love accessibility and it bugs the hell outta me when a site i design goes without due to constraints or maybe I just didnt realize them at the time.
However, I must admit, I was weary of another article (maybe it was the long winded response and debate over the last one…), I mean I figured there will be those chosen few who pave the way, who understand and everyone else will play catch up in a few more years.
**DELETED RANT about pre-html 4 nestled tables and misused js**
BUT – I read it and it is nice, Simple, clear, to the point. A great thing to print off, maybe a checklist? AND yes, accessibility nuts, there needs to be an easier (cheaper) way to test aural browsers and the like, the way Amaya should be perhaps, an open source suite of standard and accessibility checking software which emulates text, voice, non-js, slow connection, resolutions etc…I mean, charging for a browser? How accessible is that?
There are other opinions out there
css vs tables
http://www.decloak.com/Dev/CSSTables/CSS_Tables_10.aspx
Don’t take this too seriously
it seems that everyone doesn’t like CSS.
I’ve been invloved in re-developing a site over the last year. Despite some fairly heavy design, I have managed to code it all in xhtml/css. The database team weren’t overly happy about it but hey.
I would love to code to cater for disabled users on all my sites, my reasoning being that if it’s easy for someone with a disability to use, then it’s easy for everybody. Win win.
However, when I have touched on accessibility issues regarding this particular project, the client has simply said “Until somebody calls me to say I am in breach of the law, I don’t give a damn about disabled users. I want fancy javascript menus.”
What can you do? The client is aware that the law (in the UK at least) requires that a site is accessible to all as far as possible, but doesn’t care. I hope they get busted, I think their attitude stinks. The point is, you don’t need to convince me, I’m sold on it, but clients who have the money, are in control.
The only way forward I can see is not to tell them! Code for accessibility and tell the client afterwards.
Or maybe I should just make that call….
if we all turn renegade and make clients’ sites accessable anyway, many would not even know, right? and when we get fired ’cause sometimes we do have those ‘i don’t give a damn’ clients, someone else will hire us all, right? maybe i’ll just bum for change and design for free… wait… i already do, damn.
The major problem I’ve seen in the corporate world, is people who are afraid conforming to the guidelines will somehow add to project deadlines and lead to other people “controlling” an aspect of a site. I’ve been in countless accessibility meetings lately and we never get anywhere. People a re just afraid of things they don’t understand.
joakim, that misguided rant on decloak you linked to made me laugh, then cry, then shake my head…what the hell is the author on about? if this is not a good example of sticking one’s head in the sand, i don’t know…the whole rant could be summed up in “why can’t screenreaders be smart enough to understand my current markup? surely anything else is a waste of taxpayer’s money…”
i had to read it about 3 times to make any sense of it…and it’s such a damned shame there’s no commenting option available…
“but clients who have the money, are in control”
Or your boss, who sets your every minute of work – accessibility becomes an off time passion.
Not all epileptics have seizures due to flickering lights. Some, like me, are quite immune to it.
I understand the point about style switchers not allowing for a users unique requirements but to create and set up a personal CSS is not easy.
There are many places on the web where the problems are discussed, not least the British Dyslexia Association.
http://www.bda-dyslexia.org.uk/main/information/extras/x09frend.asp#
Just type dyslexia accessibility into google.
This site has articles and a wizard for creating a personal CSS and instructions on how to set it up.
http://www.techdis.ac.uk/seven/papers/dyslexia-index.htm
This is another good article
http://www.madeforall.com/archives/000013.html
I have been making a transition to accesible and XHTML valid tables. I have noticed that when I use TBody, THead, and TFoot then try to validate my pages with the W3Cs validator (XHTML Transitional), it points out that these tags are not valid or missused. I am certain I am using them correctly.
Does anyone ahve any insight into this issue?
Good article, I read it twice… Recommended for reading!