This post was originally published on the Yahoo! Accessibility blog.
One aspect I haven't seen fully addressed in the argument for using HTML5 tags, especially when considering methods to bullet-proof methods, is user benefit. Yes, the new elements in HTML 5 (nav, footer, header, aside, section, article) give developers a more expressive language. However, if that language isn't interpreted by the browser to actually mean something then there is less, and in some cases, no benefit to the end user.
To put a finer point on this: currently browsers don't consistently translate HTML 5 elements into accessible information. You could defer the solution to that problem to the browsers. That would be a valid position if we didn't already have an viable alternative in ARIA roles. Unlike HTML 5, ARIA works now, and is consistently supported across the A-Grade. Plus ARIA is supported by assistive technology like screen readers.
What do I mean by "works now"?
Consider: <div role="navigation">.
This is navigation
One tag! It's simple. So, no need for "bullet proof" wrappers, SS swapping, or Resig's HTML 5 Shiv. I like simple.
With the death of IE 6 we can use attribute selectors to style these elements. If you want to/or need IE 6 support, you could also add a class. Using a class would also facilitate future swapping out of the tag with native HTML 5 elements when they are supported without having to change CSS. Which brings me to...
Yes, you could replace <div role="navigation"> with <nav> when it's supported across the A-Grade. But it isn't necessary. ARIA is designed as a future-compatible, bridging technology, enabling us to deliver semantics when native tags aren't available. It'll always be useful. Esp. since we're going to hit the same problems when HTML 6 comes along. :)
So, I'd advocate before you consider use of an HTML5 tag and the associated hacks for getting it to work cross browser, first consider if the semantics you need are available in ARIA. If they are, use ARIA. If not, then consider HTML5.