Recently though, I have been puzzled by people suggesting that we should use EMs for layout, for two main reasons:

• Browsers translate EMs to pixels anyway, so why add a layer of abstraction?
• It is actually difficult for users to change the text size in browsers these days, so why do people think that EMs vary in a useful way?

In this article from Cloudfour on EM media queries, Lyza Gardner notes that the EM based media queries worked with zoom (in Webkit) and not with pixels.

However, that’s a bug in webkit. If you try the same in Firefox/IE/Opera, pixel based media queries work great with zoom. It just happens that a webkit bug for zooming EM based media queries has had some work, but not for pixels.

We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.

If and when the bug in webkit is fixed, there would be no need for that maths, just note the pixel value!

Pixels (that is to say, CSS pixels) have always been a relative unit, but with new devices coming out that have higher (physical) pixel densities the relativeness is more obvious than ever.

There are some issues at the moment that can be worked around by using EMs, as shown in the Alistapart article. However, I think devices like the Kindle Fire are going to have to catch up and use CSS-pixels rather than hardware pixels. My Android phone does a great job of this, most websites have reasonable sized text and the site designers haven’t had to  jump through hoops.

Long term I bet that the pixel will be the most useful and consistent relative unit.

The people in the best position to decide what a (CSS) pixel should be on a device, are the people making the device. There are simply too many devices to test your website with; if web designers can’t rely on CSS pixels working across devices then those devices are going to loose out.

Device makers are going to have to make ‘normal’ sites readable and useful, so CSS pixels will need to be relative to the screen size rather than pixel density. This will be equally important on TV displays, where the resolution is quite high, but the distance from screen to eye is greater. So for TVs CSS pixels could vary by TV size even though they all have 1920 pixel wide resolutions (for HD screens).

Lets just make sure when we talk about pixels in web design, we are talking about CSS pixels.

Sidenote –  foreground pictures

Most things in web design scale to higher pixel-density displays nicely, for example, pixel sized text and css borders. Background images in the CSS can be adjusted with media queries, so you could have different background images depending on the pixel-density. (LukeW has some good resources on workarounds.)

Where the water is murkier is foreground pictures. We can scale down larger images with CSS, but that doesn’t affect the file size, so someone on a mobile connection might still get a 1MB image scaled down to 200px.

Something like Adaptive Images is probably the best solution to this at the moment, but I do wonder if it could be more automatic?

Progressive JPGs appear to offer a solution: You provide the biggest image as a progressive JPG (e.g. 3000px wide), and set the (CSS) pixels width in the HTML or CSS. The browser then downloads a sufficient amount of pixels to meet the device’s pixel density.

This thought was triggered by this example of photography on the iPad 3. However, to extend that idea, wouldn’t it be great if you could just use one image for every size from thumbnails up?

Having tried a quick test, unfortunately browsers (currently) download all the information, not just enough to fill the current size. Still, could it work? Is it worth considering?

To show the effect, take a recent responsive design such as the Boston Globe and zoom in. In Firefox, Internet Explorer or Opera and it behaves how I expected, the media-queries trigger and the layout adapts:

However, when you try the same thing with Chrome or Safari, the zoom works (text and images get bigger), but all within the same layout:

NB: I think it is around 200% zoom, but it may be a little off.

It gets even more obvious when you scroll down, as you have huge text in narrow columns.

Accessibility

It looks like a bug, but you might be asking what effect that has on accessibility? The main impact is on people with mild to moderate visual impairment who use browser controls to increase the visibility of websites.

The browser landscape has changed a lot in the last few years, including how browsers zoom. In ye-olde days most browsers allowed you to increase the text size. Now the default method across virtually all browsers is to “zoom”, which increases the size of everything.

Zoom works well for people who need things a bit bigger unless you immediately get horizontal scrolling. That is why responsive designs (which re-flows the layout at smaller resolutions) work well for zooming, because the layout adapts to the available width.

What is a zoomed pixel?

I don’t know what the root cause is, however, from a front-end development point of view it is as though Firefox and Internet Explorer increase the effective pixel size, so when you zoom in there are less pixels in the same area. Webkit does not seem to take the same approach.

It is not event-related, as reloading the page does not trigger the media queries (except the edge-case described below). Overall it is very odd, because the reported pixel size of the window does change, at least for JavaScript (test example).

Mobile Webkit uses a different style of zooming, as when you ‘zoom in’ the window stays the same, but your view zooms in without affecting the layout. I wonder if this is a conflicting method?

Another oddity is the difference when using EMs. I created a simple test case of max-width media queries in pixels and EMs. If you zoom in so the page reports less than 500px of width, neither triggers. However, if you then refresh the page, the EM based query (only) does trigger. Bizarre, but another facet to the bug(s).

I suspect that Google is aware of some issues to do with this, otherwise you wouldn’t get a red-banner warning if you zoom in on a Google Doc:

It might not affect many people at the moment (although that is debatable), but Chrome is rapidly gathering market share, so either it will affect people or it reduces Webkit browsers usefulness on the desktop.

I’m not in the Webkit browser world, so my question is: where’s the best place to report this?

Good points, and I certainly agree with not using HTML5 as the umbrella term.

However, I’m not sure Jeremy’s point that we didn’t need a catch-all term for “HTML4.01 plus JavaScript” is going to help. (We did have DHTML as an umbrella term. Ok, that is a tarnished example, but my point is that people still remember the acronym.).

Presumably the aim of the logo is to let (non-developers) know that a site is built with a certain set of technologies?

So the next question is: What should the umbrella term be?

I believe Eric Meyer has been using “Open web stack”, which is accurate and works with developers. However, I think we need something a little shorter and snappier (preferably an acronym of 6 letters or less that can be pronounced easily. Like AJAX.).

Something that combines W3C, open, web… the WOW stack? Maybe not, any other ideas?

We need something else, or HTML5 will become entrenched as the umbrella term.

A small part of StatCounter’s Global statistics for browser versions caught my eye:

You might remember from Jacob Neilson’s Alert Box that we were stuck with old browsers for three years:

With IE6′s plateau, it seemed like things were getting worse. Even Firefox (with more tech-savvy users, we assume) is taking the better part of a year to drop under 5% from the release of a new version.

The Google Way

But now there is a new browser in town, with a web application perspective. Let’s zoom in on Chrome, when it updated from Chrome 3 to 4. Light green is 3, dark green is 4:

In a month, Chrome 3 virtually disappeared (5% down to 0.3%), and Chrome 4 took off.

As a web developer: This is fantastic! No more waiting for users to download, they don’t even need to think about it. I don’t need to worry about having multiple browsers installed, because the general population can’t use old versions.

As a user: It’s great… until it breaks. Taking the choice away about when to update a program strikes me as dangerous.

The potential danger is very limited at the moment because Chrome is not bursting with pluggins and isn’t relied on by anything else. However, pluggins are becoming more popular, and upgrades that break web-apps could be a new problem.

We know how well Microsofts upgrades are received when they break things, if Chrome carries on gaining market-share, is it risking the same issues without even giving people the choice of when to update?

Update (August 2010)

This is a consistent approach from Google, the update from 4 to 5 happened just as quickly:

The line that chrome overtakes in July is IE6 by the way, so Chrome 5 is more popular than IE6 now.

At the end of its third week of availability, Google’s Chrome accounted for 0.77% per cent of the browsers that visited the 40,000 sites tracked by Net Applications, down from a 0.85 per cent share the week before.

On sites that I have access to, it’s varied between 0.4% and 2.6%, not particularly climbing or dipping. I heard of others having 8% on the first week after launch, dropping back to 1 or 2% the next week.

However, these sort of stats are probably missing the point, what sites is it that people are most likely to use Chrome on?

I suspect it is Google’s own sites, or rather Google’s applications.

It is an express aim of the browser to work well on their apps, and for people to be able to create their own ‘short-cuts’ to applications.

We seem to be moving away from ‘the blue E is the internet’, to application icons for Google Mail, Reader etc. Perhaps BaseCamp and others as well. That is what I now have on Windows at least.

EM based layouts becoming more popular?

Recently Dan Cederholm released his new layout ‘gridlasticness‘, an EM based layout that expands with your font-size choice.

I’ve looked at accessible layouts before, and bemoaned the fact that elastic layouts are mis-named. My main point was that font-based layouts will cause issues for people with visual impairments. When usability testing with people at RNIB centers, a fairly standard setup was an 800 or 1024 width screen, and large fonts.

That means lots of horizontal scrolling. In usability testing I’ve seen people get really frustrated with horizontal scrolling. Or when they don’t notice the scrolling, frustrated with trying to do things that should be easy, and are easy if you can see the right side of the screen!

This part of Dan’s post worries me:

Understand that when building an already-wide layout, it’ll get really wide, really fast. That’s OK. Wide is the new drop shadow.

If you’re someone that often needs to adjust your font-size, you’d be encouraged to tick the “ignore site’s font sizes” setting in IE (or use larger sizing in your prefered browser), and you would immediately get substantial horizontal scrolling:

I’m not singling out Dan here, font-based layouts are popping up in quite a few places, such as the new Odeon site. He just happened to draw my attention to it and mention the fashion aspect.

Now, I can understand giving a greater weight towards design aspects, and maintaining the grid (although I wouldn’t do the same). However, I find the timing curious, as these changes seem likely to be obsolete soon.

Browser zooming coming of age

Firefox 3 has a full zoom (rather than text-zoom), and you get pretty much the same effect as the EM based layout. Except that the browser zoom is often better, as (unless it’s a font-based layout), it can try and fit the page to the viewport.

In a very little testing, Opera’s version still seems more effective with the fit-to-width option enabled, and of course IE7′s trails behind with it’s linear-only zoom. (Side prediction: I suspect that IE8′s zoom will be better, but not when using IE7′s rendering.)

The bottom line is, that when these browsers are the mainstream, the differences between pixel and font-sizing becomes academic. Of course, I still find sizing layouts based on the viewport more robust over font or pixels methods, but when browser zooming is standard it will be more difficult to argue.

Ironically Simplebits old design using percentages works much better with zooming that fits-to width. What’s the big deal with font-based layouts, what have I missed?

Oh, and although I’m writing this article, much of the implementation (and Flash expertise) is from my colleague and co-author Tom Hooper. Any Flash questions will be directed his way!

Intro

Recently we re-launched our CMS’s site, defacto-cms.com, and with it a flashy (in both senses) case study selector. If this were a clients site it probably wouldn’t be worth the time for this purpose, but now the framework is in place it will be easy to replicate.

The ‘carousel’ navigation widget is only used in the case-studies section at the moment, and it is essentially local navigation for that section. You select a case study, it spins into the center, and if you select it the content below is replaced by that case study’s information. The visual effect is not 100 miles away from the iTunes ‘coverflow’ effect, although there are some subtle differences. It uses the Papervision3D open source ActionScript 3 engine for the 3D effect, plus a fair bit of scripting!

NB: Don’t use this in Safari yet! There’s a crash-bug we’ve discovered in Safari affecting the AJAX. You can load and play, but don’t select a case study with the Flash.

It is worth noting that we needed to use quite a recent version of Flash to get that effect (V9.0.28+).

What’s different?

I don’t think there is much new in terms of techniques, although I haven’t seen people use the content of a page as source for the Flash in this way before. It has also had quite a lot of attention in terms of bullet proofing and making accessible.

The foundation

The foundation is straight XHTML 1.0, and on a basic browser you get a list of links with images.

The HTML needed to run it is a container div, its content (used in the Flash), and an object which is used to configure the Flash element on the page. This is a very generic method that we will be using for any Flash content, but as an example, for carousel that skeleton is:

<div class="flash-object" id="landing-proposition-inner">
<h2>Websites powered by Defacto include...</h2>
<ul>
 <li><a href="page1.html">
<img alt="Organisation website screenshot" src="shot1.gif" />Organisation Name</a>
</li>
<!-- more items -->
</ul>
<object>
	<param value="/defacto/live/swf/carousel.swf" name="swfLocation" />
	<param value="200" name="height" />
	<param value="#0E3E80" name="bgColour" />
	<param value="url" name="sendMode" />
	<param value="9" name="reqMajorVer" />
	<param value="0" name="reqMinorVer" />
	<param value="28" name="reqRevision" />
</object>
</div>

What the scripts do

A JavaScript script is used to embed the actual Flash into the page, in broad strokes, the page loads and the script then:

1. Runs, if you have a fairly recent browser (we used jQuery, so it matches Yahoo!’s graded browser support table fairly closely).
2. Checks the version of Flash that you have, and either:
   • Replaces the content of the container div with the Flash, or
   • Adds a small “Would you like to upgrade your Flash” link.
3. If the Flash is added, the current URL and container ID is passed to the Flash.

The Flash then loads, then displays the carousel using the images and links from the URL and ID it was sent. When a case study is selected, the Flash calls a JavaScript function to replace the content of the page (using AJAX).

Reasoning

If I were you, there would be several questions going through my mind:

Question: Why use AJAX?
It prevents you having to re-load the Flash each time you view a case study. Even cached, it’s doesn’t load instantly, and this way you don’t have to sit through the initial animation again and again

Question: Flash has to load the page itself to get the content, why not pass the content from the JavaScript to Flash?
We tried that, but it seemed very CPU intensive, and given that the nature of the widget is already CPU intensive, we steered away from that. Although it may mean loading the thumbnails twice, they should be cached for the second load. In our initial testing, the caching/loading differed between browsers:

• Firefox loaded the page fully before the Flash, which is strange, so Flash gets the cached images.
• IE seems to load the Flash and page simultaneously, so the first request for the images is usually from Flash.

Technically as the images are removed from the page when the DOM is ready, they shouldn’t all load, but I can’t confirm this yet.

Question: Why not do the Flash version detection in the Flash?
In the case of Flash not being installed, you either get a warning from the browser, or a broken plugin display. There is also a problem with signposting users what to do next, as you end up with dodgy inaccessible buttons or messages in Flash. Since the AJAX interaction requires JavaScript anyway, we decided to use JavaScript detection to deliver a much smoother user experience.

Progressive layering / enhancement

The easiest way to describe the layering is to describe the progressive enhancement, i.e. what you get with what capabilities the browser has:

Basic browser (no CSS or JavaScript)

An HTML list (ul) of standard links that work and image thumbnails.

Standard browser without JavaScript support

An HTML list of links that work. (Images are hidden with CSS, as they are too big when you have the layout in place.)

Standard browser with JavaScript, but without the required version of Flash

An HTML list of links, and a little link at the bottom of the area suggesting you update Flash.

Standard browser with JavaScript and required Flash version

The Flash carousel version, using AJAX to load the content.

In the first version the “has JavaScript but not Flash” condition used AJAX to load the content, which seemed like a more even step. However, the accessibility and browser support issues mean that the weak point is really scripting (AJAX), not Flash.

Benefits

There are several advantages to this whole method that appealed to us:

• The method scales up. The first time we tested this was for a micro-site that replaced the whole site with Flash.
• Search Engine Optimisation (SEO). Since your content is well structured XHTML, Google doesn’t even know you’re using Flash.
• The presentation in Flash can be very different from HTML, even with the same source content. (Caveat: the more Flash elements you layer on top of the source content, the less flexible the content becomes.)
• Flash can call JavaScript functions to interact with other parts of the page, so you can still use (X)HTML when it is best suited to the content.
• You can have multiple Flash instances on the same page, each with it’s own variables.
• It is easy to turn on/off, bulletproofing the accessibility.
• No duplication of content, you don’t have to update two things.
• You can edit the content within any XHTML capable CMS.

I’ll repeat that for those at the back: You can edit the content in a CMS, not one coded specifically for editing Flash or custom XML files.

Obviously, you can’t add or change functionality, but in this case you can add case studies (links and their thumbnails), and in other cases you could change the content of pages (i.e. text and images).

Accessibility issues

We are tripping several alarm bells in terms of accessibility by using Flash and AJAX, but actually it wasn’t that hard.

The pages work fine without JavaScipt. The AJAX loads on a keypress of enter, so screen readers will generally update the virtual buffer. There could be a problem if the content takes a little while to load, but adding Juicy studio’s update buffer function should resolve that.

For the the Flash you just have to put in the work (and knowledge and testing) to ensure that it works with both visual keyboard access and with screen readers. You also have to work out what should be shown to screen readers in what order for it to make sense. We did find a bizarre bug in JAWs (8.0 original version) where the whole pages content was repeated when it entered the Flash, but applying the later patches to JAWs fixed that.

User control

One of the basic assumptions we accepted is that people may not be able to, or want to, use this feature. Therefore we added a “Disable scripts” option at the top. This essentially turns off the advanced scripted features such as the flash, but leaves the cosmetic ones in place (e.g. adding rounded corners).

This is very useful for older screen readers, which may understand just enough JavaScript to get into trouble. At the moment, it’s also useful for Safari, as we’ve encountered quite a severe bug when it encounters the AJAX function.

Usability additions

Usurping the innate page model of the web comes at a cost, some of which we’ve worked around. If you just use the Flash, it’s fine, but if you switch between navigation methods it’s a little clunky as the Flash is not reloaded.

The aspects we did work around were primarily changing the page title when you load a new case study, and providing a mechanism to get back to the index page (in the breadcrumbs).

We also made the visual aspect somewhat more HTML-like, so that a case study has underlined text “View case study”, then when you select it that disappears. Adding this made the keyboard/screen reader aspects easier to deal with as well.

Improvements still to make

There are a few things we would still like to adjust, the first of which has to be the Safari bug we’ve tripped. It actually crashes Safari! Unless we can track it down, we might have to add an “if browser is Safari then don’t run” type rule. JavaScript debugging in Safari isn’t that easy, and yes messieurs Christian & PPK, you can say “I told you so”. However, it would have taken an awful lot longer than we had (1.5 days on JS) to complete it without a library.

Although we’ve restored the titles to individual (AJAX) pages, we haven’t re-enabled bookmarking of individual pages. Although search engines will have no trouble finding the pages, people will have difficulty bookmarking individual case studies.

I’m also not convinced that the double click aspect (i.e. one to move the case study to the center, a second to select it) is the way to go. Some people expect the first click to select a new page, some don’t.

Which did you expect?

One tiny little point I wanted to pick up on was whether it was a waste of time to update AJAX content if you’ve attached an event to an element that isn’t a link or form control. The reason being that you can’t tab to these elements anyway so they aren’t keyboard accessible.

However, there is a trick I uncovered out a few years ago, that has since been included into the ARIA spec: tabindex="0"

I used a value of -1 originally (around 2002?) to prevent screen reader users getting caught in Flash, as before the accessibility improvements you could easily get stuck in Flash elements.

However, although not strictly legitimate HTML (from memory values are supposed to be from 0 and up), it functions as a cross-browser mechanism for allowing keyboard focus.

Based on Steve & Gez Lemon’s work, I created a little test-case that uses a simple paragraph that you can tab to and select (with the ‘enter’ key), or click on it to activate.

This actually works quite well across some browsers now: IE 5.0+, and Firefox 1+. (It also works with Safari & Voiceover, although you have to be told to select it, there is no notification.)

If other browsers support soon, the principle is:

No tabindex

Default (current) behaviour of the element.

tabindex="-1"

Not in tab order, but is focusable via scripts.

tabindex="0"

In tab order based on the location in the source order.

tabindex="30" (any number over 0)

In tab order at the specified location, before anything without tabindex or with a tabindex of 0.

To be clear, it probably isn’t a good idea to use this, any command the user can select should probably be a based on a link or form control such as a button. Also, changing the tab order by using positive values is often very confusing, as it won’t match the reading order of the page. Still, a useful little trick to have in mind.

I almost mentioned this technique at the presentation, but Steve was so let down by technology (JAWs and projectors don’t mix!) it seemed ungrateful to do so. Plus I wanted to check it worked first.

Sizing, layout and colours

Text sizing vs zoom

Text sizing is easy to set, easy to adjust, and easy to break a web site by making adjustments!

The site’s responsibility is to ensure that the layout copes with an increase in text-size, which has been made part of WCAG 2. (In hind site, 200% of very very small isn’t going to be partcularly big, but the chances are that the layout will have similarly small margin for expansion as well.) Much of it is good practice, and for a ‘how-to’ check out Dan Cederholm’s Bulletproof web design.

The user already has control over the text size, but it isn’t very usable. A recent extension for Firefox shows a great example of how it should work:

In this case, it also saves the preference on a per-site basis. It might even be included in Firefox 3 by default.

That’s good, it will help for people with minor visual impairments, or those with very high resolution displays. However, it isn’t enough for many. Opera’s full zoom (images and layout included) is a very powerful mechanism for coping with small text and layouts that won’t leave you squinting at images. (It would be even better if it could handle increasing the system fonts as well, the text in the zoom control is cut off on my PC.)

Opera’s zoom is better than other browser’s versions because you can turn on or off the ‘fit to width’ option, as well as setting global defaults. If you use a massively increased size (over 400%), it will switch to a one-column zoom layout. Apart from making users choose whether they want this functionality when they install, it’s difficult to see how this function could be improved.

Opera also allows the user to change the styles applied to the page, so you can use high or low contrast colour schemes and remove the layout:

However, this feature is something of a sledgehammer on a walnut. It pretty much destroys any personality the site had, and some images (with transparencies) will be difficult to read. Given that our research into Zoom layouts suggested that a simple 2 column layout with well sized contrasting text was the best option for those with mild/moderate visual impairments, it is something that a site could handle better than the UA.

Ideally, a site would provide several alternative styles that still have some personality / branding, and allow the user to choose between them. In fact, the ideal would be that a user sets up (or is forced to choose) a ‘profile’ and they automatically get the best layout and colour scheme for them. (See profiles below.)

One thing that can be dealt with fairly well by the user agent is highlighting the keyboard focus. It has even been considered as a core part of Firefox. If a site provides these, great, but the user(-agent) can and should override them if that’s what the user wants. Given that people who don’t use the keyboard for navigation will probably never see this, it is probably best for browsers to have highlighting of focus enabled by default, with an option to turn it off.

Prevent ‘changes of context’ or flashing/blinking

Automatically refreshing or redirecting pages can be confusing, especially if you can’t take in the whole page at a glance. Flashing and blinking content is an obvious problem for those with epilepsy, and can be a severe distraction for people with cognitive issues.

All of these things can be turned off in the browser, but there are usability and experience problems with doing so across the board. Essentially, the user needs more control, more easily, than they currently have.

The parts are all in place, each problem can be turned off or prevented, but there isn’t an easy way to do so. Firefox’s accessibility toolbar has much of the functionality, but is not an extension aimed at people with disabilities as it includes everything possible, including tests. It also doesn’t include the required notifications.

Browser notifications

If things like automatic refreshes are a problem for the user, they need to be blocked in general, and allowed when the user wants. There are several interaction methods in use for this already, from adding an icon to the status bar, adding a large bar at the top, to pop-up dialogues. Each has a certain level of intrusion, depending on how much the browser developers wanted to interrupt the user.

I’m going to assume for the sake of conciseness that each of these methods is accessible, but obviously changing the status of an icon requires you to check, adding a bar (with sound effect) is noticed but can be ignored, and a dialogue requires you’re attention.

If you’ve set your browser to ignore pop-ups, redirects and refreshes, how should you be informed?

Pop-up windows

This has largely been dealt with by browsers, unwanted pop-ups no longer open new windows in most browsers. The status bar icon is used if anything, but now site’s generally know not to use unrequested pop-ups.

Automatically refreshing pages

If a page automatically updates (for a good reason), the chances are you would like to let it – when you are ready. This would lend itself to the status bar icon or top-bar approaches.

Re-directs

A slightly trickier one, as in some cases (ahem, Microsoft), you are sent via about 15 re-directs when you login to something. For these cases, you would want to allow re-directs on a site, domain or even time basis (e.g. *.microsoft.com or 5 minutes). This lends itself to the top-bar or pop-up interaction style.

Animations

Animations can be very distracting, but they can also be real content, so a broad-brush rule to stop all animation will not be particularly useful. The Firefox extension Flash block has this covered for Flash, but from the accessibility point of view it would be best applied to all animations, including animated GIFs and any other objects.

An option like this where you selectively play what you want is ideal.

A slightly tricker problem is when JavaScript is used to move things around the page. It would be nice to stop large adds being moved over the content, but not to prevent the usability touches that show where a items has disappeared to (e.g. when a program minimises to the OSX dock).

For JavaScript, I would trial the prevention of movement based scripts from working, but put a ‘play’ button in a corner of the screen (with an audible beep) when something tries to move.

Skip links

Skip links are one of the few things I recommend people do from WCAG 1′s priority 3 guidelines. Getting around a page can be quite a time consuming process on a keyboard, whether or not you can see the page, it’s a linear process.

However, it is something that can be at least partly built into the user-agent. If there are a bunch of links with no non-link content, provide a key command to skip over it (JAWs uses N for this).

Currently, to provide a better experience the site can provide useful short cuts that make sense to those using a linear device (a screen reader, text browser or small screen device). For example, if your navigation is at the end, a "skip to menu" would be useful.

However, with a site that has a good (and consistent) structure, this is all available now. The Firefox accessibility extension includes several methods of navigating by page structure both visually and for screen reader usage:

If you select the menu and navigation bars option, it highlights the menu bars that it picks up on the page:

The whole point of a well structured page is that you can programmatically identify these things, and give them meaningful names for people to use. Which brings us nicely onto the W3C’s ARIA work.

In future you should be able to use XHTML role landmarks to improve document navigation, in fact Firefox with the accessibility extension already has some support for this. Once these are reasonably well supported, skip-links become obsolete. A short cut in the meantime would be consistent id and class names (Doug Bowman’s presentation), as would some of the new elements from HTML5.

Accessing useful attributes

Some elements and attributes are already used, such as lang attributes that can be used by screen readers to automatically switch the speech synthesizer, and titles that provide explanation for abbreviations and form inputs. But there are quite a few that would be useful to add:

cite

On blockquote and q (mainly, but del and ins as well), where the author can provide a reference URL. I make these explicit on this site with JavaScript, adding the cite as a link at the end of the quote, or as an onclick for the q.

title

Titles are available for people with mice, Jaws or Windows Eyes. However the mechanism in screen readers isn’t that great. For links it is either ignored or replaces the link text (in Jaws), and it’s generally ignored on most elements.

What you could do with is an audible alert (called an ‘audio icon’ by some researchers) each time you find a title, and a keyboard command to read it out.

NB: There would have to be a preference to turn this off, as there are quite a lot of sites mis-using title.

hreflang

This underused attribute indicates the language of the target URL, and could be used to alert the user that it’s in a different language.

Microformats

Although there isn’t a mainstream browser that is ‘microformat’ enabled by default yet, it would be pretty easy to give an alert when a microformat is encountered, and allow the user to sending it to the appropriate program. For example, in a screen reader it could use an audible alert to say that this element contains a microformat, and the user could interrogate the item to find there is an address, and add the contact details to their address book.

(My favorite example that doesn’t exist yet: taking a geo-location from a site that you can immediately download to a GPS device and find your way there – without sight.)

There maybe other useful attributes (or elements) for assistive technologies to use, any other suggestions?

In terms of responsibility, there is a responsibility on the user to know how to use their technology. I’ve observed usability testing with someone using JAWs, who came across a perfectly marked up data table, but said that she would contact the site and complain about the accessibility. She didn’t know how to use tables in JAWs. Of course nothing was said about this during the session, but we did not recommend that the site dispense with tables!

Profiles

This is the item that could make the most difference overall: allowing users to easily set up a profile that web sites can access and use to customise the experience.

Ideally this would be part of the browser, where it asks the user on first-loading whether they would like to set preferences to make sites easier to use (or words to that effect). Interestingly, Christian Heilmann had a similar suggestion at the recent WSG-UK meeting, where he suggested that large companies (like Yahoo!, Google & Microsoft) who have central identities for users could allow them to set an option such as “I use a screen reader”. It is certainly better than sniffing for assistive technology, which even the creators of Flash-aid would only use to give the user the option to opt-in to accessibility enhancements.

This isn’t a new concept, Kynn Bartlett was suggesting similar things (using XML/XSL) back in 2000. I see standardised user-profiles as the only realistic way to balance up the responsibilities of the site and user in a usable fashion. The basic principle is that the user-agent sends certain information in the http-request headers which the site can use to customise what the user receives.

To set this up, the user would be presented with the option to customise their experience, and could choose from options like:

• Increase the text size.
• Reduce the columns (where provided by the site).
• Reduce the columns anyway.
• Use alternative colour schemes when available.
• Enforce your own colour scheme.
• Prevent animations playing automatically.
• Show page navigation options.
• Prevent pages updating.
• Disable scripting when the site makes this possible.

Each one you ticked could then take you to further settings, such as how big should text be, and what your preferred colour scheme is.

The site would then check the user’s preference and adjust the HTML/CSS/scripts (or other technologies) appropriately. For example, if the user’s preference is for a light-on-dark colour scheme, the site could have one prepared that works with all the images, which is an issue if the user agent applies a colour scheme regardless. Another example is to disable the scripting when the site accepts that preference (i.e. it’s done unobtrusive scripting properly).

In this way the user can choose to completely over-ride the site (which is currently possible, just difficult), or use alternative displays when made available (and more usable) by the site.

The W3C has defined what to do for accessibility at each ‘end’ (i.e. client side or web site site), but there is quite a lot of overlap, and scant advice on who should be responsible for what.

I’m going to try and show who’s responsible now, and where things should go.

Note: As a base assumption, I take ‘web accessibility’ in the stricter sense of ensuring that people are able to use web sites, regardless of their (dis)ability.

W3C model

The W3C, with responsibility for shepherding web technologies along a useful path, long ago outlined how things should fit together. Their essential components of accessibility include the User Agent Guidelines for browsers and assistive technologies, the Authoring tool guidelines for Content Management Systems and other tools, and the Web Content Guidelines for developers and site owners.

However, in the late 90′s when these guidelines were being developed, they were already starting from a very imperfect place. The accessibility of most sites, tools and browsers were appalling. You probably remember that there are many guidelines that start: “Until user agents” can do this that or the other. The developer wasn’t allowed to use pop-ups, client side redirects, or blinking text (amongst other things).

The next version of the guidelines has tried to avoid this, but it’s interesting that several of the things that they assumed would be fixed at the user-agent end, haven’t been (e.g. allow users to control flickering).

There is no getting away from the fact that you must have standards (or guidelines in W3C speak) for how the various web technologies interact. There are simply too many user-agents for developers to test against. The popular browsers are hard enough to deal with, without the dozens of screen readers, magnifiers, keyboards, voice recognition and other technologies that all create a different experience of a web site.

As Mike Davies said, there has to be trust on each side that the other will perform in an expected way. For progress, you need mutually developed standards, as the WHATWG has demonstrated recently by actually making process in advancing HTML.

The usability gap

Currently, the weight of responsibility for accessibility falls on web site owners, and by proxy, web developers. This is actually harmful for the accessibility of the web in the long term, as it stifles progression.

An obvious example is text-size widgets, a feature on a site that allows the user to change the font-size of the text. In the W3C model, this is superfluous, the user should be able to re-size the text from their browser. In web site accessibility terms, it’s like a spoiler on a Robin Reliant, unnecessary and in effect useless.

However, there is a usability gap at the moment.

You can argue that a text-size widget increases the accessibility of the site because people don’t know that they can increase the text size in their browser. And, in general, people don’t. There are many things that user’s can do to any site (built reasonably well with HTML & CSS), from re-sizing the text to changing or removing the layout, or even applying their own colour scheme. Given the multitude of abilities and preferences there are, this is the only way to have a hope of catering for everyone.

But so few people know how to adapt their user-agents that an impartial observer could conclude that it is reasonable for the site to be responsible these aspects.

But that doesn’t make it the right approach to the problem, and in this case the problem is cross-site applicability.

Best for users across all sites

I’ve spoken before about the limiting business models of certain products. If a site with a particularly enthusiastic developer, or a shed load of cash invests in something that improves the experience of the site for a certain population, that’s great, but should others have to?

If users like a feature on one site because the site becomes easier to read or use, they will miss it (and ask for it) on other sites. But they won’t get it on all other sites, whether it’s because other site owners can’t afford it, don’t care, or for other reasons. It’s not scalable.

There are some things that the site owner (and by extension the developer) has to be responsible for, such as the content, and the technology used to create the site.

Some things the user (and their technology) have to be responsible for, such as rendering the content according to the standards, and knowing that you can click links to navigate. (Yes, this used to be an issue in usability testing a few years ago!)

There are a couple of views that tend to highlight where people think this balance should lie. I’m highlighting extreme versions of these views:

Technical view of accessibility

If it works in Lynx (a text browser) it must be accessible.

User’s view of accessibility

If something doesn’t work for everyone (e.g. the title attribute), you shouldn’t use it.

Neither is ‘right’, but going back to my base assumption, you have to consider what accessibility is.

Accessibility = usability

A common theme, but if you are familiar with the definition of usability, accessibility fits right in. Usability is:

the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

In web accessibility, the product is the web site, “specified users” are people with disabilities, and the “specified context of use” encompasses their task, knowledge, technology, and ability. Whether you think this is too all-encompassing a definition or not, the bottom line is that a real accessibility issue is when a person (with a disability) can’t use your site, not necessarily that a certain technology can’t.

What makes accessibility complex is that different technologies give the person a different view of the same site. That’s what intrigued me in the first place. There are so many contributing factors at play, from the end-user, their technology (and whether they know how to use it), what the site does, and how that site is produced.

This makes it very difficult to say whether an issue a person has should be fixed by the site, the tools that made the site, the browser/assistive technology, or that the user needs educating. Usability is rarely clear cut, humans are messy and it’s probably better to either create a standard that can work for all, or accept the current situation.

Analysing the gaps

Site responsibilities

Working from WCAG 1 & general web standards, these are squarely in the domain of the site. These cannot (usually) be worked around on the user-agent end:

• Text equivalents.
• Using clear language.
• Separation of content, presentation and behaviour.
• Proper use of semantic elements.
• The site works without client-side scripting.
• Ensure that non-HTML formats are accessible (JavaScript, Flash, PDF, multimedia etc. Note on other formats.)
• Identifying the natural language (and changes to it).
• Using valid code.
• Ensure information conveyed with colour is also available via markup or content.
• Clearly identifying links.
• Consistent and understandable layout and navigation.
• Correct use of labels in forms.
• Ensure images with text have sufficient contrast.
• Specifying the expansion of abbreviations.
• Keywords first for headings and links.
• Supplementing text with graphical or auditory presentations.

I’ve put together a list of categorised WCAG 1 checkpoints if you really want the details. I was surprised by how many don’t come up any more.

User / User Agent responsibility’s

These could be adjusted by the user, although some are currently very difficult to do via a normal browser:

• Prevent the screen from flickering/blinking.
• Expand / contract font size and layout.
• Prevent redirects, refreshes and pop-ups.
• Skip over sets of links.
• Access to useful DOM elements (e.g. title and cite attributes).
• Navigating pages via DOM elements (e.g. Scanning headings)

Filling the gaps

There are really two main gaps, each with a technology and knowledge component. The tech components are that the:

1. Tools to create web sites don’t produce accessible code easily.
2. User agents don’t allow people to customise their experience easily.

The knowledge component of each is that:

1. People don’t know to buy better tools.
2. People don’t know to try better browsers/user agents.

So who’s responsible?

I’m afraid I’m not going to answer that for another two posts yet. In the next post, I’m going to examine the user-agent issues, and see how they could be improved. After that, there is the practical “how do people implement these sites” (the authoring tools).

However, I’m fairly sure that it’s going to be a path. If a site implements something that should be on the user-agent end, it should do so in such as way as to pave the way for user-agents to take over.

Technorati Tags:

• accessibility
• site-owners
• user-agents