HTML 5 = Improved Web, Accessibility, Productivity?

Rich sites taking off; accessibility being left behind

Rich, AJAX-based sites are taking off. When done well, they provide rich user experiences. Unfortunately, it feels as though accessibility is being left behind. This is a sad irony, given accessibility was important in galvanizing so much support for web standards.

Screen readers struggle with dynamic pages, tag soup is still prevalent, and some browsers still don’t implement standards properly.

In addition, HTML (as it was defined almost a decade ago!), CSS and JavaScript were not built with today’s web applications in mind. Some people therefore suggest other technologies such as Flash, which has come a long way, and now includes various accessibility features, too.

But there has long been a move to update the HTML specifications. It has been slow moving but recent months have seen a number of interesting things arise.

Proposal for HTML 5 is promising

The W3C has long had XHTML 2 specification drafts, while the Web Hypertext Application Technology Working Group (WHAT WG) has been suggesting HTML 5 to deal with rich internet applications that are becoming the norm today.

In fact, the W3C voted to adopt HTML 5 as proposed by Apple, Mozilla and Opera.

Not only that, but the W3C has agreed to the proposal of having Ian Hickson of Google (and spokesperson of the WHAT WG) and David Hyatt from Apple /Safari to be the initial HTML 5 specification editors.

XHTML 2 goes down the route of strict XML-based syntax and validation (markup errors result in errors on the browser, not browsers trying to still show the page). This is nice ideally, and could allow a clean start away from the current HTML mess. However, many have felt it will be difficult to adopt and not everyone will be able to ensure well-formed markup. The HTML 5 approach has been to be backward compatible (though it now also entertains an XML-version of the markup, i.e. XHTML 5).

The other concern is for older browsers that may have to render newer version(s) of HTML. HTML 5 tries to be somewhat backward compatible, so potentially an older browser will be able to render the new pages even if it is not as visually as appealing. (XHTML 2 seems to be like this too, given older browsers will just try to treat it as HTML and anything not understood would just be ignored.)

There are certainly lots of debates going on out there about HTML 5 versus XHTML 2 and various details of each specification, but the bigger picture is the potential for improved accessibility, productivity, usability, richer applications, etc.

Better markup is the foundation

The potential comes from the richer markup that is proposed.

HTML 5, for example, introduces a whole host of new elements, from structural elements such as header, footer, nav, and section. New multimedia elements include video and audio. And new form elements/types include date, email, and datagrid. There is even a proposed event-source to catch server side events. (Read the really useful HTML 5 differences from HTML 4 article by Anne van Kesteren, from Opera.)

Key benefits for users would include

  • Consistency across web sites
  • Accessibility

Key benefits for businesses, individuals and organisations developing web applications include

  • Increased productivity
  • Legal compliance (where accessibility is a legal requirement)

The consistency benefit is interesting: while some may fear that web sites will end up looking the same, some fundamental functional features are important for consistency across sites, such as form controls.

Why? We expect desktop applications to behave in the similar ways (e.g. the menu bar along the top of OSX or the top of each application in Windows, etc). In the same way some fundamental consistency of interaction on the web will be important too, for example, how dates are picked, how email addresses are validated, how data grids work, etc. This will help new users to a site quickly adapt, rather than having to learn a subtly new way of doing something similar to elsewhere.

This will be good for accessibility because assistive technology can more easily work out what a header is, or what a nav is. It will therefore be far easier to present navigation and usage options to the users of such software. Even browsers will be able to build more accessibility features right into the browser. All this without sacrificing design and development flexibility.

HTML 5′s proposals for numerous new input types and other semantic markup elements (e.g. calendar related inputs, better data grids, header/footer elements, etc) is really key, IMO.

Anne Van Kersteren provides some useful examples of form controls:

Nowadays web developers use nifty scripts to perform form validation on the client side. Soon you’ll be able to simply write the following:

<form>
 <p><label>Name: <input name=name required></label></p>
 <p><label>E-mail: <input name=email type=email required></label></p>

 <p><label>URL: <input name=url type=url></label></p>
 <p><label>Comment: <textarea name=comment required></textarea></p>

 <p><input type=submit value=React!></p>
</form>

– Anne Van Kersteren, Improve your forms using HTML5!, Dev.Opera, 13 December, 2006

Examples of why this is beneficial:

  • Developers get to focus on developing sites and apps, rather than common controls (which would all be different between different sites).
  • Users get familiar widgets (which are probably similar to the operating system, too, making such sites quicker to learn and use).
  • Assistive technology will help their users use the site more easily. Assistive technology vendors will have richer elements to support but typically only do it once (per element per browser implementation!).
  • Improved quality as not only would HTML bloat may be reduced, even more important might be the reduction in JavaScript, hence the reduction of buggy sites, memory leaks, performance issues, etc.

This would translate into more productive businesses and organisations. The content is also potentially easier and better for indexing for search engine.

All round win-win, in my view!

Of course this is overly optimistic. Some companies already provide these pre-packaged controls with today’s HTML so some perceived efficiency/productivity may not be as high as it sounds (ignoring the extra work that might be needed to make such controls accessible, search engine friendly, etc).

With something like HTML 5 being adopted and used widely, hopefully this means people can spend more time innovating, and less time dealing with browser problems!

When will this happen!

So lets come back down to earth again!!

Its all well and good to talk about the potential of something like HTML 5, but will it ever happen? Almost everyone will agree that this will all take a long time to adopt.

Browsers need to add new code. (Will those browser releases even be in remotely the same time frame? Does this ultimately depend on Microsoft’s Internet Explorer supporting it?)

And getting assistive technologies such as screen readers to support a new specification may take even longer.

If these new specifications are desirable, what will provide the impetus for tons of web developers to want to learn something new, for businesses to spend resources in up-skilling and moving to these?

Search engines.

What? Yes, search engines. If search engines were to buy into HTML 5 and say they will index the new tags, then businesses may have compelling enough reason to move into that direction. Better indexing may mean more accurate results. (Ranking of course is different to indexing which is a separate issue!)

Of course some people may now just have more HTML elements to abuse and stuff with inappropriate content. I don’t imagine any time soon search engines saying some elements will have higher precedence for ranking purposes, and instead continue to focus on social factors, how popular the site is, etc. But indexing is still important: let search engines find content, but let them also understand what is there so if the page does rank, then the right information can be shown, which helps users decide if they want to follow the link.

There are signs that things are moving in the right direction: Google as well as Apple, Mozilla and Opera are putting weight behind HTML 5. Ian Hickson has already started providing some initial analysis for HTML 5 parser implementors, for example.

But there is one big player missing in the above that can also be make or break. Microsoft. Whatever we feel about the company (most web developers that follow web standards despise IE!) their browser install base is so wide it cannot be ignored.

What about Microsoft and Internet Explorer!

This may feel odd to think about, but there’s another potential winner in HTML 5 adoption: Internet Explorer!

Microsoft’s IE is generally regarded as the least capable of modern browsers (e.g. buggy/limited CSS support, limited W3C DOM support, etc). With something like HTML 5, it is a clean slate for Microsoft.

If Microsoft want to rebuild their reputation with web developers, they should also buy into HTML 5, but this time truly support the standards, rather than go half way, win the wars and then act as most monopolies would!

There are people at Microsoft, such as Chris Wilson who leads the IE development, to whom standards is definitely important (their need to support older sites full of tag soup — partly their own doing — has slowed them down from making fixes and supporting even more modern standards) so it may be more realistic this time than in the past.

Where next?

There are definitely some odd technical decisions, outstanding concerns, and debates in terms of where XHTML 2 and HTML 5 are headed. With the W3C’s adoption of HTML 5, XHTML 2 seems dead for now, but it seemed to have a few good things which don’t seem to be there in HTML 5. HTML 5 also has a few seemingly inconsistent decisions. And so on.

So what can be done? A few things, I guess. E.g.:

Be Sociable, Share!

    One thought on “HTML 5 = Improved Web, Accessibility, Productivity?

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>