Unintentionally Blank

About a month ago I wrote about how a few high profile sites locked users out or prevented the use of parts of their site because they relied on JavaScript being available. Since publishing the post a couple of interesting things happened to reinforce to me that JavaScript accessibility matters.

The Nationwide Understands

The power of a little blog was shown the other day when I received a comment from Ian Lloyd (of Accessify and The Web Standards Project). While I have read Ian’s writing online, I had no idea that he worked for the Nationwide and was surprised to find this out in his comment and delighted to hear that he has referred the issue (users without JavaScript enabled could not access the login page to the online banking section) on to be dealt with.

For any large company, reacting to criticism from a relatively unknown blogger is quite unusual, but to do so with the grace that Ian did, especially resolving to look further into it, is fantastic. I understand what Ian said, legacy code could be at fault and it could be a long time before anything hits the main site due to the necessary processes of big business, but if the Nationwide are able to change this and allow access to the whole of their site without JavaScript being required then I will be pleased to claim a big victory for accessibility!

The People Have JavaScript Problems

It may seem to some people that 6% of users not using JavaScript is insignificant. Facebook claims to have 54 million active users, Hotmail advertises over 11 million unique users. 6% of those figures is 3 and a quarter million and over half a million users respectively, not insignificant figures.

These big numbers sound impressive, but they are also faceless numbers based on aggregated statistics and can start to mean nothing after a while. Over the last month, since publishing the original article, a few Internet users have drifted by my site driven by a few searches that prove being unable to use sites without JavaScript is confusing. In the last month I have had 4 visits from search engines with the query “facebook without javascript,” 3 visits from the search term “hotmail without javascript,” and 24 other visits from search terms involving the words JavaScript and either Facebook or Hotmail. These are real users that are finding it difficult or impossible to use a web site because it relies on JavaScript for certain functions.

Conclusion

There are users out there who do not have JavaScript enabled. It is possible, with the right mindset (like Ian Lloyd and Nationwide), to consider this and create sites that do not rely on JavaScript for core functionality. Don’t exclude users by forgetting this.

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.

An argument started up recently regarding the use of actionable anchor text for links on a page, or phrases like “Click Here” when you want someone to click. It all started with Brian Clark’s question, does telling someone to “click here” actually matter? It was the following paragraph that made me think about the issue:

Another reader once chastised me for wasting anchor text with the words “click here,” even though my primary goal for the link was to get people to click (shocking, I know). This is when I first realized that Google is truly making people retarded. Somehow, this person no longer saw links as navigation for actual people to use; they only exist to pass on “juice” according to an algorithm that no one fully understands.

Does Anyone Else Feel The Argument Got Off On The Wrong Foot?

Brian was right, search engines shouldn’t be telling us how to run our websites, however, rather than heading off in the wrong direction and maintaining that “Click here” and other similar, meaningless phrases are the right thing to do, we should really be thinking about what is important: the users.

Dawud Miracle highlighted exactly the reason why “Click Here” should not be used as anchor text. Put plainly, you cannot tell what a link with the anchor text “Click Here” leads to.

Context Explains The Link

Some would argue that in a sentence such as, “For more information on accessibility, click here,” gives context to the link and lets users know what to expect when clicking there. But not all users are reading everything on the page.

Back in 1997, Jakob Nielson tested and wrote about how users read web pages, they scan and pick out highlighted phrases, headings and links. If you scanned down a page and found the phrase “Click Here” highlighted as a link, you would have to stop scanning and read around the link to find out what it was about. Or you could just click the link to find out, Mike Cherim alluded to this in a comment on Ian Lloyd’s compromise solution on Accessify. Clicking to find out what a link is all about is an untargeted click which may have a lower conversion, if you are talking in marketing terms. I wonder if Mike has anything that backs up his comment.

How About Accessibility?

It is always sensible to consult the WCAG when concerning ourselves with the usability and accessibility of these choices. Point 13.1 says the following:

Link text should be meaningful enough to make sense when read out of context — either on its own or as part of a sequence of links.

This is a priority 2 checkpoint, but it deals with the usability aspect above as well as assistive technologies.

Yucca Korpela has a number of good examples and explanations of link texts out of context, as part of a very good article on not using “Click Here” in general.

Click Here For A Compromise?

I mentioned a compromise solution on Accessify earlier, where Ian Lloyd suggested linking a full phrase including “Click Here” using a <span> and some CSS to emphasise the “Click Here” part of the link. This allows for the link to have all the information needed to read it out of context, but draws the attention of a normal “Click Here”. I’m not a fan of this method because it still compromises on usability, by making users read around the link or click it to find out what it means.

I propose a final compromise. Let your link contain all the information that you need and use “Click Here”. What is wrong with saying “Continue reading X”, “Click Here to subscribe to X” or “Click Here to buy to X”? If you look at the phrases that Marketing Sherpa showed were better, none of them included “Click Here” for a start, in fact they used a little more explanation.

Ideally, I’d expect more explanation from a link still. You can tell your users what to do, but explain where they are going too. Brian Clark was right, Google shouldn’t matter when thinking of your link text, but the accessibility and experience for your users should. As Roger Johansson said, almost a year ago, think before you link.

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.