Unintentionally Blank

A whole lot more has been said about meta tag browser version targeting unveiled on yesterday’s A List Apart. Digital Web has quite a few reactions, a list which is worth going through if you want to see what the top people in the industry think of all this.

I have tried to keep up with as much of the conversation as I can and after some revelations today I am actually a lot happier than I was at the end of my post yesterday. Here is the way I see it now.

Continue reading “Version Targeting, HTML5 And The Other Browsers” »

Change is afoot. Every web developers’ favourite publication, A List Apart, has split the split them into three groups today, the content, the annoyed or the confused. The cause of this: Aaron Gustafson’s introduction to Internet Explorer 8’s version targeting feature and Eric Meyer’s thinking process in response to the idea. In a nutshell, from IE8 onwards the inclusion of a meta tag (or server setting) will be necessary to target the version of IE to use to render the page, defaulting to IE7 rendering if no meta tag is found (please see the article for more detail).

This has thrown the developer community into disarray as everyone tries to work out whether this is madness or genius. Jeffrey Zeldman, Jonathon Snook and Eric Meyer think it is a good thing, Jeremy Keith doesn’t, Drew McLellan distanced the whole Web Standards Project from the decision and Andy Budd thinks that IE will be the one to feel the force of the mistake. Here are my thoughts as I pass from the confused camp to one of the other two.

Continue reading “Version Targeting For IE8, Developer Wars, My Thoughts” »

Continuing in my series of posts on different things to think about when considering web accessibility this week I want to look at JavaScript.

I actually had some inspiration in this post from my girlfriend. I accidentally left JavaScript disabled one night after doing some testing on a site and came home the next day to be told there was “something wrong with the internet.” I quickly realised what had happened and rectified the situation, but the sites that she thought had broken may surprise you. Three major ones caught my attention and there’s a fourth I’d like to mention as well.

Continue reading “Web Accessibility — Javascript” »

Try to read this myspace site, I dare you. There is text there, you can probably see, but I would rather copy the text into notepad and read it there than struggle on in my web browser.

MySpace is known for bad designs, but it can serve as an example for us when looking at what not to do.

Now I’m not suggesting that anyone actually involved in web design or development would consider using white text on a grey background, but it brings up an important point. Continuing from my earlier post, Web Accessibility — Not Just For The Blind, I have couple of pointers to consider when using colour on the internet.

Contrast

Hardly any sites are so bad that people with perfect vision have incredible difficulty reading, but the visually impaired, the colour blind and even people with black and white monitors or a bright light on their screen need enough contrast to pick out text from a background.

The Web Content Accessibility Guidelines have a formula to ensure that any important elements on a site, text being the most important, have enough contrast, but a formula is not that much use to you and I, we’d rather be designing or coding than playing with a calculator and hex or RGB values. There are a number of tools available that use the WCAG formula, as well as some other clever ideas and visualisations so that you can tell whether your colours are visible to everyone who may be visiting your site. I personally like using Jonathon Snook’s colour contrast checker, it is quick and easy and applies the recommendations in an intuitive way.

Don’t Represent Anything With Colour Alone

Returning to the case of the colour blind or those with black and white displays, it is also important that when highlighting elements on a web page that you don’t rely on colours alone.

Links are an ideal example to show this. By default they are blue and underlined. Since CSS gave us the ability to change that, taking away the ugly underline was the first thing I wanted to do! However, if you can’t see the different colours, how are you supposed to know where the links are? Underlining, changing the background, underline or the cursor when you hover all add up to make links more obvious to everyone.

Test Your Site

Roger Johansson recently posted a list of 10 colour contrast checkers. Some will do the simple checking like Snook’s tool, others show you what your site will look like to sufferers of different types of colour blindness and one will turn your site from colour to grey scale (it’s quite interesting actually).

Have a look at a few of the tools, does your website pass or are there any colour combinations you are going to have to think about?

Look out for more on approaching less obvious accessibility issues coming soon, and if there is anything specific you want to know about please let me know in the comments or by email.

It seems to me that web accessibility can often be mistaken as being only for blind users. This couldn’t be further from the truth, it affects a lot of people from the severely disabled to people who can’t see their screen properly because the sun is shining on it.

How Do We Help These Other Cases Then?

First you need to know what you are dealing with. The WCAG1.0 gives a good idea of the different challenges users may face when using your site:

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
• They may have difficulty reading or comprehending text.
• They may not have or be able to use a keyboard or mouse.
• They may have a text-only screen, a small screen, or
  a slow Internet connection.
• They may not speak or understand fluently
  the language in which the document is written.
• They may be in a situation where their eyes, ears, or
  hands are busy or interfered with (e.g., driving to work,
  working in a loud environment, etc.).
• They may have an early version of a browser, a different
  browser entirely, a voice browser, or a
  different operating system.

So accessibility on the web needs to consider those who are fully able, but may just be in a different situation to how you expect people to use the web, like not using a keyboard or mouse or being interfered with whilst surfing.

Upcoming — Some Tips

Now we know what we have to face, I will be posting some tips on how to approach accessibility issues that you may not have thought about. If there are any areas in particular that you would like to know about, leave a comment or drop me an email.