Lilula

Coming soon.

A Guide to Access

This is mostly for any DIM students who visit my blog, but everyone is free to add or comment. I don’t claim to be an access buff, neither do I think I know everything. This is just a guide including some very good resources, reasons why designing accessibly benefits both users and designers and a few easy to follow tips and tricks. Hi Dave!!

So how can we define access? According to the dictionary it means the right to enter, reach or gain access to. Access can be applied to all types of users, whether it be someone with a visual disability or someone who is using a browser different to what you normally use. 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 yourself.

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 is awesome for search engines which will be able to pick out key words easily.

However accessible design isn’t just about coding - there is a large chunk of visual considerations to undertake. More than often someone who accesses a website will have a visual disability whether it be as simple as being long-sighted, colour blind or even partially blind. Sometimes someone will visit a website using dial-up or will have to pay for the amount of bandwidth they use. What about folks who are browsing at work and don’t have Flash or JavaScript enabled for security reasons?

Designing Accessibly

Lesson number one is don’t design like a twat. As obvious as this is it’s probably the most difficult concept for people to grasp. This includes using tiny text, no contrast, minuscule layouts, heavy graphics, Flash with great importance placed on it (i.e. for navigational purposes), yadda yadda. There are many examples of how to design like an idiot, and a good few of how not to. I’ll walk you through this concept and tell you how to avoid such simple mistakes.

• Big fonts doesn’t mean you need to have everything set to 500 percent. If you can read it from just over a foot away from a screen set to a high resolution without have to increase the size of the text, squint or cry in agony then that means it’s accessible.
• No contrast means, well light grey against pale grey? Colour lovers rocks at this if you’re not too keen on colour wheels, or if not just watch a few Dulux adverts to figure out which ones are the colours that go.
• There’s a huge debate about designing fluid layouts (i.e. layouts that resize with text, resolutions and so forth) but unless you design something that is larger than 800 pixels in width there is no problem here. However if you want a bigger layout I would recommend looking into it. It takes a fair bit of CSS but the concept is simple and works deliciously. Find some inspiration, and then get onto the tutorial!
• Heavy graphics can be easily avoided by compressing all layout images into JPG or GIF files which can in turn be called upon using a style sheet. Simple.
• Flash is a tricky one. WebAIM does an excellent article on how to make Flash accessible, and even presents some good points about it. However accessible Flash is not as easy as an accessible website so if you’re not familiar with it either a) use it lightly and make sure that alternatives are set in place should Flash be disabled or b) avoid it like the plague.

Coding Accessibly

Don’t panic. I know all DIM students love code to bits (internet applications… the good times) but there’s no reason to cry with exuberant joy. For all outsiders, DIM students don’t like code. We design. Ug ug. Er anyway, coding validly is coding doing things the simple way. It’s easier to update, easier to read and it visually looks tidy and, contrary to popular DIM belief, is not frightening at all.

So what are the common mistakes of a bad coder? Not using a DocType, invalid coding that returns many mistakes on the W3C validator, ignoring the rules of semantic coding, using tables to make layouts, and other equally naughty things. I’ll detail these and provide links a plenty. Anyone willing to contribute please do since this isn’t my forte.

• A DocType is a niggly little bit of coding at the top of every (well coded) 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 sounds pretty bad in itself. For more information on DocType’s read Rachael’s article on how to use them.
• Coding validly is as easy as XHTML. Although it is argued that the difference between XHTML and HTML is petty, XHTML is designed to display websites correctly across all platforms - go figure. The basics of valid XHTML coding are closing all tags, nesting tags properly, coding in lower case and placing everything within html, body and head tags. It’s so simple a monkey could do it and what better way to learn it from W3 Schools.
• Semantic coding is another doddle. It means using logical header tags that bots from search engines can read and return in a search. It increases your page rank and makes the page look tidy without CSS. Check out this article to learn more.
• Tables suck because they’re there to portray, well, tabular data. Using divs makes a website easier to update in the long run and degrades gracefully where there’s no CSS to be displayed. Use InObscuro’s tutorial to learn about coding a div layout.
• Using alternative text on images is another aspect of valid and accessible coding. So if you post pictures of your Disney princess birthday party putting alt text on an image that says “piccie_lushcamera01″ isn’t very descriptive. However, “Me in a Belle costume” is! Don’t go overboard though. “Me not looking so manly in a Belle costume gown whilst trying to regain my manhood by downing a keg of beer” is too much information.

Other Points to Consider

There is a huge war of some sort happening between validity enthusiasts, accessibility lovers and usability admirers. I’m not going to get involved because I can see things getting nasty, but I think they all lean on each other so embrace the fear and design for your users whilst keeping an eye on each of those subjects.

Good design isn’t born from accessible design. This is a LIE. Good design comes from being creative within limited situations, and coming out with something extraordinary despite what was thought possible. Putting the blame on the tools is just the trademark of a bad designer.

There are other little things you can do to increase accessibility on your site. For example, access keys are not the most imperative thing you can add to your website, but they are useful for some people who find it difficult or otherwise impossible to use a mouse. This can be someone with a physical or cognitive impairment, or even someone with a dodgy laptop touch pad. Use them in main navigation by tacking them onto links using ‘accesskey=”*”‘ and sticking a relevant character where the asterisk is. For example, Home could be H, or if done numerically 1.

If you use JavaScript, Flash, Shockwave or anything else that requires enabling or a plug in make sure that there are alternatives. There are simple ways to make JavaScript degrade seamlessly using CSS. Flash and Shockwave can be alternated with still images or text on browsers which do not support it.

Resources

• Making your Site Accessible
• Accessibility : What is accessibility?
• Not Validating to be Trendy
• The Web Standards Project
• Use It
• Checklist of Checkpoints for Web Content Accessibility Guidelines
• A List Apart (notably the article Let Them Eat Cake)
• The Value of your Visitors - Halfway down there’s a snippet on validation
• Accessibility Colour Wheel

Footnotes

Hope you DIM guys find this useful for AUFDW! And for those of you who aren’t in DIM, if you don’t want to comment explicitly on the above then provide your own opinions or insight on accessibility, or even your own links and resources. I don’t claim this entry to be absolutely perfect or complete in any way, so contributions (and hopefully not but if necessary, corrections) are most welcome.

Comments are off Subscribe