The cause – but not the fault – lays with Eric Meyer’s original CSS reset, subsequently included in the YUI CSS framework, among others.

Eric warned that he didn’t “recommend that you just use this in its unaltered state” but people did so anyway. Including the code:

:focus {
  outline: 0;
}

The problem became so widespread that Eric has apologised for it, even though it wasn’t his fault people ignored his advice! In the second version of his reset, he removed the code above.

At Soupgiant, we take a two-fold approach to link focus styles. We leave the outline in place because users have come to expect it. To increase the contrast of focused links further, we reverse the foreground and background colours too.

a:link, a:visited {
  color: #00f;
  background: transparent;
  text-decoration: underline;
}
a:focus {
  color: #fff;
  background: #00f;
  text-decoration: none;
}
a:hover, a:active {
  color: #00f;
  background: transparent;
  text-decoration: none;
}

While it seems we are doubling up on some code, it’s a necessary evil as multiple pseudo-classes can be applied to single a link at once (for example: :hover and :focus).

For the cost of a few extra bytes, we believe it adds significantly to the usability of our sites. For that reason, we’ve included it in Minimum Page: our reset-free, CSS starting point.

The only computers my parents have ever used are Windows machines. They call viruses “bugs”. My father still complains about the purchase of a seemingly unnecessary maths co-processor in 1990. My mother writes down all the instructions I give her and follows them one by one. These are not people to whom computer technology naturally presents itself as being in any way obvious to use.

Add to that the fact that my parents both have English as a third language and the need for clear and obvious instructions or steps is even more understandable.

So it was important to me to see how they attacked the problem of setting up a new iPad armed with only the box it came in. I filmed them as they went through the process trying as much as possible to be an independent observer. I wanted to uncover answers to two main questions:

1. Are the things we consider to be user-friendly really that obvious?
2. What are the barriers to entry for someone who wants to use technology but regards it with suspicion?

They opened the iPad box to reveal the following 5 separate pieces:

• the iPad itself
• a USB cord
• a power supply
• an Australian power plug adaptor
• an envelope which itself features:
  • a pin clipped to the outside
  • a card with a picture of an ipad on one side
  • warranty information
  • apple stickers

That was it. No instructions that they could see.

They shuffled through all of the documentation in the envelope and couldn’t find any instructions. There are instructions on the back of the card with the iPad on one side but it took a while to notice them.

In all the “unboxing” videos and photo collections I’ve seen, nobody ever looks at the back of that card.

The first instruction is to download iTunes.

Dad didn’t want iTunes. He wanted to use his iPad. He had no intention of using it to play music.

For someone suspicious of technology this is enough of a barrier. There is no explanation of iTunes being the software that will prime the iPad. iTunes is a music player.

All my parents needed was a preceding line that said “You will need iTunes to set up your iPad” and their suspicion would have been subdued. The assumption Apple made, however, is that people will follow instructions without explanation.

When building websites we often assume that what we have designed is obvious. It might be obvious to someone who has used similar things before but what about someone who has never used it before?

We deal with usability every day. We hope that the things we create work for everybody who uses them. In the box for iPad 2, Apple provides the instruction for what to do next but not why it should be done. People should be suspicious when a corporation, website or person tries to force trust and faith.

There are other moments in the set up when this happens. It happens with accepting the iTunes EULA. Apple pretends to offer a choice but it’s really just dictation. Accept or don’t use the $900 device you just purchased. That’s the choice.

Of course, this sounds a lot more sinister than it probably is but it’s so easy for bad instruction to feel like being ordered rather than guided. That is something we need to keep in mind when designing for usability. Sometimes there is no choice but if we are given reason then lack of choice is so much easier to swallow.

Update: 9 June 2011

Apple are trying to improve this experience with a no-computer no-itunes set-up process with the impending release of iOS 5.

Engaget has screenshots of what the process will look like. Turn it on and get a set-up screen. Now that’s more like it.

(Thanks to @adnrw for pointing this out.)

Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.

Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.

I really tried to adopt the commonly advocated view that it’s okay to require website visitors have JavaScript enabled. It was going very well, right up to the final hurdle when I couldn’t resist checking the site I was working on without JavaScript.

Everything looked fine in Chrome, Firefox, and Opera. It was, predictably, Internet Explorer that threw a spanner in the works. For an artist’s impression, visit the demo in IE8 (screenshot via WebPageTest):

HTML5 as seen in IE8

Without Remy Sharp’s HTML5 enabling script the site I was working on was unusable, if anything, it looked worse than the demo provided.

I couldn’t, in good faith, sell a website to a client that some visitors would find unstyled, half styled or difficult to follow in places. I didn’t want to throw out the baby with the bathwater, the additional meaning provided by HTML5 elements is just too great. <header>, <section>, <nav>, <article>, etc all provide meaning to a document that it’s difficult to justify going without.

It’s with the additional meaning in mind that I decided to go with – what I’ve dubbed – HTML4.5. HTML5 provides the meaning while using traditional HTML 4 tags as hooks for styling. It introduces a bit of tag soup, as instead of <article id="content"> ... </article> the code becomes <div id="content"><article> ... </article></div>.

The improvement to site I was working on was immediate, as you can see by visiting the html4.5 demo in IE8 (screenshot via WebPageTest):

HTML4.5 as seen in IE8

I don’t care about tag soup

If given the choice between an unusable website for some visitors or a little tag bloat, I’ll take the bloat any day of the week. In the demo the bloat adds an extra 14 bytes. On the home page for the site I was working on, it’s 40 bytes. I save plenty more than 40 bytes by minimising my JavaScript and CSS (a single key combo with the YUI Compressor TextMate bundle), so I’m not too concerned about the side effects.

A technically beautiful site is the ideal but if a portion of your visitors can’t use it, then the beauty isn’t even skin deep. As Drew McLellan said recently on 24 ways, progressive enhancement is “also known as doing our jobs properly.”

According to the fangs plugin, the JAWS screen reader reads the opening of Soupgiant.com as:

Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer Heading level one Link Graphic Soupgiant vertical bar Web Production Heading level five Heat and Serve Combine seventeen years of web production experience, twenty years of television and radio experience, put it all in a very large pot on a gentle heat. Stir regularly and serve. Soupgiant goes well with croutons and a touch of parsley.List of five items bullet This page link Skip to Content bullet Link Home bullet Link About bullet Link Contact bullet Link Folio

- my emphasis

That’s a lot of content to get through, on every page of the site, before the Skip to Content link. It would be much better if the skip to content link were earlier on the site.

As the HTML title of the page is read out by JAWS, the best position would be before the in-page title. The opening content would then read as:

Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer This page link Skip to Content Heading level one Link Graphic Soupgiant vertical bar Web Production

- again, the emphasis is mine

That gives the JAWS user the title of the page and immediately allows them to skip to the page’s content. I don’t read the header of on every page of a site, nor should I expect screen reader users to.

I realise screen readers most likely have a feature to skip around the page relatively easily, regardless of how the page is set up but our aim should not be relative ease, our aim should be absolute ease.

As a result, we’ve decided to move the skip to content links on future sites to earlier in the page.

Sadly, this revelation came up as a result of what I consider to be a limitation of the WordPress 3.0+ function wp_nav_menu, the inability to add items at the start of the menu. I should have considered the accessibility implications much earlier. It serves as a reminder, to all web developers, that we should constantly review our practices and past decisions.

If you’ve recently changed something you’ve always done, we’d love to hear about it in the comments.

While neither the xHTML nor the CSS on this site validates, we consider it to observe best practices.The HTML fails validation due to the following problems:

• One of the WordPress plugins we use on the site inserts JavaScript with unencoded ampersands in the URL. This isn’t a best practice but unfortunately it’s beyond our control;
• The <html> tag has a class attribute;
• Two of the fields in our comment form have an unrecognised value for the type attribute.

The CSS fails validation due to the following problems:

• We load the YUI 2.7.0 CSS reset, base and fonts files from the Google AJAX API servers. These files contain star hacks for IE targeting;
• We use browser extensions to implement CSS rounded corners and rgba backgrounds;
• Until I started writing this post, we styled a heading with font-size: 145.4545%%.

That last one was a typo, and has since been fixed.

Justifying the invalid CSS

We’d prefer to avoid the star hacks in YUI’s CSS. If we self-hosted the files they’d be moved into the CSS files with our other IE specific hacks and targeted with conditional comments. Our compromise is to load the files from Google’s server with the aim that our site will load faster. Either the user will already have the files in their browser cache, or the user will load the files from a closer, faster server on Google’s global network.

The W3C’s CSS validator also screams at us for using CSS3 browser extensions and rgba backgrounds. While the browser manufacturers are still trying out their implementations of the new specs, we’ve no choice but to use these for the time being. As they iron out their implementations and move them over to the specified properties we can remove these. CSS3 junkies could probably have skipped this paragraph.

Justifying the invalid HTML

This site uses xHTML. We’ve discussed using HTML5 but WordPress, which powers Big Red Tin, isn’t ready to drop the /> from self closing tags. At this stage the HTML5 spec is too dynamic for our liking. Have a late afternoon snooze and the spec is likely to change during your siesta.*

Depending on your point of view, and even what you are coding, it is either fortunate or unfortunate that browsers don’t always follow specs to the letter. We’ve taken advantage of that to throw one of the biggest advantages of HTML5 into our xHTML. In our comments form, we’ve used HTML5 type attributes for two of our fields: <input type=”email” … /> and <input type=”url” … />.

In browsers that do not support these types of inputs the type falls back to the standard of type=”text”. In browsers that do support input types of email and url, it prevents the user from entering an erroneous value. For users of the iPhone or iPad, a special keyboard is presented to make entering an email address or URL easier. In browsers that support the new HTML5 input types, the behaviour is identical regardless of the doc type.

The iPhone displays different keyboards for HTML5 input types

It may be breaking some of the rules of standards. To me it’s not so much about standards as best practices and giving the user the best possible experience on a site, even if this means breaking the rules sometimes.

Don’t take that to mean that we’ll be reverting to table layouts, or insert code such as <a href="#"><h1>Heading</h1></a> into our xHTML. It’s bending the rules around the edges, which is no different to using vendor prefixes to make use of CSS3.

*Yes. I know this is an unfair characterisation. A lot of very important people, with very important lawyers, are working hard to change this.