Even though many elements of HTML 5 have only limited application at this time due to lacking browser support, there’s little reason not to make use of them. The design of the markup language is intended to minimize dependence on user agents, failing invisibly if the browser doesn’t offer that feature, which helps encourage early use of new elements.

Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

The coolest thing coming, in my opinion, is the numerous new attribute values for the input element. It seems like everybody’s always talking about the video element — but, not being somebody who’s all that excited by video, those conversations just make me say “Meh.”

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

In the comments from my most recent article, “Supporting Standards that Support Accessibility,” a number of interesting thoughts were raised concerning the requirement (or lack thereof) of the alt attribute in HTML 5.

It’s a difficult issue.

I’ve seen numerous articles around the web which discuss the fact that HTML 5 does not require the alt attribute. To some degree, this is true: HTML 5 provides exclusions to the requirement. In situations where an image is significant but no alternative text can be provided, HTML 5 recommends that the alt attribute be left off as an indicator that the image is significant (not a purely decorational image).

It’s actually quite a bit more complicated than that — the specification describes detailed guidelines for when the alt attribute should be left off, when it should be given a value, and when it should be provided without a value.

My complaint, and the complaint of many others involved in the web standards world is against the concept of providing any reason that the alt attribute may be left off. Ian Hickson states:

Empty alt text means the image is unimportant (decorative) and should be ignored. Missing alt text means that the image is important, critical even, but that there is no fallback text provided. The user agent is expected to treat the two cases differently.

At least, that’s what the HTML5 spec says at the moment.

I believe that it is important to provide a way to distinguish the two cases above; putting both of them into the empty alt=â€?” category would be, IMHO, bad for the accessibility of the aforementioned pages.

He’s right, of course — it is quite important to distinguish between insignificant images such as decorational graphics and between significant but undescribed or undescribable images. The challenge, then, is to come up with a solution to the problem which allows the alt attribute to remain.

So…what are some possible alternatives?

The first thing that comes to mind is to add a signifier attribute. Something which indicates whether an image is significant or non-significant. This would require some revision to HTML generating tools, but certainly no greater a change than that expected for new elements. It would be best to assume a default value when the element is not provided which assumes the image is significant, for backwards compatibility.

A second possibility would be to introduce a key term available to the alt attribute which would indicate significance. This strikes me as a bad idea, since it would have relatively poor backwards compatibility, and would require selecting a term which would become unavailable as normal alt text. Nah, that’s not really going to work.

Third…I’m struggling to come up with another idea…

I’m very open to any thoughts on the subject. Problems with these ideas are welcome, as are suggestions of any off-the-wall idea you may have!

The justification that a web site is accessible because it “follows standards” contains a serious fallacy. Specifically, the assumption that standards support accessibility.

One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.

Web standards only provide accessibility to the degree that they have been designed to do so — and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)

In many (most) cases, web standards do not in any way require best practices — they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.

HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".

Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.

Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.

There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!

Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.

Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.

At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b1, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.

1. In point of fact, I can accept the inclusion of one inline non-semantic element (span) and one block level non-semantic element (div). I feel there’s ample justification to allow elements which are not specifically defined on the grounds that not all situations can possibly be covered by the specifications of the language. I see no justification, however, for the inclusion of additional explicitly non-semantic elements.