Web Standards Planet Freshly Syndicated Standards

Common knowledge to most who have been working with CSS for a few years, but perhaps not something that relative newcomers have come across yet: the order in which you define the different link states affects the end result.

I prefer the following order: :link, :visited, :hover, :focus, :active.

Eric Meyer explains why the order matters and why he also prefers defining the states in this order in Link Specificity, Ordering the Link States, and Who Ordered the Link States?.

Posted in CSS.

One large group of people with special needs that is often overlooked – even by those who make an effort to build accessible websites – is dyslexics.

A good way to learn more about dyslexia, how it can make it hard to use the web, and what you as a designer can do about it is to read Mel Pedley’s article series on designing for dyslexics:

• Designing for Dyslexics: Part 1 of 3
• Designing for Dyslexics: Part 2 of 3
• Designing for Dyslexics: Part 3 of 3

You will also find some useful tips in a presentation by Jonathan Hassell on Dyslexia that was held at the Scripting Enabled conference in London in September.

Posted in Accessibility.

Jeffrey Zeldman recently posted Is your (website’s) underwear showing?, which is a reminder about one of my pet peeves – websites that don’t specify a background colour but have a design that relies on all browsers having a white background. When the browser background is set to something other than white, some sites look really… interesting :-).

This has been happening since forever. Back in the late 1990’s those of us who used Netscape on Macs saw a lot of it since Netscape on the Mac had a grey default background colour while Windows browsers used white. And back then “nobody” checked their sites on a Mac.

In case you don’t feel like changing the default background colour of your web browser but still want to see how strange sites can look, check out the Flickr pool Underwear showing (web design).

The solution to this is very simple: if your site is meant to have a white background, specify a white background in the CSS. It will cost you at the most 23 characters:

1. body {background:#fff;}

Better yet, make sure the CSS you use as a starting point for new projects specifies a colour for both text and background. That way you’ll never forget to do it.

Posted in Accessibility, Graphic Design, Usability.

I do quite a bit of quality assurance work, specifically looking at the accessibility and web standards use of websites. In many cases I make remarks about the use of alternative text for images and other graphic elements.

It is, not surprisingly, common for alternative text to be completely absent, but it is probably even more common to see inappropriate use of the alt attribute. In most cases this is caused by well-meaning people using the alt attribute to describe the image itself instead of the function it has or the content it presents.

Two rules of thumb I use when writing alt text for images are these:

• If you were to describe the document to someone over the phone, would you mention the image or its content? If you would, the image probably needs an alternative text. If not, it should probably have an empty alt attribute.
• Does the alternative text of any images in the document make sense if you turn off the display of images in your web browser? If not, change the alternative text so it does make sense and does not provide redundant information.

These are just rules of thumb and there are exceptions, but as a general rule I have found that they work well.

In practice this means that images should often have empty alt text, alt="". Be aware though that if the image is within a link that does not also contain descriptive text, the image needs an alt text that describes the link.

Much more detailed instructions for writing alt text are available in an article at WebAIM called Appropriate Use of Alternative Text.

Posted in (X)HTML, Accessibility.

When reviewing websites to find areas that may be improved, one of the things I look for is whether any JavaScript has been implemented in an unobtrusive way or not.

I normally do that by turning JavaScript on and off, and viewing the source code. It can be a bit tedious. But now there is a quicker way to find obtrusive JavaScript: Robert Nyman’s Obtrusive JavaScript Checker.

The Obtrusive JavaScript Checker will examine the web page you are on and highlight all elements that have inline events or javascript: links, making any obtrusive JavaScript really easy to spot.

Obtrusive JavaScript Checker is available both as a Greasemonkey user script, a Ubiquity command, and as a Firefox extension. I don’t use Greasemonkey or Ubiquity, so the Firefox extension is my favourite.

Posted in JavaScript.

The Web Content Accessibility Guidelines (WCAG) 2.0 is currently in W3C Proposed Recommendation status and may be advanced to W3C Recommendation status before the end of this year. To prepare for this it’s time to start reading up on WCAG 2.0 if you haven’t already.

A good start may be the Overview of WCAG 2.0 Documents compiled by the W3C WAI. The WCAG 2 FAQ and How to Meet WCAG 2.0 documents may also be worth your time.

To help people who are familiar with the checkpoints in WCAG 1.0 make the transition to WCAG 2.0, the W3C has published a document (currently a draft) with a Comparison of WCAG 1.0 Checkpoints to WCAG 2.0. A similar document is Roger Hudson’s Migrating from WCAG 1.0 to WCAG 2.0. Read both and you should get a good overview.

Posted in Accessibility.

Character encoding can be wickedly difficult to get right, especially when you want to start using UTF-8. It seems there is always at least one part of the chain from your brain to the end user’s browser that has problems with UTF-8.

Two articles that try explain character encoding are The Definitive Guide to Web Character Encoding and UTF-8: The Secret of Character Encoding. I won’t pretend to fully grasp character encoding, but after reading these articles I believe I at least understand it a little better.

Posted in Coding, Web Standards.

One of the more problematic areas of web accessibility is how to handle the custom widgets and dynamic changes to content used in most web applications and on many content-based websites.

Using JavaScript to add custom behaviour and update content can cause problems for people who rely on assistive technology (AT) such as screen readers. The problems often consist of the AT not being aware that content on the page has changed, the user not noticing that something has changed, or the user being aware that something changed but not what.

These problems can be tricky to solve, but there is hope in the form of Accessible Rich Internet Applications (WAI-ARIA). From the WAI-ARIA Overview:

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

I have only just started reading up on WAI-ARIA, but it looks very promising. It is also time to start using it to improve the accessibility of web applications that make heavy use of JavaScript.

Since I’m a WAI-ARIA novice myself I won’t try to explain the details of how to use it. I can offer you plenty of links to further reading though:

• Accessible Rich Internet Applications (WAI-ARIA) Version 1.0
• WAI-ARIA Overview
• Introduction to WAI ARIA
• Speeding adoption of WAI-ARIA
• ARIA Plugins for YUI Widgets
• Free ARIA Community
• AxsJAX
• access.see.be, WAI-ARIA based Accessibility Library
• Examining WAI-ARIA Live Regions
• ARIA momentum and Internet Explorer
• Accessibility of Rich Internet Applications

Posted in Accessibility, JavaScript, Web Standards.

Validating the markup of a single page is quick and easy – either install the HTML Validator Extension and get instant feedback in the status bar or use the Tools - Validate HTML option in the Web Developer Extension. But what about validating an entire site to find errors that could cause problems for your visitors (or your clients’ visitors)?

When I recently upgraded this site to the latest version of Movable Type I also wanted to find and fix any errors that had snuck in, either through mistakes of my own or via comments (posted before I implemented HTML validation of comments). Instead of spending hours and hours manually checking each of the approximately 1 800 pages I wanted to find a tool that will index and validate an entire site.

It’s possible to use the instructions provided in Validating an entire site to set up the W3C validator locally and make it check an entire site, but I had problems making it work. Not being in the mood for that kind of problem solving I wanted to find something that just worked.

Luckily I didn’t have to spend a lot of time looking since one of my colleagues told me about the Free Site Validator, a free service that does two things:

• it crawls the site and validates all pages with the W3C validator
• it checks all links and reports any that are broken

I’ve used it to check this site and found a bunch of pages that contained validation errors (some of which badly messed up the rendering in some browsers) and many that contain broken links to other sites. Any validation errors that aren’t intentional or impossible for me to do anything about should now be fixed. I haven’t had time to fix the 924 broken links yet though, and I’m not sure when – or even if – I will get around to doing that. Thank you, Link rot.

Posted in (X)HTML, Web Standards.

Screen readers don’t always work as well with JavaScript as you might want or expect them to. But what exactly is it that doesn’t work?

I’m not screen reader-savvy enough to answer that in any detailed way, but others are. Check out JavaScript and screen readers by Aaron Cannon and Aaron Barker to find out more about how JAWS and Window-Eyes handle (or don’t handle) JavaScript events.

Posted in Accessibility, JavaScript.

As you might guess from the number of book reviews I have posted here, I like reading things printed on paper. Yeah I know, that’s so old-fashioned. But true.

If you feel the same about paper and would like to read more about web related subjects offline, take a look at Scroll Magazine, brought to life by Web Directions founders John Allsopp and Maxine Sherrin, and designed by Veerle Pieters.

Prefer reading on-screen? Buy the magazine in PDF format. Don’t want to pay at all? Wait until three months have passed since the paper issue was published and the articles come online in HTML format for free.

Posted in Web General.

A few weeks ago the WebKit team posted an update about the Web Inspector Redesign. I’ve been trying it out for a bit and really like what I see.

With this update, which currently is only available in WebKit nightly builds (both Mac and Windows) and not in Safari, the Web Inspector is turning into an excellent web development tool. In my opinion it isn’t quite comparable to Firebug yet, but it’s getting very close. At least for what I use Firebug for, which is mainly CSS debugging.

If we look beyond pure functionality for a while though, the Web Inspector wins hands down. Its interface is very polished and makes Firebug look a bit rough around the edges in comparison. That is my personal impression of course, so yours may differ.

Grab the latest WebKit nightly and check it out for yourself.

Posted in Apple, Browsers.

It's been almost five years since Movable Type 2.65 was released . Currently the latest version of Movable Type is 4.21. Yet version 2.65 is what I've been using to run this site up until a week or so ago.

I delayed upgrading partly because I did not feel like dealing with the unavoidable upgrade breakage, partly because MT 2.65 actually has been working pretty well for me - it does the job it's supposed to do.

Nevertheless I did not want to feel like an IE 6 holdout anymore. It was time to clean up the cruft that's been building up in my Movable Type installation over the years, take the plunge, and upgrade to Movable Type 4.21. And – you guessed it – I did run into some issues.

Minor problems with (mostly) easy fixes

To make a long story short there were some upgrading problems involving obsolete plugins, plugins that needed upgrading, and template adjustments. The problems I ran into were actually both fewer and less severe than I had feared, but I am happy that I got Movable Type set up locally on my Mac to test and fix everything before touching the live site.

As far as I am aware nothing related to Movable Type is broken around here (though if you come across anything broken, please let me know).

Use dirify? Beware of possible URL changes.

One tip that I'd like to give anyone else considering upgrading from a really old version of Movable Type is to keep an eye on how your entry URLs are created. I used to create each post's URL by using the dirify function: <$mt:EntryTitle dirify="1"$>. In more recent versions you're supposed to use <$mt:EntryBasename$> instead since there is no guarantee that the dirify function will always work the same (there wasn't much choice in 2.65 since the basename functionality was introduced in MT 3, if I am correct).

Well, it turned out that the latest version of MT changed one detail of the dirify function - it no longer removes hyphens from the input text. This meant that any post that had a hyphen in the title got a new URL after the upgrade. Ouch!

At first I thought I would be spending hours creating rewrite rules to avoid breaking incoming links, but luckily there is an easy way to fix this problem by way of the EntrySetBasename plugin.

The plugin contains a function that goes through all entries and sets their basenames to match the output from the old dirify function. I had to tweak the template code used with the plugin a bit to make it recreate the basenames for all of my old entries, not only those with hyphens in. When my ancient MT database was converted to the new format all entries got basenames, but they were limited to 30 characters which unfortunately is not enough for many of my posts. If you need to do the same, replace these lines:

1. <mt:if name="new_dirified_title" ne="$old_dirified_title">
2. <li>
3. <$mt:EntrySetBasename value="$old_dirified_title" test="1"$>
4. </li>
5. </mt:if>

with this:

1. <li>
2. <$mt:EntrySetBasename value="$old_dirified_title" test="1"$>
3. </li>

Anyway, the URLs should be fine now.

New admin interface

For someone coming straight from Movable Type 2.65 to 4.21, the difference to the admin interface is huge. Visually it is not even close to being the same CMS. In other words it takes a little while to get used to, but it's worth it.

Still liking Movable Type

Many people who used Movable Type back in the day have moved to other platforms. I have also spent plenty of time looking at other options (Wordpress, Textpattern, and Expression Engine to name a few), but I keep coming back to MT. One reason is that I know how to get absolute control of the markup and URLs it outputs, another that I really like how it creates static HTML (or PHP, or whatever you like) files of everything.

If you're looking for a blogging CMS, either because you're just starting out or because you're not entirely happy with what you are currently using, do give Movable Type a chance. You just might like it.

Posted in Movable Type, Site news.

The other day I mentioned a few Firefox add-ons that I have recently discovered. One add-on that I forgot to mention is NoScript, which I have been using for a few months now.

As the name indicates, NoScript blocks the execution of JavaScript in Firefox. But it isn't the same as simply turning off JavaScript support. NoScript gives you control over which sites are allowed to run scripts, Flash and other active content, and has tons of settings that will let you configure it to your liking.

NoScript is very popular – at the time of this writing it has been downloaded over 29 million times – so surfing the web with it installed (and thus JavaScript at least semi-disabled) is hardly a fringe case. Many people download and use NoScript primarily for security reasons, but my main reason for using it is that it makes many sites that normally are a pain to visit (mostly newspaper websites) much more responsive, quicker loading, and less intrusive.

Surfing the web with NoScript installed also makes it quite obvious which sites have not been built with progressive enhancement and unobtrusive JavaScript in mind. I don't know about other NoScript users, but I tend to leave sites that don't work pretty quickly unless they offer something I really need.

Posted in Browsers, JavaScript.

Looking to hire some web talent? Need a designer or a developer who keeps track of what's going on in the web world? In case you haven't already, give Authentic Jobs a try.

Right now there is a promotion that lasts until October 31 (this year ;-)) and will give you 30% off on both full-time and freelance listings if you use the promotion code BEREA31 when you create your job listing.

Should you not find the talent you are looking for there is a money-back guarantee that applies even if you use the promo code. In other words you have nothing to lose.

Not hiring but looking for a job? Check out the listings or subscribe to an Authentic Jobs listing feed to make sure you don't miss any of the opportunities that are posted.

Posted in Job openings.

I have recently discovered a few Firefox extensions that can be quite useful when building websites. They are likely old news to many, but I figure there are at least a few others who have not come across them.

• ColorZilla is a handy extension that makes it easy to grab colours from the web page that is currently open in the browser. It sure beats having to open a screen shot in Photoshop just to find a colour code for something. ColorZilla does some other useful things as well, so it is not just a colour picker.
• Firefox Accessibility Extension adds features that are useful to people with disabilities and helps developers evaluate accessibility.
• Screengrab! among other things lets you take screen shots of what is inside the browser viewport, without the browser chrome. I could have used this recently when I was taking a whole bunch of screen shots of various websites for an upcoming course on web development. Unfortunately I didn't know about it then so I used the built in screen shot functionality in Mac OS X and cropped the images to get only the browser viewport. Oh well.
• WAVE Toolbar lets you run the WAVE web accessibility evaluation tool inside Firefox, without sending any information to the WAVE server. Perfect if you're like me and spend a lot of time working on password-protected sites.

Posted in Accessibility, Browsers.

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.

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.

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.

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.