Tags: aria



Marking up help text in forms

Zoe asked a question on Twitter recently:

‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.

Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).

The first example puts the validation message in an em element inside the label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.

<div class="first error example">
 <label for="firstemail">Email
<em class="message">must include the @ symbol</em>
 <input type="email" id="firstemail" placeholder="e.g. you@example.com">

The second example puts the validation message after the form field, but uses aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.

<div class="second error example">
 <label for="secondemail">Email</label>
 <input type="email" id="secondemail" placeholder="e.g. you@example.com" aria-describedby="seconderror">
 <em class="message" id="seconderror">must include the @ symbol</em>

In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:

  1. Label text,
  2. Validation message,
  3. Form field.

And in the second example we get:

  1. Label text,
  2. Form field,
  3. Validation message.

In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.

Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.

Unlabelled search fields

Adam Silver is writing a book on forms—you may be familiar with his previous book on maintainable CSS. In a recent article (that for some reason isn’t on his blog), he looks at markup patterns for search forms and advocates that we should always use a label. I agree. But for some reason, we keep getting handed designs that show unlabelled search forms. And no, a placeholder is not a label.

I had a discussion with Mark about this the other day. The form he was marking up didn’t have a label, but it did have a button with some text that would work as a label:

<input type="search" placeholder="…">
<button type="submit">

He was wondering if there was a way of using the button’s text as the label. I think there is. Using aria-labelledby like this, the button’s text should be read out before the input field:

<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">

Notice that I say “think” and “should.” It’s one thing to figure out a theoretical solution, but only testing will show whether it actually works.

The W3C’s WAI tutorial on labelling content gives an example that uses aria-label instead:

<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

It seems a bit of a shame to me that the label text is duplicated in the button and in the aria-label attribute (and being squirrelled away in an attribute, it runs the risk of metacrap rot). But they know what they’re talking about so there may well be very good reasons to prefer duplicating the value with aria-label rather than pointing to the value with aria-labelledby.

I thought it would be interesting to see how other sites are approaching this pattern—unlabelled search forms are all too common. All the markup examples here have been simplified a bit, removing class attributes and the like…

The BBC’s search form does actually have a label:

<label for="orb-search-q">
Search the BBC
<input id="orb-search-q" placeholder="Search" type="text">
<button>Search the BBC</button>

But that label is then hidden using CSS:

position: absolute;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);

That CSS—as pioneered by Snook—ensures that the label is visually hidden but remains accessible to assistive technology. Using something like display: none would hide the label for everyone.

Medium wraps the input (and icon) in a label and then gives the label a title attribute. Like aria-label, a title attribute should be read out by screen readers, but it has the added advantage of also being visible as a tooltip on hover:

<label title="Search Medium">
  <span class="svgIcon"><svg></svg></span>
  <input type="search">

This is also what Google does on what must be the most visited search form on the web. But the W3C’s WAI tutorial warns against using the title attribute like this:

This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information.

Twitter follows the BBC’s pattern of having a label but visually hiding it. They also have some descriptive text for the icon, and that text gets visually hidden too:

<label class="visuallyhidden" for="search-query">Search query</label>
<input id="search-query" placeholder="Search Twitter" type="text">
<span class="search-icon>
  <button type="submit" class="Icon" tabindex="-1">
    <span class="visuallyhidden">Search Twitter</span>

Here’s their CSS for hiding those bits of text—it’s very similar to the BBC’s:

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;

That’s exactly the CSS recommended in the W3C’s WAI tutorial.

Flickr have gone with the aria-label pattern as recommended in that W3C WAI tutorial:

<input placeholder="Photos, people, or groups" aria-label="Search" type="text">
<input type="submit" value="Search">

Interestingly, neither Twitter or Flickr are using type="search" on the input elements. I’m guessing this is probably because of frustrations with trying to undo the default styles that some browsers apply to input type="search" fields. Seems a shame though.

Instagram also doesn’t use type="search" and makes no attempt to expose any kind of accessible label:

<input type="text" placeholder="Search">
<span class="coreSpriteSearchIcon"></span>

Same with Tumblr:

<input tabindex="1" type="text" name="q" id="search_query" placeholder="Search Tumblr" autocomplete="off" required="required">

…although the search form itself does have role="search" applied to it. Perhaps that helps to mitigate the lack of a clear label?

After that whistle-stop tour of a few of the web’s unlabelled search forms, it looks like the options are:

  • a visually-hidden label element,
  • an aria-label attribute,
  • a title attribute, or
  • associate some text using aria-labelledby.

But that last one needs some testing.

Update: Emil did some testing. Looks like all screen-reader/browser combinations will read the associated text.

Accessible progressive disclosure revisited

I wrote a little while back about making an accessible progressive disclosure pattern. It’s very basic—just a few ARIA properties and a bit of JavaScript sprinkled onto some basic HTML. The HTML contains a button element that toggles the aria-hidden property on a chunk of markup.

Earlier this week I had a chance to hang out with accessibility experts Derek Featherstone and Devon Persing so I took the opportunity to pepper them with questions about this pattern. My main question was “Should I automatically focus the toggled content?”

Derek’s response was very perceptive. He wanted to know why I was using a button. Good question. When you think about it, what I’m doing is pointing from one element to another. On the web, we point with links.

There are no hard’n’fast rules about this kind of thing, but as Derek put it, it helps to think about whether the action involves controlling something (use a button) or taking the user somewhere (use a link). At first glance, the progressive disclosure pattern seems to be about controlling something—toggling the appearance of another element. But if I’m questioning whether to automatically focus that element, then really I’m asking whether I want to take the user to that place in the document—in other words, linking to it.

I decided to update the markup. Here’s what I had before:

<button aria-controls="content">Reveal</button>
<div id="content"></div>

Here’s what I have now:

<a href="#content" aria-controls="content">Reveal</a>
<div id="content"></div>

The logic in the JavaScript remains exactly the same:

  1. Find any elements that have an aria-controls attribute (these were buttons, now they’re links).
  2. Grab the value of that aria-controls attribute (an ID).
  3. Hide the element with that ID by applying aria-hidden="true" and make that element focusable by adding tabindex="-1".
  4. Set aria-expanded="false" on the associated link (this attribute can be a bit confusing—it doesn’t mean that this element is not expanded; it means the element it controls is not expanded).
  5. Listen for click events on those links.
  6. Toggle the aria-hidden and aria-expanded when there’s a click event.
  7. When aria-hidden is set to false on an element (thereby revealing it), focus that element.

You can see it in action on CodePen.

See the Pen Accessible toggle (link) by Jeremy Keith (@adactio) on CodePen.

Accessible progressive disclosure

Over on The Session I have a few instances of a progressive disclosure pattern. It’s just your basic show/hide toggle: click on a button; see some more content. For example, there’s a “download” button for every tune that displays options to download the tune in different formats (ABC and midi).

To begin with, I was using the :checked pseudo-class pattern that Charlotte has documented so well. I really like that pattern. It feels nice and straightforward. But then I got some feedback from someone using the site:

the link for midi files is no longer coming up on the tune pages. I am blind so I rely on the midi’s when finding tunes for my students.

I wrote back saying the link to download midi files was revealed by the “download” option. The response:

Excellent. I have it now, I was just looking for the midi button which wasn’t there. the actual download button doesn’t read as a button under each version of the tune but now I know it’s there I know what I am doing. I am using the JAWS screen reader.

This was just one person …one person who took the time to write to me. What about other screen reader users?

I dabbled around with adding role="button" to the checkbox or the label, but that felt really icky (contradicting the inherent role of those elements) and it didn’t seem to make much difference anyway.

I decided to refactor the progressive disclosure to use JavaScript instead just CSS. I wanted to make sure that accessibility was built into the functionality, rather than just bolted on. That’s why code I’ve written doesn’t rely on the buttons having a particular class value; instead the buttons must have an aria-controls attribute that associates the button with the element it toggles (in much the same way that a for attribute associates a label with a form field).

Here’s the logic:

  1. Find any elements that have an aria-controls attribute (these should be buttons).
  2. Grab the value of that aria-controls attribute (an ID).
  3. Hide the element with that ID by applying aria-hidden="true" and make that element focusable by adding tabindex="-1".
  4. Set aria-expanded="false" on the associated button (this attribute can be a bit confusing—it doesn’t mean that this element is not expanded; it means the element it controls is not expanded).
  5. Listen for click events on those buttons.
  6. Toggle the aria-hidden and aria-expanded when there’s a click event.
  7. When aria-hidden is set to false on an element (thereby revealing it), focus that element.

You can see it action on CodePen.

I’m still playing around with this. I think the :focus styles are probably far too subtle right now—see this excellent presentation from Laura Palmaro for more on that. I’m also not sure if the revealed content should automatically take focus. I’ll see if I can get some feedback from people on The Session using screen readers—there’s quite a few of them.

Feel free to use my code but you might want to check out Jason’s code to do the same thing—his is bound to be nicer to work with.

Update: In response to this discussion, I’ve decided not to automatically focus the expanded content.

100 words 067

There’s something to be said for focusing on one particular kind of work. There’s a mastery that only comes with repeated practice.

On the other hand, I have to tendency to get bored of doing the same thing. Repetition is good for skill-building but it has the downside of being …repetitive.

Today Charlotte and I took part in a client workshop, getting right down to the nitty-gritty of cataloging interface elements at a granular level. Then I published a long rambling post on the nature of the web.

From sea level to the stratosphere—it’s good to mix things up.

100 words 029

It’s Monday. This Monday was an inverse of Friday.

Now I know that many people consider Mondays to be the inverse of Fridays in general—you know, the mood, the spirit of the day. But this particular Monday was literally the inverse of the previous Friday. On Friday I travelled from Brighton to Bulgaria. Today was the reverse. I began the day in a hotel room in Sofia and ended it safely ensconced back home in Brighton.

Car; plane; plane; car.

Once again there was a layover in Frankfurt—just enough time to enjoy some currywurst and pommes between flights.

100 words 028

The Thracians were one of the first peoples to settle in Bulgaria.

The Romans arrived in the first century.

Four centuries later, Bulgaria became part of the Byzantine empire.

From the fourteenth century onward, the country was part of the Ottoman empire.

That lasted until the end of the nineteenth century, when the country was liberated by Russia.

At this point for some reason, the Bulgarians thought they ought to have a monarchy.

That whole monarchy thing only lasted until the end of the second world war. Then they gave communism a whirl.

Finally they got with the democracy programme.

100 words 026

Today was a travel day. It began in Brighton and ended in Bulgaria.

Jessica and I were up early to make the trip to Heathrow. From there we took a flight to Frankfurt, where we killed time waiting for our next flight. Despite having a three hour layover, we still ended up rushing to the gate—I blame the lack of signage and wayfinding in the airport.

From Frankfurt we flew to Sofia. With each leg of our journey, we set our clocks forward. Now we are two timezones away from where we started the day.

Tomorrow: Bulgaria Web Summit.

The main issue

The inclusion of a main element in HTML has been the subject of debate for quite a while now. After Steve outlined the use cases, the element has now landed in the draft of the W3C spec. It isn’t in the WHATWG spec yet, but seeing as it is being shipped in browsers, it’s only a matter of time.

But I have some qualms about the implementation details so I fired off an email to the HTML working group with my concerns about the main element as it is current specced.

I’m curious as to why its use is specifically scoped to the body element rather than any kind of sectioning content:

Authors must not include more than one main element in a document.

I get the rationale behind the main element: it plugs a gap in the overlap between native semantics and ARIA landmark roles (namely role="main"). But if you look at the other elements that map to ARIA roles (header, footer, nav), those elements can be used multiple times in a single document by being scoped to their sectioning content ancestor.

Let’s say, for example, that I have a document like this, containing two header elements:

 <header>Page header</header>
 Page main content starts here
  <header>Section header</header>
  Section main content
 Page main content finishes here

…only the first header element (the one that’s scoped to the body element) will correspond to role="banner", right?

Similarly, in this example, only the final footer element will correspond to role=”contentinfo”:

 <header>Page header</header>
 Page main content starts here
  <header>Section header</header>
  Section main content
  <footer>Section footer</footer>
 Page main content finishes here
 <footer>Page footer</footer>

So what I don’t understand is why we can’t have the main element work the same way i.e. scope it to its sectioning content ancestor so that only the main element that is scoped to the body element will correspond to role="main":

 <header>Page header</header>
  Page main content starts here
   <header>Section header</header>
   <main>Section main content</main>
   <footer>Section footer</footer>
  Page main content finishes here
 <footer>Page footer</footer>

Here are the corresponding ARIA roles:

 <header>Page header</header> <!-- role="banner" -->
 <main>Page main content</main> <!-- role="main" -->
 <footer>Page footer</footer> <!-- role="contentinfo" -->

Why not allow the main element to exist within sectioning content (section, article, nav, aside) the same as header and footer?

 <header>Section header</header> <!-- no corresponding role -->
 <main>Section main content</main> <!-- no corresponding role -->
 <footer>Section footer</footer> <!-- no corresponding role -->

Deciding how to treat the main element would then be the same as header and footer. Here’s what the spec says about the scope of footers:

When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

I could easily imagine the same principle being applied to the main element. From an implementation viewpoint, this is already what browsers have to do with header and footer. Wouldn’t it be just as simple to apply the same parsing to the main element?

It seems a shame to introduce a new element that can only be used zero or one time in a document …I think the head and body elements are the only other elements with this restriction (and I believe the title element is the only element that is used precisely once per document).

It would be handy to be able to explicitly mark up the main content of an article or an aside—for exactly the same reasons that it would be useful to mark up the main content of a document.

So why not?

Landmark roles

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

Thinking Small

Jason Santa Maria, AKA Stan, is the man. Here’s here at An Event Apart in Boston to talk about Thinking Small. He’s my warm-up man.

He begin in the 1980s; Christmas day in the Santa Maria household—Jason gets Castle Greyskull. One Christmas, his parents played a cruel joke on him. Instead of getting him toys, they got him books. But these books were better than regular books. They were choose-your-own-adventure books; classics like You Are A Shark and War With the Evil Power Master. The best part is that they are interactive. Of course you cheat. You go back and see what would have happened if you had made a different decision. Let’s look at the decisions we make when we are building website. Jason will show us seven small decisions that change the outcome of a finished website.

Be a thinker

Don’t just dive into moving shit around in Photoshop. Stop and figure out the problem before trying to come up with a solution. Take a look at the Enterprise car rental site. It’s not terrible but it’s also not exciting. It’s just bland.

Take a step back. Start with sketching. Sketching isn’t about being able to draw, it’s about being able to think. Jason started a Flickr group for people to upload one page from their sketch book, no matter how crappy it looks.

At the beginning of a project, get acquainted with it. Get a feel for the content.

Find the message

The difference between good design and great design is intelligence.

Sum up a website with a message, as if you were introducing a friend at a party—what’s important? Everything on the site should communicate that message. The White House website does this. So does A Working Library.

Be a reverse engineer

Come at things from a different angle. Jason played Layer Tennis recently with Derek Powazek. They decided to play around with the format by introducing three truths and a lie. This prompted new ways of thinking about what they were producing.

Take lessons from improv. Play the “yes” game in brainstorming sessions. Take what people are offering and add to it.

Plot it out

Jason comes from traditional graphic design background of grids and systems. Cue obligatory Vignelli quote. But how big should your grid be? Just because you can go to 960 pixels doesn’t mean you should. Don’t blindly approach grids from a set size. The space on the screen is a valuable design tool. You can use for your grid but you can also use it for whitespace. Brockman says:

The grid system is an aid not a guarantee.

There are other kinds of grids, not just columns. It’s about choice. How do you choose to fill that space? 960 pixels is not right for everyone. Stop and consider. Big Cartel feels small and approachable because it doesn’t go full width. That fits the message it wants to communicate.

Grids don’t necessarily have to be uniform. Yet most grid tools start from that assumption. It seems like a small decision but it effects everything further down the line.

Think horizontally, then vertically

Thing of the page as a delicious parfait. The design of Jason’s own site can adapt to the content. His grid is just some horizontal strips. The different sections can then work together or stand alone. Within each layer there are then sub-layers. Only then does Jason think about how things line up vertically.

Design systems, not pages.

Stop, modulate and listen

Jason wrote a 24 Ways article on modular layout systems. You can narrow page elements down to identifier, size and placement: what it is, how big it is and where it goes. You can then apply those things to class names. Have classes for identification, size and placement. Then combine those classes e.g. class="pic two left" or class="pic seven right". Clients like the self-documenting nature of this.

Be a matchmaker

The state of type on the web today is still questionable. The choice isn’t large. It’s as if Netflix only offered four films for you to choose from. But type on the web is going to change soon. The conversations are already happening. In the next six months to a year, you will see more of a push for understanding of type and how to use type. Jason has some rules of thumb when choosing typefaces:

  • Don’t use two script typefaces together. Or two sans-serifs together (or two serifs together), for that matter. One of each is a good rule of thumb.
  • Pair fonts from the same designer. Perpetua and Gill Sans go great together because they were both made by that loony Eric Gill.
  • Find harmony and structure. Bedoni and Futura are very different; one is serif and one is sans-serif. And yet they share geometric forms.
  • Conversely, look for contrast. Caslon and Garamond are too similar to use together.

Step by step, all those decisions add up. It’s like Stewart Brand says in How Buildings Learn. People don’t begin building a house and plan for adding an addition but over time, bit by bit, you add to the house. Buildings adapt over time. So do websites.

The small decisions add up even if you don’t realise it at the time.


The first European Accessibility Forum in Frankfurt was a resounding success. I had fun moderating the panel on Accessible Web Applications. Paul, Christian and Saqib were all excellent. We could’ve talked all day.

The rest of the day featured a mixture of technical, governance and legal panels. Personally, I enjoyed diving into the technical stuff. I really enjoyed listening to the mighty Steve Faulkner talking about .

A question from the audience brought up the subject of the crossover between HTML5 structural elements and ARIA landmark roles. There seems to be a lot of opposition—even downright hostility—from the HTML5 group towards WAI-ARIA. I’m sensing a lot of thinking; a conclusion documented by Sam Ruby as already having been reached by the Technical Architecture Group:

The HTML5 community would define themselves as encompassing all Web technologies, i.e., if it’s not HTML5 and implemented in a browser, it’s not the Web.

Part of the opposition to ARIA is based around a perceived conflict with HTML5 structural elements:

For example, if ARIA defines a feature to say that something is a header, this will conflict with the HTML5 header algorithm.

So there’s an ARIA landmark role of banner that appears to align with the HTML5 header element. But if you look more closely at the specs, they’re actually defined in different ways. A banner is a region that contains the primary heading or web site title whereas a header is the header of a section. One is unique per document whereas the other can be used multiple times in the same document. To put it another way, banner is like an ID and header is like a class name.

Steve pointed to another false clash. HTML5 contains a value of search for [the type attribute of the input element. ARIA has a search landmark role. Sounds like a duplication, right? But the landmark role is typically applied to a form element, not an input element.

So on an HTML5 site like Huffduffer, I should be able to write:

<form method="get" action="/search" role="search">
<label for="query">Search</label>
<input type="search" name="q" id="query">
<button type="submit">Go!</button>

Alas, the HTML5 validator will throw an error (although it is using an experimental HTML5+ARIA schema). Ah, well.

Still, there’s no reason not to start using ARIA roles today: browsers, libraries and screenreaders already offer a good level of support and it’s only going to get better. If we start adding ARIA roles to our websites—and in our CMS themes—then if the HTML5 community stays true to its stated principal of paving the cowpaths, the pragmatic here-and-now solution should triumph.


My trip to MIX08 was also my first visit to Las Vegas. I’m sure I’m not the first place to make this observation but may I just say: what an odd place!

I experienced first-hand what Dan was talking about in his presentation Learning Interaction Design from Las Vegas. In getting from A to B, for any value of A and any value of B, all routes lead through the casino floor; the smoky, smoky casino floor. If it wasn’t for the fact that I had to hunt down an Apple Store to try to deal with my broken Macbook—more on that later—I wouldn’t have stepped outside the hotel/conference venue for the duration of my stay. Also, from the perspective of only seeing The Strip, visiting Las Vegas was like Children of Men or a bizarro version of Logan’s Run.

But enough on the locale, what about the event? Well, it was certainly quite different to South by Southwest. Southby is full of geeks, MIX was full of nerds. Now I understand the difference.

I was there to hear about Internet Explorer 8. Sure enough, right after some introductory remarks from Ray Ozzie, the keynote presentation included a slot for Dean Hachamovitch to showcase new features and announce the first beta release. I then had to endure three hours of Silverlight demos but I was fortunate enough to be sitting next to PPK so I spent most of the time leaning over his laptop while he put the beta through its paces.

After the keynote, Chris Wilson gave a talk wherein he ran through all the new features. It goes without saying that the most important “feature” is that the version targeting default behaviour is now fixed: IE8 will behave as IE8 by default. I am, of course, ecstatic about this and I conveyed my happiness to Chris and anyone else who would listen.

IE8 is aiming for full CSS2.1 support. Don’t expect any CSS3 treats: Chris said that the philosophy behind choosing which standards to support was to go for the standards that are finished. That makes a lot of sense. But then this attitude is somewhat contradicted by the inclusion of some HTML5 features. Not that I’m complaining: URL hash updates (for bookmarking) and offline storage are very welcome additions for anyone doing any Ajax work.

Overall IE8 is still going to be a laggard compared to Firefox, Safari and Opera when it comes to standards but I’m very encouraged by the attitude that the team are taking. Web standards are the star by which they will steer their course. That’s good for everyone. And please remember, the version available now is very much a beta release so don’t get too discouraged by any initial breakage.

I’m less happy about the closed nature of the development process at Microsoft. Despite Molly’s superheroic efforts in encouraging more transparency, there were a number of announcements that I wish hadn’t been surprises. Anne Van Kesteren outlines some issues, most of them related to Microsoft’s continued insistence on ignoring existing work in favour of reinventing the wheel. The new XDomainRequest Object is the most egregious example of ignoring existing community efforts. Anne also some issues with IE’s implementation of ARIA but for me personally, that’s outweighed by the sheer joy of seeing ARIA supported at all: a very, very welcome development that creates a solid baseline of support (you can start taking bets now on how long it will take to make it into a nightly build of WebKit, the last bulwark).

The new WebSlices technology is based heavily on hAtom. Fair play to Microsoft: not once do they refer to their “hSlice” set of class names as a microformat. It’s clear that they’ve been paying close attention to the microformats community, right down to the licensing: I never thought I’d hear a Microsoft keynote in which technology was released under a Creative Commons Public Domain license. Seeing as they are well aware of microformats, I asked Chris why they didn’t include native support for hCard and hCalendar. This would be a chance for Internet Explorer to actually leapfrog Firefox. Instead of copying (see the Firebug clone they’ve built for debugging), here was an opportunity to take advantage of the fact that Mozilla have dropped the ball: they promised native support for microformats in Firefox 3 but they are now reneging on that promise. Chris’s response was that the user experience would be too inconsistent. Using the tried and tested “my mom” test, Chris explained that his mom would wonder why only some events and contact details were exportable but not others. But surely that also applies to WebSlices? The number of WebSlices on the Web right now is close to zero. Microsoft are hoping to increase that number by building in a WebSlice parser into their browser; if they had taken the same attitude with hCard and hCalendar, they themselves could have helped break the chicken’n’egg cycle by encouraging more microformat deployment through native browser support.

Overall though, I’m very happy with the direction that Internet Explorer is taking even if, like John, I have some implementation quibbles.

Having experienced a big Microsoft event first-hand, I still don’t know whether to be optimistic or pessimistic about the company. I get the impression that there are really two Microsofts. There’s Ray Ozzie’s Microsoft. He’s a geek. He gets developers. He understands technology and users. Then there’s Steve Ballmer’s Microsoft. He’s an old-school businessman in the mold of Scrooge McDuck. If Ray Ozzie is calling the shots, then there is reason to be hopeful for the future. If the buck stops with Steve Ballmer however, Microsoft is f**ked.