Archive for the 'HTML5' Category

On the styling of forms

The earliest incarnation of the specification that we now call “HTML5″ was an extension of HTML forms, called Web Forms 2.0 (Working Draft 5 February 2004 – almost nine years ago!). It contained lots of cool stuff that’s in the spec today, like <input type=”date”>, <input type=”email”>, the required attribute, and cool stuff that never made it to the final spec like <input type=”location”> and repeating templates (the latter was implemented in Opera, and subsequently removed in 2010).

When I first started talking about HTML5, I’d show these new forms controls to developers, who were all initially very excited. After all, who wants to code JavaScript date-pickers, or email validation routines? But the excitement dissipated after the inevitable question about how you can style the forms and their error messages.

The answer is that unfortunately you can’t very well. You can apply some styling – for example, making invalid or out-of-range inputs have a different border colour with CSS pseudoclasses, as defined in the CSS Basic UI module input:invalid {border:2px solid red;}, but this was badly thought out because, for example, fields with a required attribute are “invalid” at page load and therefore take the ugly styles before the user has even begun to interact with the form. Mozilla implemented their own -moz-ui-invalid mechanism that solves the problem:

If the element is required, the preceding rules apply only if the user has changed the value or attempted to submit the form.

It’s only implemented in Firefox, as it’s proprietary, but it’s a really good idea and informed a W3C proposed :user-error pseudoclass:

The :user-error pseudo-class represents an input element with incorrect input, but only after the user has significantly interacted with it.

This is good, but only deals with styling erroneous input fields. Error messages can be styled in WebKit using proprietary pseudoelements ::-webkit-validation-bubble, ::-webkit-validation-bubble-arrow-clipper, ::-webkit-validation-bubble-arrow, ::-webkit-validation-bubble-message. There’s no cross-browser proposal at W3C, but Peter Gasston has interesting ideas. The only reliable way at the moment to control the appearance of validation is turn it off with <form novalidate …> and script your own, which rather defeats the purpose.

There are no real ways of styling the controls themselves. The HTML5 spec is mostly silent on styling matters (and rightly so); the CSS Basic UI module would be a natural place for it, but that hasn’t been touched for a year, and before that update had languished for half a decade. Of course, this isn’t a trivial problem. <input type=”date”> might be rendered as a pop-up calendar widget on a desktop browser, and you may wish to “grey out” weekends – but are weekends Saturday and Sunday? or Friday and Saturday? How would you achieve that in CSS? input[type=date]::friday {color:gray;}? And the same browser’s mobile version might use the operating system’s native date picking UI, in which case it would probably be unstylable anyway.

And what of sliders? When you have a pointer/ grabber, its track and tickmarks, what would input[type=range] {color: red;} change? Bear in mind that most browsers don’t follow the one styling suggestion that the spec does offer, which is to render vertical sliders when the input’s CSS height exceeds the width.

One thing that working in the web for a decade has taught me is that where there’s a will, clever people will solve the most head-pulsing problems. But I’m beginning to wonder if there is a will. Phenomenally brainy Tab Atkins wrote

I think any arguments that sites will refuse to use the native controls because they don’t match the site’s theme are countered by the observation that most sites using JS-library equivalents today still don’t theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library.

This doesn’t meet my experience of developers telling me they’ll continue to use things like jQuery UI because of the themes it offers.

It means that developers continue to make forms out of non-semantic elements like <div> and pile on contenteditable attributes and (hopefully) ARIA attributes and tabindex to make them accessible, even though native form controls are accessible by default.

Anne van Kesteren discusssed this in his clean markup plea:

Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type=”button”>.


Co-chair of the W3C HTML5 Working Group, Apple’s Maciej Stachowiak tried to get some traction for specifying form styling in 2010:

Popular sites are applying a great deal of custom styling to form controls. One example page we love to use here is If you take a peek in, say, Safari or Firefox, you can see that Google has put a lot of custom styling on the text field and the two <input type=submit> buttons on their home page. This lets them have a custom look while still working in old or obscure browsers, or in browsers with script disabled, and to provide good accessibility while maintaining fairly compact markup. But by styling form controls at all, they are in a no-man’s land in terms of standards. We need to bring this technique into the real of interoperable-specified behavior.

…but to no avail. So what is to be done? The Shadow DOM may help. Shadow DOM gives you access to the internals of browser widgets; for example, the buttons in a <video> element that the browser provides when you specify the controls attribute. It’s a work in progress, part of the suite of specifications called Web Components. Spec editor Dimitri Glazkov writes

Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree, which in turn allows the author-created shadow trees to properly override and even include) those UA-provided shadow trees.

You should be able to do the same exact thing with every other element (though there’s a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of “the insides” of the actual replaced content that will need to be first resolved by CSS WG).

So, again, back to the CSS Working Group. I’d like to ask them, when they’re specifying the insides of replaced content, that they do the same with form controls, and give us pseudoelements.

As Tab Atkins continued:

…us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar.

Tab’s absolutely right. And developers really start to use features when they’re specified in languages they already use. We’ve seen this with CSS transitions, animations and filters, all of which were possible for ages in SVG but that was something extra to learn.

The Shadow DOM is potentially a great advance in web development, but it’s a whole new set of technologies. Allowing form styling through CSS would make it simple and allow developers to satisfy the marketing department’s demand for sliders in corporate heliotrope and goldenrod, while using native, accessible controls rather than JavaScript libraries, ARIA bolt-ons and abusing semantics.

If you’re a developer, let me know if you use the native HTML5 form inputs, or – if you use some JS library – do you adjust them to suit your site?

Why I changed my mind about the <main> element

Congratulations to The Mighty Steve Faulkner, whose proposal for an HTML5 <main> element was published yesterday by the W3C. I’m delighted to see one of the code examples features “The Lawson Academy”. Academy of what is left unknown.

@stommepoes asked me why I now support the introduction of <main> when previously I thought it unnecessary. So here’s why.

It’s always seemed to me to be a good plan to make elements out of common landmark patterns like navigation, footers, banners/ headers and the like. While the Scooby Doo algorithm mostly works to identify where main content begins, I was unsure that it always would, and most authors found the absence of a <main> element anomalous. Ease of authoring matters: the priority of constituencies in the HTML5 Design Principles says

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

The Mighty Steve Faulkner is a very persuasive man – a kind of aussie Derren Brown of accessibility. He produced lots of data that suggested that people use <div id=”main”> (or similar names) properly.

Ian Hickson consistently claimed that such an element wasn’t necessary because the main content can be algorithmically determined so there’s no need to add extra cruft to the language – an argument which I’ve grown to consider “theoretical purity” and thus bottom of the heap in the priority of constituencies.

But, perhaps ironically, it was Ian Hickson who finally swayed me. When researching microdata and RDFa Lite, I noticed that a table comparing RDFa Lite and microdata said that microdata’s itemscope attribute is “not needed” in RDFa. More pertinently, it’s not really needed in HTML5 microdata, either. As Matt Wilcox writes

itemscope is utterly pointless. The scope of the property is /always/ the scope of the tag to which it is applied. Making this extremely verbose and rather confusing.

The reason is there is that it makes it easier for authors. Hixie did user-testing of (seven) markup authors and wrote

I was really surprised by the itemscope/itemtype thing helping people, but it was a really stark result if I recall correctly. Originally I’d designed it with just one attribute “item”, whose value was optional but if present was the type. Confusion abounded in the usability lab when we tested that variant. We had a variant with the attributes split more or less like it is now, and the participants in the study were far more comfortable with that. One of the people who was tested on my original design saw the split variant near the end of their session, and it was like they had an epiphany.

It was quite an educational experience for me as a language designer. Things that I thought were obvious (URLs are too long and unwieldy to be used everywhere, terse markup is better than verbose redundant markup) were repeatedly shown to be false. It really changed how I design languages.

If it’s worth adding a redundant attribute to the language for something as comparatively esoteric as adding micro-semantics, it seems wrong to refuse to add an element that mirrors what vastly more authors actually write, and which would make the Web more accessible to those who need extra help.

And that’s why I support the addition of a <main> element to HTML5.

I’d be grateful if no-one told my wife or kids that I was wrong previously; they’re convinced I’m perfect.

Addendum 23 December: A few people have asked whether <main> would need an attribute role=main too. I don’t believe so; according to Steve Faulkner, test builds of Firefox and WebKit already map <main> to the ARIA role, so no need to duplicate. Thus, if the assistive technology already supports ARIA role=main, it Just Works™ without the explicit role.

Reading List

A bumper reading list for those long holidays (and because I’ve been away conferencing for a few weeks and need to spurt out my backlog).



Conference videos


  • Cry-Baby of the Year – a list of ten previous winners of Cry-Baby of the Week who have been shortlisted by me as nominees for Cry-Baby of the Year
  • Dalkey Archive Press seeks unpaid interns -” Any of the following will be grounds for immediate dismissal during the probationary period: coming in late or leaving early without prior permission; being unavailable at night or on the weekends; failing to meet any goals; giving unsolicited advice about how to run things; taking personal phone calls during work hours; gossiping; misusing company property, including surfing the internet while at work; submission of poorly written materials; creating an atmosphere of complaint or argument; failing to respond to emails in a timely way; not showing an interest in other aspects of publishing beyond editorial; making repeated mistakes; violating company policies. DO NOT APPLY if you have a work history containing any of the above.”

And finally, here’s Kim Wilde, pissed on a train after the Magic FM Xmas party, singing “Kids in America” and “Rocking Around the Christmas Tree”.

On the talismanic fight between RDFa and microdata

A new fight has broken out in specland, between the supporters of RDFa and supporters of microdata. Observers may be wondering why; both are methods of adding extra markup to existing content in order that machines may better understand the content. Semantic Web proponents (note capital letters) dream of a Web where all content is linked by said machines. Semantic Web sceptics have more humble aspirations of search engines better understanding micro-content (is this string of digits a book ISBN, or a phone number?).

RDFa was part of XHTML 2. It became a W3C standard (or, in their vernacular, a “recommendation”) in 2008. microdata was invented by Ian Hickson as part of HTML5 because he identified deficiencies in RDFa. microdata was subsequently modularised out of W3C HTML5, but microdata is part of HTML5; it validates, whereas RDFa doesn’t.

Note the history. Like football fights that break out because one guy called an opposing team fan’s pint “a pouff”, this isn’t about the actual slight at all; this is about the past, allegiances and alliances; it’s a clash of world views. This is XML versus non-XML; it’s the XHTML 2 gang against the uncouth young turks of HTML5. This is Rangers vs Celtic; it’s Blur vs Oasis; it’s Tiswas vs Swap Shop.

(Added 15:30 GMT: R/e my framing the current debate as a talismanic battle, I should point out that I don’t mean Manu (whom I’ve always found to be courteous, thoughful and a jolly good chap). Neither do I mean Marcos, who isn’t a WHATWG-er. But some of the discourse “cowardice”, “suck metadata and fade, for all I care” on one side, and “TimBL’s RDF temple priests still mad as hell” suggests some, er, partisan feeling going on.)

What follows is the observation of a layman; I’ve not used much structured content, so am not an expert (I once tried to use microformats for events at the Law Society, but their accessibility problems prevented it.)

In my opinion, the primary deficiencies of Classic RDFa are that it’s too hard to write. For professional metadata-ologists it may be simple (but, hey, those guys understand Dublin Core!). The difficulty for me as an HTML wrangler was namespacing, CURIEs, and triples. This is XML land, and most web authors are not particularly adept with XML.

There’s also the problem that in order to use RDFa properly, you needed an xmlns attribute which is separate from the content you’re actually marking up (you don’t anymore in RDFa 1.1, see Manu’s comment). In a world where lots of content is syndicated via machine, or copy and pasted by authors (many of whom don’t really understand what they’re copy and pasting), this leads to breakage as not all of the necessary moving parts get transferred to their new environment. Hixie wrote

Copy-and-paste of the source becomes very brittle when two separate parts of a document are needed to make sense of the content. Copy-and-paste is how the Web evolved, so I think it is important to keep it functional and easy.

microdata solves this problem. It’s also easier to write than Classic RDFa (in my opinion) although I’m still mystified by the itemid attribute. I intend to start using microdata on this site soon (in order to plug the holes left by removal of the HTML5 pubdate attribute).

I’ve been recommending that people use microdata. Its main advantages:

Manu Sporny understood the problem that RDFa is hard to author for those of us who find the best ontology is a don’t-ology. Almost a year ago, he set about simplifying RDFa and came up with RDFa Lite. RDFa Lite greatly simplifies RDFa; in fact, you can search and replace microdata terms with RDFa terms (see his post Mythical Differences: RDFa Lite vs. Microdata).

RDFa has multiple advantages, too:

It seems to me that developers should just choose the one that meets their project’s needs. Need valid code Don’t need “full fat” RDFa, need a JavaScript API? Choose microdata. Care about Facebook, don’t care about a JavaScript API? Use RDFa Lite.

The current fight, however, won’t allow that. The RDFa gang want to stop microdata going further in the standardisation process because RDFa became a Recommendation first, and microdata is quite similar to it. (This is a controversial perspective; see Manu’s comment.)

While I completely understand that two competing standards makes it harder for developers in the short term, I agree with Marcos Caceres (who isn’t a WHATWG/ HTML5 zealot) who counters Manu Sporny’s objection to microdata progressing thus:

I don’t see what it being a “Recommendation” has to do with anything – just because it’s a W3C Recommendation does not mean that RDFa has a monopoly on structured data in HTML. So, just because that spec reached Rec first doesn’t mean that it’s somehow better or preferable to any other future solution (including micro data). That would be like objecting to Javascript because assembler (or punch cards) already meet all the use cases…

I hope you will instead focus your energy on convincing the world that RDFa is the “correct technology” on its own merits and not place your bets on a mostly meaningless label (“Recommendation”) given by some (much loved, but) random standard organisation.

I see no technical reason to favour microdata or RDFa Lite; both do the job. So, developers; which tickles your fancies? RDFa Lite or microdata?

Reading List

HTML5 etc

Responsive Web Design



Reading List



Reading List



Thoughts on Adobe Edge

Last week, I dragged my snot-filled carcass down to London for a day-long presentation by Adobe called Create The Web.

I’m an occasional user of Adobe products: I used Dreamweaver in my last job (and was a beta tester for a previous version), and use Photoshop from time-to-time, although use about 2% of its capabilities. I also have some chums at Adobe, but they’re weedier than me so didn’t try to threaten me to be nice to them.

In passing, it’s interesting to note that while Twitter has lots of griping about Adobe products, they managed to get about 800 people into a Leicester Square cinema for a full-day product pitch. That suggests Adobe retains significant mindshare.

I was there because I wanted to see their new Edge range, as the tools that authors use to make websites directly affect the quality of the code of those sites, which directly affects the interoperability of the Web. I was therefore watching the day from two occasionally opposing perspectives: firstly, as the representative of a browser vendor that is sometimes disadvantaged by developers not using the correct prefixes etc, but also as a web author who, all other things being equal, prefers to use IDEs than type in code.

The decline of Flash has not diminished the appetite of site owners and developers for eye-candy and movie-like effects. That’s why Adobe is pushing for lots of new effects in CSS: cool stuff like CSS Filters and CSS Compositing and Blending and also anachronistic “we wish the Web were print” specs like CSS Regions.

Regardless of your opinions on Flash as a technology or plug-in, there’s no denying that the Flash Pro development IDE beats coding canvas in raw JavaScript. It’s also true (according to my good chum and co-author, Remington Sharp) that those developers just coming to canvas and motion graphics now are bumping up against problems that the Flash developers solved decade ago.

Therefore, Adobe has made a very smart move by making the new tools for animating stuff feel familiar to Flash developers. This was explicitly called out: Flash devs, your skills are not dead; the technology might be, but your experience and creativity are still in demand. This is true, and a shrewd business strategy.

(A word about product nomenclature and confusion: the DHTML tool that was called Adobe Edge is now called “Edge Animate”. “Edge” now refers to the whole suite of new Adobe tools. Animate seems to produce DHTML, flying <div>s around with CSS and JavaScript. Apparently, the Flash IDE can produce “HTML5″ output, but that’s <canvas>. If your stuff involves text, use Animate so the text remains text and is therefore accessible.)

I haven’t had a chance to download my copy of Edge Animate yet. Lee Brimelow gave an excellent and entertaining developer-focussed presentation building up an animation and there were a few nasties in the code produced.

For example, it seemed that, by default, the code is simply empty <div>s with everything else injected by JavaScript. This means that someone without JS sees nothing at all. The “static HTML” export (which ought to be the default, in my opinion) at least puts the images in the markup, so a browser without JS sees *something*, albeit it unanimated. That code, however, was invalid: it produced <img>…</img>, and there is no closing </img> tag in HTML5 (or any previus incarnation of HTML, for that matter).

Encouragingly, Ryan from Adobe contacted me after I tweeted about this, asking for further feedback which I gave.

Other products that interested me were PhoneGap Build which allows you to upload a PhoneGap project and receive all the different packages through The Cloud™. I’d definitely use this. Who wants to dick around with all the different SDKs?

Edge Code is built on top of an open-source project started by Adobe called Brackets. Some hard-core developers (eg, those who wouldn’t pee on Dreamweaver if it were on fire) I spoke to seemed impressed. It seems they’re very serious about getting external developers involved; pull requests are reviewed daily; Agile sprints mean a quick iteration time, so your contributed code doesn’t languish interminably, and priority is given to external contributions.

The last product that interested me is Reflow, which isn’t out yet. It’s a drag-and-drop visual editor, which allows you to shrink the “stage” and, when your design starts to fall apart, set a breakpoint (which writes a Media Query) after which you re-design the page for the new page width. I haven’t seen the code that’s produced, but it feels to me an intuitive way for a designer to work.

Overall, it was exciting to see a company working hard to come up with a new strategy. The jury is out on the code it produces; Adobe is very heavily investing in WebKit and one of the presenters’ saying “this also works in old browsers like IE9 and Firefox” makes me uneasy. But it doesn’t have to be bad: Microsoft’s Web Essentials Visual Studio extension does an excellent job of adding all the vendor prefixes, even though Microsoft are heavily investing in IE.

The success of the product will ultimately depend on the price. And I’m curious to see how they’ll integrate with Dreamweaver, which is pricey and currently lacks many of the Edge features.

(Note: this is a personal post and doesn’t reflect the opinion of my employer).

Give Paul Robert Lloyd’s Thoughts on Adobe Edge a read, which prompted me to write this up. Fellow HTML5 Doctor Ian Devlin says PhoneGap Build is Awesome.


This week, I went to speak at Apps World, a great big “Global Developer Event, Mobile Marketing Conference” (according to its site). It was at Earls Court, full of people in suits (6000 attendees) and there was an average of 9.6 synergies per square meter.

As I was waiting for my panel, I listened to the preceeding talk “Is HTML5 the future?” (answer: “yes”). The first question from the audience was about when Digital Rights Management (DRM) will come to HTML5 “so my company can start using it”. Many of the other attendees were nodding their head in agreement.

At the end of my panel, the moderator Robin Berjon asked us “which feature would you like to see come to HTML soon?” and I rather surprised myself by answering “DRM”.

I don’t want DRM. I dislike DRM. Not particularly because I think everything should be free (I don’t; I like receiving royalties for the best HTML5 book) but because I don’t think it works. The DRM graveyard: A brief history of digital rights management in music demonstrates this excellently.

However, “the suits” believe it does work, and aren’t willing to invest fully in the web stack until there is some attempt at DRM. That’s why Netflix, Google and Microsoft have proposed the Encrypted Media Extensions specification that’s being worked on by the Encrypted Media Task Force of the HTML Working Group at the W3C.

Currently, DRM for video is the province of plugins. About a year ago, Lovefilm moved from Flash to Silverlight:

We’ve been asked to make this change by the Studios who provide us with the films in the first place, because they’re insisting – understandably – that we use robust security to protect their films from piracy, and they see the Silverlight software as more secure than Flash.

Simply put: without meeting their requirements, we’d suddenly have next-to-no films to stream online.

This is a problem for Linux users, as Silverlight doesn’t work on that operating system. It’s potentially a problem for Opera users, too, as Opera isn’t officially supported by Silverlight (although it does work). At least if DRM is moved into HTML rather than plugins, people using smaller browsers or operating systems will be able to choose whether or not to view DRM content. Now, they don’t have any choice at all.

But philosophy aside, ultimately, DRM in HTML is coming. WebKit appears to have started work on it 6 months ago, and Microsoft will presumably add it into Internet Explorer. And if those two giants support DRM, which browser would dare not to support it, and potentially be blocked by video sites? It’s like h264 on mobile: nobody likes it very much, but it’s a reality.

Like an unpleasant medical procedure such as having a catheter inserted, if it must happen it might as well come sooner rather than later.

(This is a personal view and does not reflect that of my employer)

Also see More on DRM in HTML5 in which I belatedly realise that the spec is just a plugin architecture.

Scooby Doo and the proposed HTML5 <content> element

Note: Since writing this, I’ve continued vacillating and now support a <main> element. Why I changed my mind about the <main> element.

Trigger warning: contains disagreement about accessibility.

I’ve been vacillating (ooh err, missus) for two weeks from one opinion to the other regarding a proposed (and rejected) <content> element. This weekend, The Mighty Steve Faulkner wrote an unofficial draft of a <maincontent> element.

Dude, where’s my content?

For a while, people have suggested that HTML add a <content> element that wraps main content, because many websites have something like <div id="content"> surrounding the area that authors identify as their main content, which they then use to position and style that central content area.

Fans of WAI-ARIA also like to hang role="main" on that area, to tell assistive technology where the main content of the page starts. I do this too.

The editor of, Ian Hickson, rejected a new <content> element:

What would the element _mean_? If it’s just “the main content”, then that is what the element’s contents would mean even without the element, so really it means the element is meaningless. And in that case, <div> is perfect, since that’s what it is: a grouping element with no meaning.

The primary argument against a special element is that it isn’t necessary, because the beginning of “main content” can be identified by a process of elimination that I call the “Scooby Doo algorithm”: you always know that the person behind the ghost mask will be the sinister janitor of the disused theme park, simply because he’s the only person in the episode who isn’t Fred, Daphne, Velma, Shaggy, or Scooby. (Like most Scooby fans, I’m pretending Scrappy never existed.)

Similarly,the first piece of content that’s not in a <header>, <nav>, <aside>, or <footer> is the beginning of the main content, regardless of whether it’s contained in an <article>, or <div>, or whether it is a direct child of the <body> element.

Authors do need to be able to identify their main content, both for styling (in which case <div> seems to be the most appropriate element) and as a target for “skip links”, in which case, the current <a href=”#main”>Skip nav<a> … <div id=”main”> pattern still does the trick.

It’s worth noting that people often code “skip links” believing it’s required by WCAG 2, but if browsers implemented the Scooby Doo algorithm that is explicitly not the case: “It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent.”

Many assistive technology useragents understand the ARIA role=”main”, so skip links should be unnecessary; ATs can hone in on <div id=”main” role=main> by themselves, even without supporting the Scooby Doo algorithm.

This suggests to me that a new element isn’t required. But…

Paving cowpaths, ease for authors

Chaals (ex-Opera, now Yandex) wrote

To turn the question around, if it is more convenient for authors to identify the main content, and not think about the classification of other parts, should we offer that facility as part of the platform? Or does it make sense to say that only the exhaustive identification of all supplementary content is an appropriate way to mark up a page anyway?

Chaals argues that it makes authoring easier – suddenly you get extra accessibility by just adding one <content> element, rather than adding the other elements that the Scooby Doo algorithm can then exclude. People using CMSs, who only control the textarea that gets lumped in as “main content” and can’t touch the surrounding areas can now add an element, without having to ask others to tweak templates.

But then, they can do this already, by surrounding their content with <div role=”main”> and this already works in assistive technologies.

A flawed argument for a new element is that it paves a cowpath, so should be added to the language. It’s certainly the case that <div id=”main”> and <div id=”content”> are very frequently found in pages – they were #2 and #6 in the most-frequently used ID attributes in the 2008 MAMA: What is the Web made of? report.

But not every cowpath needs paving. If it did, we’d also have a <logo> and a <container> element (#4 and #5 respectively), and we’d be recommending tables for layout. If something can be done automatically, without requiring extra authorial work, shouldn’t that be favoured? In the same way that we like HTML5 form types as they’re baked into the browser, shouldn’t the Scooby Doo algorithm be preferable?

Of course, the Scooby Doo algorithm requires the author to use <header>, <footer> <nav> and <aside> — but if (s)he doesn’t want/ isn’t able to author HTML5, ARIA’s role="main" is there precisely as bridging technology.

There’s also the argument that authors expect there to be a <content> element, so its absence violates the Principle of Least Surprise. But I’m not sure that’s a valid argument. Implementing the Scooby Doo algorithm would mean that pages whose author does nothing for accessibility can be made so that their main content area may be programmatically determined. ARIA exists for pages that aren’t in HTML5, or until the Scooby Doo algorithm is widely supported, and analysis shows that most ARIA is correctly used by authors.

Why add an extra complexity, which is more to go wrong and thus potentially harms accessibility?

Also available: