Archive for the 'semantics' Category

HTML 5 is a mess

HTML 5 is a mess”, said John Allsopp.

I agree. It is. It’s also several different kind of messes, not all of which are avoidable or bad. Let’s look at them.

The backwards compatibility mess

The first kind of mess is because it builds on HTML 4. I’m sure if you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).

You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.

But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. This page is written in HTML 5, and although your browser doesn’t “understand” it, it it still renders it.

There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.

That’s one reason why HTML 5 a mess. It’s built on a mess.

The process mess

Specifying HTML 5 is probably the most open process the W3C has ever had. Different groups with different interests battle it out over the mailing lists. Competing variant specs are springing up: Manu Sporny is devising a spec that incorporates RDFa in HTML 5, while The Mighty Steve Faulkner is writing one addressing accessibility issues including alt text and summary attributes. I’m hopeful that these will all be merged together, while simultaneusly, parts of the spec are being split out into separate specifications where there are no dependancies, such as Web Storage and Web Database.

This amorphous process is messy. But, in my opinion, infinitely better than the ivory tower of XHTML 2 academia.

The spec mess

Then, of course, there’s the real mess that John Allsopp and Matt Wilcox complain about—imprecise, ambiguous specification or unnecessary restrictions.

Why the restrictions on the time element? Why the overlap between figure and aside?

Why is the nav element so loosely specified? (“Only sections that consist of major navigation blocks are appropriate for the nav element”—define “major”, if you please.) Why can you have nav inside a header and not in a footer?

If these things bother you, you can do something about itemail the Working Group and make your feelings known.

Post-publication clarifications

I should clarify two things after some tweets and a Skype conversation with Lachlan Hunt. The first is in fairness to Hixie: he changed the definition of nav to clarify that there can be more than one per page, and I agreed that the new defintion was an improvement. But, as I’m a self-confessed dimwit, I only realised later that the word “major” leaves ambiguity as well. So that’s my brain parsing slowly, not Hixie’s bad.

Secondly, and most importantly, I haven’t had some kind of damascene conversion to the anti-HTML 5 camp. I firmly believe that it’s the best way forward for an Open Standard that allows us to write richer web pages and applications. And I’m sure that no-one, especially those in the Working Group, believes it’s perfect already. In fact, the Working Group consistently call for developer participation in reviewing the spec.

To reiterate: bitching in blogs (like I’m doing now!) and on twitter is OK, but the best way to be sure that your views are heard is to mail to Working Group.

BBC remove hCalendar from websites

An Event Apart Boston is going swimmingly, but I’m taking a break to post this story from a BBC site that explains that the BBC has taken the decision to remove the hCalendar microformat from /programmes until

  • either the BBC accessibility group does further testing and declares the abbreviation design pattern to be safe to use
  • or the microformats community settles on an accessible alternative to the abbreviation design pattern

More at BBC radiolabs blog.

(More detail and backstory)

Microformats and accessibility

I’ve long been worried about the accessibility of microformats, so experimented and found that the way that dates are marked up is inaccessible to users of the big two screenreaders, and began writing an article to that effect.

James Craig, who is 97 times more helpful than I am, decided to research a better way to embed machine-parsable dates in content.

We jointly wrote up our results in an article called “hAccessibility“, which James published today.

Comment there, please.

The Friday joke

Q: What’s black and white and brown round the mouth?
A: A nun sucking a turd.

Where the rubber meets the road: web accessibility and pragmatism

At last, the podcast audio and transcript of the talk Patrick Lauke and I gave at Geek In The Park.

Riddled with swear words (all Patrick), rambling at times (that Patrick again), you might nevertheless find it useful. (Summary)

Initial transcript provided by CastingWords, with subsequent editing by me and Patrick. Patrick did nearly all the work, and paid for the transcription. What a guy. Released under Creative Commons Attribution-NonCommercial-ShareAlike 2.0.

Geek in the Park: Pragmatic accessibility

Yay for the Geek in the Park meeting. I missed the picnic, as I was returning from monstrous partying for my kid brother’s birthday, but got there in time to actually have a pre-speaking run-through with my partner-in-crime, Pat Lauke, to make sure the two-handed presentation we’d jammed by phone and mail worked.

It was splendid to meet old mates like Matt Machell, the excellent Jim O’Donnell, as well as meet more people (and a shame I couldn’t meet others – who were these people, for example?)

My notes, combined with some notes Patrick gave me, are reproduced. These are dense, as we talked for two hours, as this is just our crib sheet rather than a full transcript (if you want the full thing, we are available for weddings, barmitzvahs and satanic orgies. Especially satantic orgies).

Continue reading Geek in the Park: Pragmatic accessibility

Breaking news: w3c specs are not the Word of God

Pretentious introduction

In the world of religious loonies, there are two main kinds of nutter. One is the fundamentalist – someone with the attitude that a tract is the work of God, perfect and unquestionable; if it’s mentioned in the Book, it’s beyond doubt no matter how daft. The second sub-genre of nutter is the exegesist: someone who believes that extra, unwritten information may be teased out of the text with enough insight and critical reading.

Web Standards evangelist types will all recognise both type of adherent to that Holy of Holies: the w3c specs.

Continue reading Breaking news: w3c specs are not the Word of God

Opening links in new windows in xhtml strict

My last post explores in detail why you can’t rely on a title attribute to warn a user that a link opens in a new window, as you’re required to under checkpoint 10.1 of WCAG 1.0.

Here’s Gez Lemon‘s script that opens any link marked rel="external" and opens it in a new window without being invalid. He’s just too damn modest to post this himself.
Continue reading Opening links in new windows in xhtml strict

New windows in xhtml strict

Sun 18 Sept, 8.30 p.m. This post is already marked “considered harmful” as the script does not give maximum accessibility, nor fill the browser with nourishing valid code. The comments are good, though: thanks Gez and Lachlan. A proper script will appear in a couple of days, so watch this space. (Hey, does that mean I’m a script-tease artist?). There’s also a good discussion of the subject on the Accessify forum.

target=”_blank”. We’ve all done it – whether because the boss says “open external links in new windows so our site is still open”, or for non-html documents, or just because we want to drive Jakob into an early grave.
Continue reading New windows in xhtml strict

Semantics, Standards, Accessibility …

… the three legs of the Stool of Truth

As the thickest member of the WaSP ATF, I’ve been having a bit of a think about what the terms Accessibility, Standards, Semantics mean, trying to reach a working definition of the three terms, and how they inter-relate (while the other ATFers do hard work).

A good, modern website is like a stool. (The wooden kind. An inaccessible website is like the other kind.) The most stable stool is the one where each of the three legs is the same length, carries equal weight and supports its load well. Of course, it’s perfectly possible to sit on wobbly stool – but if it’s too wobbly, you’ll fall flat on your arse, in much the same way as this metaphor does.

Gurus need read no further; here’s my beginner’s guide to the Stool of Truth.
Continue reading Semantics, Standards, Accessibility …