A Guide to Access »
Access means the right to enter, reach or gain access to. It can be applied to all types of users, whether it be someone with a visual disability or someone who is using a different browser. It sounds a little daunting, and sure it can be pretentious to gloat about having an accessible site but the truth of the matter is that having an accessible website makes things easier for everyone, including the webmaster.
Why design with accessibility in mind? Usually an accessible website is a tidy website. The coding is neat and easy to follow, the design is flexible so all types of users on all types of browsers, machines, devices and resolutions can view the same page and navigate it with ease.
Since accessible design is mostly valid design the amount of time the site takes to load decreases substantially. Coding semantically is coding logically – a semantically coded website will still make sense without CSS. This in turn allows search engines to pick out key words easily.
However accessible design isn’t just about coding. For example, a large proportion of the population is colour blind. Some users pay for the amount of bandwidth they use so image heavy layouts may not appeal to them. Some workplaces have Flash or JavaScript disabled for security reasons.
How can design incorporate accessibility? Lesson one is don’t design like a knob, which should be obvious. This includes using tiny text, no contrast, minuscule layouts, heavy graphics, Flash for navigational purposes, yadda yadda. As obvious as these points are, it’s very easy to fall into these design traps.
Having big typefaces does not mean everything must be set in a massive size. If you can read the text from around two feet away on a high resolution without having to increase the size of the text, squint or cry in agony then that means it’s most likely accessible.
Colour is a very personal experience and it’s difficult to achieve consistency in a way that’s accessible. Ensure that there is enough contrast by creating a greyscale of your designs, and view colours through colour blind eyes with the accessiblity colour wheel.
Fixed designs are optimum if the width falls within the most common resolution used by visitors. However if the design is bigger than the common resolution, it may be worth coding a fluid layout. I recommend browsing fluid design galleries as it is a difficult look to achieve.
Most website layouts will not need to rely on image heavy designs to pull visitors. Evaluate the purpose of images and try text alternatives. Heavy graphics can be avoided by compressing them into JPG or GIF files. Layout images can then be placed within a stylesheet.
WebAIM states that Flash can be accessible and a useful tool to increase usability. However accessible Flash is not easily achieved so if you’re not familiar with it either a) use it lightly and make sure that image alternatives are set in place or b) avoid it like the plague.
How can code incorporate accessibility? What are the most common mistakes in front end web development? Not using a DocType, invalid coding, not coding semantically, using tables to make layouts, and other equally naughty things. Anyone willing to contribute to this list, please do since coding isn’t my forte.
A doctype is a code at the top of a web page that sets a standard for the browsers that access it. Without it a browser has to guess how to display a page which it doesn’t always do accurately – ensure the proper doctype is used to render the design correctly.
Adopt a good coding ethic. Close all tags, nest tags properly, code in lower case and place everything within html, body and head tags. Don’t use markup to style elements such as font tags and the ever redundant center tag. In place of tables use divs.
Semantic code creates a logical heirarchy and tells a browser what data lays within tags. It allows bots from search engines to crawl with ease and makes designs easier to update. There are many more benefits to semantic coding, and it’s easily achieved.
Using alternative text on images is another aspect of accessible coding. Putting alt text on an image that says “piccie_lushcamera01″ isn’t very descriptive. However, “Me in a Belle costume” is! Alternative text should fall under ten words as it’s only meant to be a brief annotation.
What are the cognitive implications of accessibility? User experience is still a relatively new field in the world of user orientated services. It focuses on the psychology of user and interface interactions to produce the best experience for that user within context. As such there are a few points I feel are applicable to the web.
It’s easy to simply accept the statistics when it comes to eye tracking. Naturally there are recurring trends in the ways a user scans a website but mostly it’s down to the decisions made by the designer. Consider colour, size, position and shape when creating a gaze plot - or use an eye tracker.
There are also many usability factors to consider for text centric websites. Around a dozen words per line is optimum for readibility. Splitting up articles makes them easier to read on screen, as is using precise language without too much jargon or ‘waffle’.
- Making your Site Accessible
- Accessibility : What is accessibility?
- Not Validating to be Trendy
- The Web Standards Project
- Jakob Nielsen’s Use It
- Web Content Accessibility Guidelines
Accessibility does not make a good or bad designer. It’s an expected part of work ethic when regarding users, and as such should not be a selling point in any profession. Alternatively, saying accessibility limits design is just placing blame on the tools instead of accepting responsibility.
This article is being edited to remain current and relevant. If you have anything to contribute, please do not hesitate to comment. This post was last edited on November 23, 2009.
This is a great article, lots of interesting and helpful resources and thing to keep in mind when the accessibility is in question.
thanks for the mention, btw.
O_o Vivien commented on your blog?
Lil, you’re going up in the world! :P
Although I would have to say “semantic coding” doesn’t just mean using headline tags… You know better than that.
There are a couple of things I disagree with in this article that I thought you might be interested in…
Firstly, access keys are debated to be more of a hindrance than a help (especially when set to letters because then they interfere with OS shortcuts). I would recommend not using them. If ‘you’ feel the need to use them, stick with numbers.
Secondly, like Rachael said, semantic code is NOT just about using “logical header tags”. All code should be semantically correct. That means using {strong} for strong emphasis rather than just bold text, or unordered lists for navigation and so on.
Two other things you might be interested in:
1. The w3schools website is NOT made by the W3C (I only found this out today!) so referring to the writers as “the masters of the inturwebz” is not necessarily true.
2. By linking to a series of websites using single words (“good few of how not to”) you’re committing your own accessibility/usability faux pas – always try to ensure links make sense out of context!
So there you have it :)
Thanks for your comments all! Access keys, eh? I personally use numbers because they’re easier to use since they’re next to each other. I suppose with all the key combinations newer browsers have it’s actually getting more complicated to punch in an access key combination than get a shaky cursor to hover over a main link. Maybe a valid Javascript alternative would provide the solution? That’s if people can’t figure out how to use tab. I’ll do some more research into it.
I am aware of using strong tags (as well as em and such) but I forgot to reference them. Probably should have made notes beforehand to avoid skipping details. Hopefully people will read through the comments and pick these up!
1. That’s incredible!! A little misleading of them I reckon ;) Even though it’s not made by the W3C is it endorsed by them in any way? Might be my next task to find out.
2. I’d read that somewhere before (ironically it was probably your site) but didn’t put two and two together. And what of using title tags? Do they redeem me in any way? :P Oh well, it’s no secret I’m not great at using the advice I preach – but I’m definitely working on it.
It’s such a big topic, I’m glad some of my loose ends have been picked up. If only the same were done for my atrocious grammar :D
Awh, Lilian, you’ll do fine. It’s impossible to cover everything there is to do with accessibility in one page.
But you could claim “Do as I say, not as I do.”
Ooh, this is a good resource. I’m bookmarking it; thanks!
Gee, I hope my website is accessable for most users, it works fine in the major browsers I checked. And if it doesn’t then tough cookie you know where the ‘x’ button is lulz. OMG your W2C entry is sooo funny, but no way can it beat my weborexic site muahahaha emo dominance!
heyyy lil. When does the site swap comp winners be announced. Im hanging off my seat here! Lol. Hope you had a fab weekend!
Definitely a good resource!
*raises hand*
What’s DIM? >.
Oh no! The rest of my comment didn’t show up…that’s odd.
The acronym for my course title – Design for Interactive Media. This entry was directed to people in my year who asked me for pointers on accessibility.
heh, i’m glad you wrote what DIM is because that’s exactly what i was going to ask. i suppose you’re the big man (er, but not) on campus since people are coming to you for advice! :) how cool.
love the article, i have no corrections to make, and i agree with everything (what an exciting comment).
Heh, I think you should abbr the DIM thing, because it’s a nice thing for the people who don’t know what DIM is short for, like me. Oh actually, just read your comment on it.
I’ve been thinking about fluid layouts as well. Designing a layout for 800×600 is just… I know some people still use it, but I think majority have moved on to 1024×768? I don’t have figures to back my statement, but I think it’s getting more acceptable to make non-fluid layouts for 1024×768.