Unintentionally Blank

It’s always interesting to see what plugins other WordPress bloggers use. Today Darren Rowse shared a few of his favourites. As it’s the weekend I thought I’d show you my top plugins too.

Continue reading “Something For The Weekend — WordPress Plugins” »

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.

Internet Explorer can make the simplest piece of code hard. It turns a simple function into a headache. The standards say one thing, but Internet Explorer doesn’t just disobey those standards, it comes up with a different function and a different idea of what that standard even meant. All I want is that when you click on an element to trigger a function, you can refer to the element using this. Let me explain.

Simple Javascript Functions… Really?

I am gaining a lot of experience and practice with javascript in my new job and I am really enjoying it. I’ve dealt with some complex stuff and some seemingly simple stuff. But sometimes it is the simplest of functions that cause the biggest problems.

All I needed to do was create a page with a few <textarea>s that held text for someone to copy. To aid in this, I was to write a short javascript function that would automatically select the text when the <textarea> was clicked on. Here is the function that will do it:

function selectText() {
this.focus();
this.select();
}

Attach selectText() to the onClick event for each <textarea> and I was sorted.

Except For One Thing…

Internet Explorer, in all its wisdom, returns the window object as the result of this regardless of the element that triggered the event. Firefox and all other sane browsers return the element as you would expect. Quirksmode explains this much better than I can.

I spent forever searching for a way to return the element that triggered the event so that I could use the function, finally stumbling across a mention of event.srcElement in a forum. Looking it up, I discovered that this was the function I needed. However, using it took a more roundabout method than hoped.

When attaching an event to an element, you can only give the reference to the function, passing parameters is not allowed. To pass event.srcElement to the event that I was attaching I needed an anonymous function. Let me illustrate with code:

For standards compliant browsers:

textareas[i].addEventListener(’click’, selectText, false);

For Internet Explorer:

textareas[i].attachEvent(’onclick’,function () {
IEselectText(event.srcElement);
});

Got There In The End

Here is the code I finally produced, with a little example of how it works.

So, if you want to use this don’t forget event.srcElement.

(Unless there’s a much better way, but I spent a good while searching for this and I didn’t get anything better!)

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.