456 Berea Street

Google to webmasters: Write clean HTML and consider accessibility

Roger Johansson — 2008-10-07T20:46:41+01:00

I suspect that the recent release of Google Chrome, based on Webkit, has at least something to do with the Google Webmaster Central Blog post Workin' it on all browsers. In the post webmasters are encouraged to make sure their sites work regardless of what browser their visitors use, and Google is likely interested in websites working properly in their own browser.

The blog post points to an article in the Webmaster Help Center called Making sure your site appears properly in different browsers. That article contains four main tips:

Test your site in as many browsers as possible
Write good, clean HTML
Specify your character encoding
Consider accessibility

All good advice of course, though obviously there is a lot more to be said about good HTML and accessibility than what is brought up in the article. Nevertheless it's good to see this kind of information on Google where it may reach people who would not otherwise bother writing proper HTML and CSS or consider accessibility at all.

Posted in Accessibility, Web Standards.

Multiple form labels and screen readers

Roger Johansson — 2008-09-30T18:24:23+01:00

Just about every website needs some forms. Sometimes there are many of them, sometimes just a single contact form. Regardless of their number, they need to be usable and accessible, which can sometimes be a little more work than it would be if theory and practice aligned a little better.

Say you have a simple form with an input field whose value needs to be validated, either by a JavaScript running in the browser or by a script on the server (preferably both). When the data entered by the user does not match what is expected, you need to notify the user somehow.

For sighted users this is generally not a problem. If you output some text stating what the problem is and highlight it visually, most people will notice it. For screen reader users it's a little more tricky though.

To make sure that the screen reader associates the message with the correct input field, the text should be in a label element that is explicitly connected to the field. No problem so far actually, but then the designer tells you that it has to look differently. The validation message should be below the input field instead of next to the label text. Or it should be next to the input field, or some other location not directly adjacent to the label text.

You start fiddling with extra markup, absolute positioning, negative margins, and end up with something that seems to work reasonably well. Until you resize the text, at which point things get misaligned.

You may be able to find a half-good solution that works within certain constraints, but if you've been down this road you probably get the point. Positioning error messages this way is fragile. It would be so much easier if you could just put the error message in a second label element associated with the input field.

Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification:

The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.

The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.

Sounds great, doesn't it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work...

Unfortunately, and perhaps unsurprisingly, it looks like it doesn't quite work as well as you'd hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it's worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy.

I am far from an expert user when it comes to screen readers, but I've done some limited testing with mostly disappointing results.

Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document's source order.
JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus.
The only screen reader of those that I tested that does handle multiple labels is Fire Vox.

The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.

A couple of years ago, Bob Easton set up a multiple label test case that reveals similar results, discussed in Speaking form labels - Summary.

Sorry to write at such length about something that appears to have no practical use. I just wanted to highlight a case where I think screen readers following the HTML specification more closely would help web developers to increase the accessibility of HTML forms they don't have full visual control of.

Posted in (X)HTML, Accessibility.

Turn Firefox into a screen reader with Fire Vox

Roger Johansson — 2008-09-23T20:38:19+01:00

I've sen Fire Vox mentioned plenty of times but have never had any luck getting it to work on my Mac. Until now, that is. Not sure what I've been doing wrong the other times I have tried it, but the other day I gave it another shot and it worked without any problems.

For anyone who hasn't heard of Fire Vox, it is a free, open source screen reader extension for Firefox that works on Windows, Mac OS X, and Linux. Among other things it has support for WAI-ARIA and the CSS3 Speech Module, and is a good alternative to VoiceOver if you're on a Mac and need a screen reader for web browsing (or testing).

One thing that had me a little bit confused at first is that, at least as far as I can tell, you need to tab into a freshly loaded page before the "Auto Read" option (Ctrl + Shift + a) will work. Read Next (Ctrl + Shift + f) and Read Previous (Ctrl + Shift + d) work even if the focus is still in the location bar. Not sure if that is intentional or not, but if you load up a site and nothing happens when you press Ctrl + Shift + a to have Fire Vox read the entire page, try using tab or (Ctrl + Shift + f) to move keyboard focus to the loaded page first.

For developers Fire Vox makes it easy to check how their sites work in a screen reader. Sure, it's just one of several available screen readers, but this one is free and cross-platform. In other words there is no reason for you not to have it installed, so grab a copy right now.

Posted in Accessibility, Browsers.

Opera Web Standards Curriculum: A "do things the right way" learning resource

Roger Johansson — 2008-09-16T18:41:54+01:00

In July the Opera Web Standards Curriculum (WSC) was launched. It is a great initiative that aims to provide a free course for anyone who needs a thorough introduction to the web and how to create standards-based and accessible websites.

The WSC consists of a large number of articles covering topics, including the history of the web, graphic design for the web, HTML, CSS, and accessibility. At the time of this writing 23 articles have been published, with many more to come.

The editor, Chris Mills, asked me if I would be interested in writing a few articles. I said yes, but unfortunately I soon realised that I did not have enough spare time to write as many WSC articles as I would have liked to. My single contribution to the WSC is Choosing the right doctype for your HTML documents. Considering the quality of the articles written by the other authors I think my lack of time may have been for the best.

For a long time I've missed having something like the WSC to refer people to when they ask me where to start learning about modern web design and development, so it's great to finally have a place to send them to.

Even better, the entire course is Creative Commons licensed to allow universities, companies, and other organisations to use it freely.

Know someone who needs to catch up with Web Standards? Help make the web a better place by referring them to the Opera Web Standards Curriculum (WSC).

Posted in Web Standards.

Signs of life

Roger Johansson — 2008-09-04T20:30:23+01:00

As you may have noticed it's been over three months since I last posted anything here. Just in case you missed it, the reason is that I have been on parental leave. Well, as of this week I am now back at work, and hope to start posting reasonably regularly here again within the next few weeks.

There will be a few changes compared to how things have worked here in the past. Time is becoming more and more precious for me, especially with a one-year-old to take care of, and I need to find ways to remove as many time eaters as possible. One of those time eaters is - unfortunately - comments.

Yeah, I know. I have said in the past that comments are very important here and on other blogs, and I still think they are. But managing comments, whether they are positive or not, takes a lot of time and effort for me, so I am going to disable comments for the time being.

Others have argued for not allowing comments on blogs, and Jeremy Keith sums it up pretty well in Commentary. I used to partly disagree with what Jeremy and the others he is quoting are saying, but I have changed my position on this. Thank you to all readers who have taken the time to post constructive, thoughtful and encouraging comments through the years. I really appreciate it, but from now on there will be no comment form at the end of each post here.

Another thing I want to do is simplify. The design, the code, the publishing system, my writing process, everything that has to do with writing and posting content here. I really want to have a stable setup that lets me focus on writing instead of worrying about pixels or scripts or databases. I am also going to (try to) stop worrying about things being broken in inferior browsers. I get quite enough of solving IE CSS bugs at work, so I am going to minimise the time I waste on it here.

These simplifications will be a work in progress, so if you see anything that is broken or experience any other kind of hiccups around here, it's most likely caused by me changing things and will (hopefully) be temporary.

Or not.

Posted in Life.

Temporary absence

Roger Johansson — 2008-05-21T19:29:50+01:00

For the next few months I will be on a combination of parental leave and vacation. Well, that isn't completely true since I still have one week of work to get through, but when June comes around it's time to switch off and unplug my computer.

That isn't entirely true either. I won't actually be unplugging my computer all the time, but I will not be checking my email regularly (i.e. don't expect a response if you send me email) and I will try hard to avoid reading any blogs or keeping up with what's new in the world of web design and development.

The current plan is to return some time in September, but don't take that as a promise. Neither do I promise not to break the silence if something that calls for a quick post shows up ;-).

See you later, hope you stay subscribed, and thanks for reading.

Posted in Life.

Validation statistics from Nikita the Spider

Roger Johansson — 2008-04-29T19:44:40+01:00

About a year and a half ago I mentioned Nikita the Spider: a bulk validation and link checking tool as a useful quality assurance tool. Well, Nikita the Spider has received a lot of fixes since then and has recently been taken out of beta. It is no longer completely free, but the first 125 pages it crawls will cost you nothing.

But what may be more interesting is what Nikita finds when it crawls a site. Philip Semanchuk, Nikita's author, has analysed the statistics Nikita collected during March 2008 and walks you through the results in By The Numbers – March 2008. A few highlights:

The most common validation error is neglecting to specify an alt attribute for img elements
The second most common error is failing to escape ampersands
XHTML doctypes are much more common than HTML doctypes
Over sixty percent of the crawled pages use a transitional doctype

Of course these statistics are only representative of a very small sample of the pages that exist on the web. In addition to that, those pages live on sites that somebody has actually asked Nikita to crawl, so it is likely that they are more aware of web standards than the average website owner/author/developer.

It's still interesting reading though.

Posted in (X)HTML, Web Standards.

Authentic Jobs API and Affiliates program

Roger Johansson — 2008-04-26T10:10:16+01:00

If you've been looking for a new job or looking to hire a skilled web professional you may have come across Authentic Jobs. You may also have noticed that there have been Authentic Jobs listings on this site for some time.

The news is that now anyone can display job listings on their site. You can also make some money when someone you refer posts a listing on Authentic Jobs.

To display job listings you will need to apply for an Authentic Jobs API key, and once you have that you can start doing all sorts of with the job listing data. Find more details on that in The Authentic Jobs API Documentation.

Even if you don't want to display job listings you can become an affiliate by applying for The Authentic Jobs Affiliate Program. Once you're approved you will get a personal code that you can use when referring people to Authentic Jobs. For each new full-time listing posted as a result of your referral you will get USD 75, and for each freelance listing your award will be USD 25.

If you're completely new to Authentic Jobs, it is "a targeted destination for standards-aware designers and developers and the companies seeking to hire them." In other words, it is a place where companies looking for modern web professionals can find talent.

Posted in Job openings.

What does Acid3 mean to you and me?

Roger Johansson — 2008-04-01T09:59:14+01:00

So, last week two browser vendors proudly announced that their rendering engines now achieve a 100/100 score on the Acid3 Browser Test: Opera (Opera and the Acid3 Test) and Apple (WebKit achieves Acid3 100/100 in public build).

Getting a 100/100 score does not mean that the browser has completely passed the Acid3 test, since there are other criteria as well - the animation has to be smooth and the final page has to be a pixel perfect match of the reference rendering. Despite that, it's great news to see browser vendors in a battle to implement standards first. Too bad the biggest two in terms of market share - Firefox and Internet Explorer - didn't take part in the Acid3 race.

What I'm wondering is if, how, and when, this will help Web designers and developers like you and me. How long will it take for the other vendors to catch up enough that the standards that are tested by Acid3 can be used reliably? And what parts of the Acid3 test checks stuff that we really can't wait to use?

What's your thinking on this?

Posted in Browsers, Web Standards.

Designing Web Navigation (Book review)

Roger Johansson — 2008-03-19T19:50:31+01:00

What? An entire book just about designing navigation on the Web? Yes, that's right. And if you think about it for a while you'll probably realise that there is a need for a book on that subject. Heck, considering the number of sites out there that are incredibly hard to navigate, there is room for plenty of books that explain how to create Web navigation that works.

And you're very likely to have run into problems more than once when trying to figure out how to make a website or Web application easy and intuitive not only for yourself, but for your own or your client's end users, to find their way around. Designing Web Navigation by James Kalbach aims to help you master the fundamentals of navigation design. While there is no guarantee that you will master the subject, reading this book will definitely give you a lot of insight into the problems that you encounter in navigation design as well as possible solutions to those problems.

The way Designing Web Navigation is structured makes it usable not only as a book you read from cover to cover, but also as a reference to keep handy for the next time a tricky navigation problem shows up. It can also give you arguments to use in discussions with clients or other team members when there is something that doesn't feel quite right about the solution somebody is suggesting but you can't put it into words. In fact, it may also make you look at the problem from a different angle and realise that maybe your solution isn't the best one.

The author starts the first part of the book by explaining the foundations of Web navigation. Those foundations include why we even need navigation in the first place, how we use Web browsers to interact with websites, the most common types of navigation on the Web, and how we can label navigation to make it easy to understand.

The second part of the book is called "A Framework for Navigation Design", and is focused on providing you with a systematic approach to designing Web navigation. It does that by describing a number of phases that you will often move through while turning a concept into a working navigation system.

In the third and final part, James Kalbach takes a closer look at navigation in special contexts, such as before and after searching, in social tagging systems, and how Web applications can be navigated.

Throughout the book there are many references to accessibility and internationalisation issues that can be caused by some types of navigation. It's great to see that those two very important aspects of Web navigation aren't overlooked here as they are in many other places.

Overall this is a great book that I enjoyed reading. The examples and references are current and credible. One area that has room for improvement is the layout and typography, which I think could be more usable. Line-length is a bit too long for the book to be a really comfortable read, and page numbers are smaller than the text on websites designed by ad agency art directors.

But don't let that discourage you from picking up a copy of this book. My impression is that there is a lot of research behind this book, and I think all web designers and front-end developers can learn something from it.

Designing Web Navigation: Author: James Kalbach; ISBN-10: 0596528108; ISBN-13: 978-0596528102

Posted in Reviews, Usability.