Articles for February 2011

Do you remember the trick how to find out that you went to certain web sites by analysing link colour (now patched in Firefox)? There is much your browser tells about you if you just create a few HTML elements.

Mike Cardwell has found an interesting way to detect if you are logged into social web sites. The easiest trick lies with GMail. Mike created a photo and uploaded it to Google. If you add this image to an HTML document and add event handlers for the success and failure case you can check if the visitor is logged in or not – as the photo gets delivered when you are and GMail delivers a 404 document when you are not:

<img style="display:none;"
     onload="logged_in_to_gmail()"
     onerror="not_logged_in_to_gmail()"
     src="https://mail.google.com/mail/photos/static/AD34hIhNx1pdsCxEpo6LavSR8dYSmSi0KTM1pGxAjRio47pofmE9RH7bxPwelO8tlvpX3sbYkNfXT7HDAZJM_uf5qU2cvDJzlAWxu7-jaBPbDXAjVL8YGpI"
/>

This works in all browsers and can be used to for example send mailto: links to GMail directly. Notice that this just checks that you are logged in, it doesn’t mean you get access to content.

For Facebook and Twitter, this doesn’t quite work. Instead, Mike tries to read content with the APIs and relies on errors to be thrown on 404 responses:

<script type="text/javascript"
        src="https://twitter.com/account/use_phx?setting=false&amp;format=text"
        onload="not_logged_in_to_twitter()"
        onerror="logged_in_to_twitter()"
        async="async"
></script>
 
<script type="text/javascript"
        src="https://www.facebook.com/imike3"
        onload="logged_in_to_facebook()"
        onerror="not_logged_in_to_facebook()"
        async="async"
></script>

This fails to work in Internet Explorer and Opera, but still works nicely for the other browsers. In Firefox you can work around this using the Request Policy add-on.

It’d be interesting to see what other social web sites can be detected with some simple onload and onerror handlers. Know any others?

Last week I went to the London Ajax User Meetup in London, England to deliver two talks about HTML5. One was a re-run of a talk I gave at MIT about Multimedia on the web and the second was a call to arms to use HTML5 sensibly. You can go over to Skillsmatter web site to see both talks back to back – but be sure to catch the notes to the second talk in this post, too.

In addition to my notes here there is also a great write-up of the evening by Ian Alderson available on the web.

Multimedia on the web

We’ve covered this talk before in the blog post here and you can read the extensive notes for the whole talk with code examples on my blog. The slides of the multimedia talk are on slideshare and here:

You can see “Multimedia on the web” on any HTML5 enabled device here (courtesy of vid.ly) or embedded here:

Using HTML5 sensibly

Using HTML5 sensibly was a talk I wanted to give for a long time. Rather than just giving the facts, I wanted to raise some questions every developer should ask themselves, the HTML5 working groups and everyone who cares to listen. We are in the middle of a big change in our development environment and not many people realise that we are breaking a lot of old conventions without fallback.

You can get the slides on Slideshare or see them here:

You can see “Using HTML5 sensibly” on any HTML5 enabled device here (courtesy of vid.ly).

Notes on “Using HTML5 sensibly”

I started the talk by telling the story of the Antarctic Snow Cruiser – a marvel of technology built in 1939 to allow a crew to explore Antarctica. The job of the Cruiser was to give the crew all the neccesary creature comforts and allow them to drive through Antarctica, which is both very cold and also features massive cracks that the vehicle somehow needs to get over. The ingenious solution was to have huge wheels that can be retracted into the Cruiser to prevent them from getting brittle over night and to push the vehicle over the cracks. The Cruiser was built in a rush and tested on the way to the port to go down to Antarctica. It was a hit with the press and people delayed the whole trip even more by wanting to have their photo taken with it. Upon arrival the vehicle almost crashed into the sea as the ramp built for its delivery onto the ice was not strong enough. Even worse, once on the ice the Cruiser couldn’t get a grip and the wheels spun uselessly, almost overheating the engine. Despite all the hype, the cruiser was a massive failure.

A few things went wrong with the cruiser:

• It was purely engineering driven
• It was tested while on the road
• It was never tested in the real environment
• There was a massive media excitement before it proved its worth

Much like we deal with HTML5 nowadays. A lot of the information about HTML5 is marketing driven and used to sell a certain environment or browser to people. Instead of real applications and day-to-day use web sites we create demo sites to show what “HTML5 can do for you”. The term HTML5 gets washed out as it is used both for implementations of parts of the specification but also for browser-specific code that only works in a certain environment.

This is partly because of the specifications and the different players in the HTML5 world itself. The specs do not only contain definitions of markup but also JavaScript APIs and instructions on how to write a browser that renders HTML5 content. This is great as it takes away the liberty browser vendors had in the past in “creatively” applying the HTML4 specs, but it also means that people can focus on parts of the spec and of course rant about all the other parts. You’ve probably seen one talk about the amazing cool new semantics of HTML5 markup and another about API implementations using completely non-sensical markup back to back. This is what we get right now as the specs are too big and all-encompassing for implementers.

One of the main topics of the HTML5 work is pragmatism – XML and strict HTML just used too many things we simply don’t need. This shows itself a lot in the simplification of a plain HTML document. In HTML4.01 strict this was:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
  <meta http-equiv="Content-Type" 
        content="text/html; charset=UTF-8">  
  <title>HTML - c'est moi!</title>
  <link rel="stylesheet" type="text/css"
        href="styles.css">
  <script type="text/javascript" src="magic.js">
  </script>
</head>
<body>
  <h1>Heading! Everybody duck!</h1>
  <p>I am content, hear me roar!</p>
  <p class="footer">By me!</p>
</body>
</html>

Neither the long DOCTYPE definition nor the http-equiv was ever used by browsers. It is not needed for browsers to do their job. In HTML5 this is a plain Vanilla document:

<!DOCTYPE html>  
<html lang="en">
<head>
  <meta charset="utf-8">  
  <title>HTML5, c'est moi, ou HTML...</title>
  <link rel="stylesheet" href="styles.css">
  <script src="magic.js"></script>
</head>
<body>
  <h1>Heading! Everybody duck!</h1>
  <p>I am content, hear me roar!</p>
  <p class="footer">By me!</p>
</body>
</html>

Much simpler and shorter. In addition to that HTML5 also includes new semantic elements:

<!DOCTYPE html>  
<html lang="en">
<head>
  <title>HTML5, c'est moi, ou HTML...</title>
  <link rel="stylesheet" href="styles.css">
  <script src="magic.js"></script>
</head>
<body>
  <header><h1>Heading! Everybody duck!</h1></header>
  <section>
    <p>I am content, hear me roar!</p>
  </section>
  <footer><p>By me!</p></footer>
</body>
</html>

This gives us handles for styling and tells the browser what the different parts are. The simplification goes further though. As people never seemed to have bothered to write valid XML in HTML it is now also completely OK to mix upper and lower case and omit quotation marks around the attributes (if the attributes have one value, multi value attributes like classes need quotes around them once you add more than one value):

<!DOCTYPE html>  
<html lang=en>
  <TITLE>HTML5, c'est moi, ou HTML...</title>
  <LINK rel=stylesheet href=styles.css>
  <script src=magic.js></SCRIPT>
<body>
  <HEADER><h1>Heading! Everybody duck!</h1></header>
  <section>
    <p>I am content, hear me roar!</p>
  </SECTION>
  <footer><p>By me!</p></FOOTER>
</body>
</HTML>

Browsers are forgiving enough to fix these inconsistencies for us. For example the generated code in Firefox is:

<!DOCTYPE html>  
<html lang="en"><head>  
  <title>HTML5, c'est moi, ou HTML...</title>
  <link rel="stylesheet" href="styles.css">
  <script src="magic.js"></script>
  </head><body>
  <header><h1>Heading! Everybody duck!</h1></header>
  <section>
    <p>I am content, hear me roar!</p>
 
  </section>
  <footer><p>By me!</p></footer>
</body></html>

However, if we were to omit the closing </p> tag in the <section> the generated code looks different:

<!DOCTYPE html>
<html lang="en"><head>  
  <title>HTML5, c'est moi, ou HTML...</title>
  <link rel="stylesheet" href="styles.css">
  <script src="magic.js"></script>
</head><body>
  <header><h1>Heading! Everybody duck!</h1></header>
  <section>
    <p>I am content, hear me roar!
      <footer></footer>
    </p>
    <p>By me!</p>
  </section>
</body></html>

As you can see, the <footer> got moved into the paragraph inside the section. Why? Who knows? The issue is that we ask a browser to make an educated guess for us and as a browser doesn’t understand semantics, this is what we get.

Which leads me to a few questions we need to ask and find the answer to:

• Can innovation be based on “people never did this correctly anyways”?
• Is it HTML or BML? (HyperText Markup Language or Browser Markup Language)
• Should HTML be there only for browsers? What about conversion Services? Search bots? Content scrapers?

The next issue I wanted to discuss is legacy browsers which seems to be a euphemism for IE6. The issue with IE6 is that when you use the new semantic HTML elements exclusively then they can’t be styled in this browser. By using the correct new syntax that should bring us a lot of benefits you condemn older browser users to see unstyled documents.

There are a few ways around this. The first one requires JavaScript – if you create the element using the DOM first you can style it in IE:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <style>header{color:#fff;background:#369;}</style>
  <script>document.createElement('header');</script>
</head>
<body>
  <header><h1>Hello!</h1></header>
</body>
</html>

This technique has been wrapped up nicely in a script called HTML5 shiv by Remy Sharp. Of course, this means that you make markup dependent on JavaScript to work which is not what markup is about, according to purists of the web. You can work around that dependency in a few ways. You can write HTML5 as XHTML, you can use conditional comments or a namespace or you can use both the new semantic elements and DIVs with a class around them to please all browsers:

<!DOCTYPE html>
<html lang="en">
  <head><meta charset="utf-8">
    <title>HTML5, c'est moi, ou HTML...</title>
    <link rel="stylesheet" href="styles.css">
    <script src="magic.js"></script>
    <style type="text/css" media="screen">
      .header,header,
      .footer,footer,
      .aside,aside,
      .section,section{
        display:block;
      }
    </style>
  </head>
  <body>
  <div class="header"><header>
    <h1>Heading! Everybody duck!</h1>
  </header></div>
  <div class="section"><section>
    <p>I am content, hear me roar!</p>
  </section></div>
  <div class="footer"><footer>
    <p>By me!</p>
  </footer></div>
</body>
</html>

This seems to be the most pragmatic solution but is a lot of extra effort.

The main issue is that not only legacy browsers are failing to support HTML5 properly which is why people tend to use a library like Modernizr to check for HTML5 support before applying it. Modernizr adds classes to the HTML element after checking what the current browser supports and thus gives you handles to use in progressive enhancement. All the hacks and fixes are also bundled in HTML5 Boilerplate, including server settings and ways to make legacy browsers behave. In essence, the much smaller Vanilla HTML5 markup becomes a lot of code again if you test it in the real world.

If you also want to use all the cool new JavaScript APIs you can use Polyfills to make legacy browsers do something with the code you write.

Which leads to more questions we need to answer:

• Should we shoe-horn new technology into legacy browsers?
• Do patches add complexity as we need to test their performance? (there is no point in giving an old browser functionality that simply looks bad or grinds it down to a halt)
• How about moving IE fixes to the server side? Padding with DIVs with classes in PHP/Ruby/Python after checking the browser and no JS for IE?

The last feature of HTML5 I want to talk about is Video and Audio. Again, there is much more complexity than meets the eye:

Tecnically, embedding an HTML5 video should be as simple as this:

<video src="interview.ogv" controls>
  <a href="interview.ogv">Download the video</a>
</video>

Once you consider all the different formats needed for different browsers though it becomes a lot more work:

<video controls>
  <source src="interview.mp4" type="video/mp4">
  </source>
  <source src="interview.webm" type="video/webm">
  </source>
  <source src="interview.ogv" type="video/ogg">
  </source>
  <p>Download the 
    <a href="interview.mp4">video in MP4 format</a>.
  </p>
</video>

The reason is intellectual property, legal codec battles and implementation of video in different browsers and platforms. In essence, you need to provide the video in three formats. Of course when there is a need then some company will come up with a solution. Vid.ly is a service by encoding.com that provides you with a single URL that sends the video in the right format to the device you use. All in all they create 28 different formats for you to cater for all kind of mobiles and browsers.

The other big issue with HTML5 video is that there is no protection from downloading the videos. This is as intended but a big problem when it comes to premium content on the web. As discussed in the comments of this post by Adobe publishers want to have a way to stop people from downloading and reusing their videos but instead just want their audience to watch them in a closed environment.

All in all there are a few questions to answer when it comes to HTML5 video:

• Can we expect content creators to create video in many formats to support an open technology?
• Can a service like vid.ly be trusted for content creation and storage?
• Is HTML5 not applicable for premium content?

In the end, I want every developer and designer out there to take a stand and demand answers to these questions. There is no point in just saying “that’s how it is”. When we keep our technologies closed and when we rely on scripting to make web sites work we do break the web in the long run. The current debate about hashbangs for links shows this.

Everybody can take part in the HTML5 working group and add documentation to MDN – time to get to work.

Firefox 4 is just around the corner and the updated version of the Firefox API has been frozen for some time now. The Add-ons blog is reminding add-on developers to Update your add-on for Firefox 4. Add-ons that are compatible with Firefox 4 are eligible for a competition to be featured in a collection to showcase the best Firefox 4 add-ons. So, if you’re an add-on developer, check out the details of how to update your add-on, read the contest rules, and enter the competition.

I just returned from my first ever FOSDEM conference in Brussels, Belgium – a hard-core open source conference with more Linux Distros and amazing open source software packages being showcased that I could take in (although this might also be because of the fact that the conference served beer all day).

The free conference attracts a few thousand attendees and you meet people you normally don’t see at the bigger and more expensive conferences. It was a massive pile-up of open innovation and high-tech presentations that didn’t shine by their looks (by a long shot in some cases) but definitely by their content.

Mozilla had a room for the duration and many a great talk lined up so there were never any empty benches. I have to admit that I was wondering if the talk I had planned to give together with Robert Nyman would work with this crowd and was quite surprised to see our room packed to the brim. Due to fire regulations we had to stop allowing people in ten minutes before the talk.

For all the people who couldn’t attend, here are the slides and the audio recording of “Moving to the client – HTML5 is here”:

[ Editors note: as slideshare is having trouble with their image generator we embedded the flash version for now. You can also download the slides as a PDF if you want to ]

It was a massive success and I hope we encouraged some people to give HTML5 a go!

Seeing what other people do in an audience at a conference can be interesting. When waiting for the next talk in the incredibly claustrophobic seats at FOSDEM last week I saw something that got my attention: the Desktop of an operating system being debugged using a web inspector:

Turns out, the guys doing that are from Jolicloud – a company that strives to offer a OS alternative for old and low-spec computers by only providing basic OS tasks and leaving the day-to-day work tasks to web applications hosted in the cloud. Sounds familiar? Google does the same with their Chrome OS and the Cr48. The main difference is that Jolicloud is based in Europe and a dedicated, affordable Netbook is available even for us across the pond.

Jolicloud is an interesting approach to fix the problem of outdated hardware and any Desktop system that runs on HTML, CSS and JavaScript gets my attention. Hence I took the opportunity to interview the guys on the spot and get some answers:

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

If you want to give Jolicloud a try you can check it out at http://www.jolicloud.com/.

Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

Contributors to Wiki Wednesday will get recognition in next week’s Wiki Wednesday announcement. Thanks in advance for your help!

Last week’s contributors: Trevor Hobson, Boris Zbarsky, bullines, BYK, MatrixFrog, mhitza, evilpie.

JavaScript

• Shell global objects
• A re-introduction to JavaScript
• Introduction to Object-Oriented JavaScript

SpiderMonkey

• Shell global objects
• JS_IsExceptionPending

Developing Mozilla

• Adding a new style property
• Displaying Places information using views
• Mozilla DOM Hacking Guide

Extensions

• Displaying Places information using views
• Post data to window
• XPCOM category image-sniffing-services

XUL

• Troubleshooting preference windows
• -moz-stack-sizing
• XUL template Tag Reference

XPCOM

• nsIDirectoryIterator
• nsIWinAccessNode
• nsIDragSession

Interfaces

• nsIMsgDBHdr
• nsIUserInfo
• amIWebInstallInfo

Plugins

• PluginArray

Also, we need someone to write about Cocoa NPAPI plugins for Mac OS X.

CSS

• -moz-column-gap
• percentage
• normal

SVG

• Introduction
• Basic Shapes
• Fills and Strokes

HTML

• head
• Focus management in HTML
• Drawing text using a canvas

DOM

• nsIDOMNSHTMLDocument
• Gecko-Specific DOM Events
• nsIWorkerGlobalScope

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Today we are featuring John Foliot co-chair of the subcommittee on the accessibility of media elements in HTML5 and well-known accessibility warrior of the wild wild web.

John’s been around the web, mailing lists and W3C meetings for longer than he’d care to remember and has always been a voice of reason when it comes to making the web accessible for everyone and still use new technologies. As this is a topic not often covered in the HTML5 context we thought it a good idea to bring up.

The video interview

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

Ten questions about HTML5 for John Foliot

1) There is quite some confusion going on about what HTML5 is. Even the W3C shot an own goal with the release of the HTML5 logo and describing it as a branding for modern development that encompassed other technologies. What is your definition of HTML5?

Personally, HTML5 is the next major iteration of HTML – Hyper Text Markup Language – which will be standardized by the W3C in due course. It will effectively take over from HTML4.01/XHTML1.1, which has not been updated since December 1999. It is one of the core standards that support today’s Open Web Technologies.

I understand and accept however that in terms of marketing and mass communication, having a term that describes the idea of the current larger eco-structure is by necessity going to be abstract. The conversation around naming has gone on for some time now, and I suspect that most developers remotely interested already know that the stack of Open Web Technologies we are using needs a name (my buddy Bruce Lawson dubbed it NEWT).

But the horse was already out of the gate, and HTML5 is the name. So when communicating with developers in general today, I believe we all understand what is meant by HTML5. HTML5 has also become the way the mainstream thinks of what it is we are doing, so I really don’t worry too much about a marketing name. Over time, a new buzz word will emerge, the world will move on, and HTML5 will mean the standard for hyper text markup language – fifth iteration.

2) There seems to be two battling sources of truth about HTML5. The WHATWG and the W3C. When would you consider which group to be more important? What is the relationship between them?

Their relationship? Complicated.

The relationship acknowledges that two diverse groups can share a common goal, and working together can lead to progress. But it is hard work.

The WHAT WG serves a useful – likely critical – role in the emergence and growth of many of the Open Web Technologies. With the support of many (but not all) of the browser vendors, a common sharing of technical ideas, including experiments and evaluation by multiple teams, leads to improvements in the technology. It is the place of the engineers, and it is accustomed to working in an Agile environment, which works well for engineers. It’s an exciting place where new ideas emerge and first get roughly specc’d out, and then refined, seeing greater support in developmental browsers, and then reaching released browser versions.

However, even if tentatively working, those specs may not yet be complete, even if being implemented; often implementation is varied from browser to browser, and shortcomings (sadly often with regard to accessibility) are often significant.

The specification WHAT WG are working is constantly evolving – which is good – but it makes it very difficult for large entities outside of the browser vendors to keep up. Large scale projects require more stability than what a “living specification” can provide, as by its nature that specification is in constant change. Witness this recent comment on a developer’s blog:

“The worse part of it is that you can’t simply search blogs/forums or look the documentation to figure out how to solve the problems, since “nobody” knows how to do those things, information gets outdated really fast with the release of a new OS version, documentations are very poor and doesn’t cover edge-cases, specs are constantly changing and different versions of iOS adopt a different set of rules…” – and that was just trying to get <video> to work properly on the iPad.

As well, by organization and politics, not all vested interests are part of the WHAT WG process, which can be problematic but not insurmountable.

Microsoft is not part of the WHAT WG, and likely never will be. We can rail on about the problems that IE has wrought upon us, but with a current majority market-share we simply cannot ignore it. So the WHAT WG is somewhat ham-strung by this situation.

I am known as being a staunch W3C supporter, as I believe very strongly that they best carry the banner for Web Technologies on a global level. The W3C is more than just websites in browsers; their Standards cover a wide scope of related technologies that all leverage the larger network, and whenever possible the W3C strives to ensure that they can all work together. It is a global organization that has financial support and backing from national governments, academic institutions, and technology companies that rely on the global internet network. I acknowledge however that like any large entity, it can sometimes struggle with rapid movement – bureaucracy being a necessary evil in any globally reaching organization.

For a younger person, involved in the daily race that is this new technology, this pace can be understandably frustrating, but engineers working in larger corporations such as IBM, Microsoft, etc. are accustomed to this already. Nobody has to like it, but it exists.

The WHAT WG explores ideas and works out wrinkles, W3C stabilizes, scrutinizes and “publishes” a benchmark that everyone can refer to. Both roles are important, but each is unique.

As to the “truth”, I will leave that to others to decide.

3) You are quite an advocate of accessibility. Do you see the new open technologies as a benefit for accessibility or are we forgetting about
it?

I think much of what HTML5 is starting to deliver will be of benefit to all users, including those using Assistive Technology. However much of what is promised is not yet supported in all browsers, and related technologies – Assistive Technologies – have a long way to come to leverage this benefit.

For example, most browser rendering engines do not do native processing of the landmark elements (I believe Firefox 4 uses an HTML5 rendering engine), and support for other parts of the emerging spec that have an impact on accessibility is still lacking. All the more reason to get HTML5 Standardized; certainly to Candidate Recommendation at the W3C.

I think that some of the emergent stuff that the WHAT WG is working on occasionally falls short on accessibility concerns; thankfully less so now than when some of the earlier HTML5 work was undertaken.

Overall, I am generally thankful to see how much the awareness for accessibility has grown, and the generally productive dialog between engineers and accessibility specialists.

4) A lot of showcases of HTML5 show a certain effect but fall behind in basic accessibility concerns. There’s no keyboard interaction and a lack of testing for support. You find empty links pointing nowhere and HTML that is stored in the document for later use – like a whole list of error messages that get shown and hidden when needed. What could be done about this? What is your message to developers why keyboard access or even non-JavaScript fallbacks matter?

I think part of the problem, perhaps the biggest part, is lack of education. The barrier to entry for creating and posting to the web is extremely low: any fool can do it, and so even fools do – without knowing or understanding what it is that they really are doing. It is also hurt by web-sites and blogs that recommend some of these poor techniques as “the way to do…”, further perpetuating bad coding practice.

I think one of the other problems, especially with regard to accessibility issues, is that many developers (that have any kind of engineering background) have become very comfortable, even dependant on, the AGILE development process: code it, test it, break it, fix it, test it, break it, fix it,… I can’t count how many times I’ve heard “This is just our first iteration, we’ll get to the accessibility stuff in a future build.” The problem here is that accessibility is relegated to the role of ‘feature request’ instead of ‘core requirement’. Here again, it’s a larger education issue: mainstream developers need to understand and commit to making accessibility a core requirement, which then helps shape the functional and technical decisions that they will be making as their project evolves.

Keyboard access is an important requirement for many users, and increasingly not just users with disabilities. The massive growth in web content being created for mobile devices is helping make developers more aware of this fact. I challenge everyone reading this piece who creates web content to remove the battery from their wireless mouse for one day, and then test their site(s). This is perhaps one of the easiest “accessibility tests” any developer can do, as it does not require any special tools (hardware or software) for testing, and yet has a huge impact on both non-sighted users as well as users with various forms of mobility impairment.

With regard to JavaScript, the W3C Web Content Accessibility Guidelines 2 (WCAG 2) are more relaxed about JavaScript than WCAG 1 was. Virtually every browser out there today supports JavaScript, and client-side scripting is a necessary piece of today’s modern web infrastructure: remember that most Adaptive Technology interacts with these web browsers, so the pitfalls and problems of relying on JavaScript for ‘mission critical’ functionality are equally present for all users. Again, the real answer to this problem is education.

5) Let’s talk assistive technology. As markup and scripting should not only be targeted towards certain browsers we need to know what for example screen readers can do these days. How is the support for the new technologies?

First, I define Assistive Technology as a collection of off-the-shelf software tools, specialized programs, and alternate combinations of hardware; all are Assistive Technology: Dragon not only types when you talk, but provides a hands-free solution to UI interaction to those with severe mobility issues; screen readers are programs that communicate between browsers and other UI tools, and the operating system, leveraging the OS’s accessibility APIs; and Braille output bars connected to various devices allowing for a specialize output for those that require it. OS level offerings such as VoiceOver has been a boon to non-sighted users (allowing them to interact with their iPhones and iPads) and can also be considered AT.

Screen readers are sophisticated software, and while some screen readers such as NVDA are actively working to keep up with improvements in HTML5, the majority are sadly (I believe) waiting for a more formal standard to settle down before committing resources to re-factor their software. Whether this is the right decision or not is not really the question – it isn’t a question, it is an apparent fact.

It is a difficult chicken and egg scenario, and it is one of the reasons why I continue to advise that production class development proceed cautiously when using many of the new “HTML5″ technologies. The silver lining in this story is the fact that ARIA has pretty good support in the current screen readers, and so developers can safely rely upon most of ARIA today, in concert with many of the HTML5 goodies. Many of the current UI JavaScript libraries (such as YUI3 and jQuery UI) are also helping out here, so working devs should be looking at a robust blend of current and new technology solutions.

6) One very important thing to make a document understandable for assistive technology is maintaining a logical order, especially when it comes to headings. With HTML5, we have sections and articles, hgroups and heading order in parts of the document rather than the full document. There is even implicit outlining of the document. How does assistive technology deal with that? Do we block out users by doing the right thing?

This is actually a very topical issue right now, as recently (January2011) many have come to question the viability and usefulness of the hgroup element in HTML5. W3C Process is such that any real dialog and discussion on this issue is being deferred to later this spring, as the Working Group is trying to clear older bugs and issues that were raised prior to the end of September 2010 cut-off date. I believe that currently no browser supports hgroup

The outline algorithm for headings is a great idea which has not yet seen implementation or support in Adaptive Technology. The idea is that the browser would heuristically know that an <hx> element was actually supposed to be at an appropriate level (say <h3>) based upon its surrounding ‘inheritance’.

This makes the outline and structure of a composite document more legible and understandable from the DOM on out to user-interfaces, whether the GUI of the browser, or Adaptive Technology. In effect the browsers would ‘re-write’ the heading level. The need for doing something like this has been understood and around for some time: XHTML2 had proposed a numberless <h> element that would have helped achieve the same goal, but for whatever reasons (likely the simple aversion to XHTML2 as being “wrong”) the idea was not carried into the work of the HTML5 group. Despite the lack of support for this feature today however, the appropriate usage of headings to ‘chunked’ content is still an important requirement for users (and especially screenreader users) – even if the actual heading order in the DOM today is ‘incorrect’ screen readers can and do use headings to facilitate in-page navigation. Today, it’s just not pretty (and sometimes – often – incorrectly ‘stacked’), but useful still the same.

Sections and Articles are 2 elements that have not yet really seen any kind of actual implementation in the browsers (although I believe that Firefox 4 will start to support them ‘natively’), so at this time they are still in the “this is conceptually a good idea” stage for all practical purposes. However, for browsers that do not have native support for these elements, they treat them as non-semantic divs, and so by adding ARIA landmark roles today they can be made quite navigable/accessible to AT. As a forward looking best practice I think that it is one of the things that developers can start implementing today – just don’t forget the ARIA landmark roles.

7) One thing I really loved when I found it in the HTML5 specs is a definition of figures and captions. However, when you use them and you want support for assistive technology you need to use ARIA labeled-by and assign a unique ID for every figure to connect it logically with the caption. That is extra effort a lot of developers will not go through. I find a lot of ARIA things very verbose. Are there any efforts to streamline the communication between the different standard bodies?

Absolutely!

ARIA as a specification/technology has been with us for a long time – almost 10 years now – but it has only been within the past 3 to 5 years that we’ve seen any real support in tools such as screen readers. ARIA however was built as a bridging technology, and one that was designed as much for remediation as forward development: go back and add the following bits of stuff to make your existing widget accessible. Because of this, yes, sadly, it is hardly elegant or compact. It has been however a chicken and egg problem since it was first addressed.

One of the significant pieces of work that the W3C Accessibility TaskForce has focused on has been ensuring that ARIA functionality is being integrated and mapped back to emergent HTML5 elements and attributes. While this work is not yet completed, there is a commitment to ensure that it is completed before HTML5 (the markup language) becomes a full recommendation.

Looking at the 2 examples you pointed out – figures and captions – the longer range plan is that these will map directly to the browser parsers and on to the Accessibility APIs, so that down the road they will simply “work” as advertised on the tin.

Adding ARIA attributes today is a belt and suspenders approach to both future-proof your content, but also ensure that it is accessible today. In many ways, it is very similar to the vendor prefixes used in CSS3: the ideal is to simply declare the property, but because it is still emergent technology, today we need to prepend the property with a vendor prefix (as in, for example: -moz-margin-end, -webkit-margin-end – where you must declare it twice in your style sheet to target both browsers). Same basic idea: yes, more work for developers, but there is no easy answer.

8) What do you consider the biggest problem of HTML5 video and audio to date? Is it the lack of options to protect premium content? Or the lack of a supported format for subtitling and captioning? Encoding woes?

Actually, I think all of the above contribute to a lack of maturity today.

The encoding issue will remain (I believe) a complicated political dance for some time into the future, with the average content producer left with no choice but to encode twice if they want to use <video> natively for all browsers. HTML5 currently lacks a means to fully support the identified needs of users with various need, although the proposed <track> element is certainly going to help here (but AFAIK no browser is supporting it today,or the ability to extract <track> data via a native interface).

I fear that the time-stamp format is a debate not yet completed (despite WHAT WG’s overwhelming support for WebSRT, err WebVTT, or whatever they decide to call it next). I think this was all but guaranteed when the SMTPE (Society of Motion Picture and Television Engineers) announced their industry supported SMPTE Time Text Format, based upon TTML. When commercial content providers make up their own minds about a time format,one would suspect that the browser vendors (pressured by online content distributors) will pay attention (especially given the current mood towards web captioning in Washington). While no browser today has staked a firm either/or position here, I get a sense that at least Microsoft will likely support both.

Issues surrounding DRM and parental controls – admittedly unpopular with a generation used to Pirate Bay and torrent feeds – are both issues that should be addressed,but likely will not be any time soon, further retarding widespread implementation and uptake in my opinion: commercial content providers will want *some* form of DRM, even if it can be hacked – the hacking becoming as much the criminal act as taking the digital asset.

Meanwhile, alternative solutions to the native <video> solution, from Flash and Silverlight to QuickTime itself, are quietly developing and shipping DRM solutions to clients eager to have this form of protection for their content – just look at Netflix. What I find curious is that many of those loud voices decrying DRM have no issue buying MP3s from iTunes (which can only be shared on 3 machines registered with Apple).

9) Canvas seems to be another big accessibility issue. Do you know of anything that is being done to make the changes you plot onto a canvas element understandable to assistive technology? Does SVG suffer from the same drawbacks?

Yes, Canvas remains a tricky accessibility challenge. Sadly, I’ve not been as focused on that aspect as I have on the media stuff, but I have faith and trust in the accessibility folk who are working out the kinks. RichardS chwerdtfeger (IBM) is the chair of the Canvas Accessibility sub-team and is a very smart engineer, and all of the browser vendors are in active discussion in that sub-team. My understanding is that there is a general consensus on the subtree DOM, although cross browser support for the solution is not yet there. There remains issues with caret focus and textMetrics interaction with screen magnifiers, as well as how to convey absolute positioning of all content to screen magnifiers and screenreaders who make use of Braille.

SVG, as a technology, is very different than Canvas and for the most part there are few accessibility issues with SVG. There’s a good over-view of accessibility Features of SVG available.

10) The silver bullet for safely using new technologies seems to be object detection. You test if the browser supports something before you apply it. This never worked with assistive technology. Why is that the case? Why can’t we just say if(window.screenreader)?

There are a number of reasons why this is not feasible.

For one, “screenreader” is a class of software tools that all behave slightly differently. Yes, today in the English speaking “Western” world,the JAWS software package holds a commanding share, but alternatives such as WindowEyes, Hal/Supernova, ZoomText and upstarts like NVDA and Serotek’s SAToGo are challenging the status quo. Yet none of these tools behave in exactly the same way, and at times their approach to user-interaction can differ greatly. Add foreign language tools such as the Korean Sense Reader Professional and the Brazilian Leitor de Telas – to name but two – and sniffing for a screen reader becomes somewhat futile: if you know I am using SAToGo (for example), what does that mean to you as a developer, exactly?

Things get worse however, as not only do you need to account for ‘brand’ of screenreader, but also version. While WebAIM’s Screen Reader Survey last year confirmed that most users keep their software up-to-date (74.6% within the first year), that still leaves almost 1 in 4 using software that can be as much as 3 years old or older. Developers need to remember as well that screenreaders are not part of the browser, but rather an OS level software tool that interacts not only with the browser, but also with other tools such as text editors, spread-sheet applications, and other productivity tools on their computers.

Finally what of VoiceOver? The OS level screen reading option from Apple is present on virtually every system they ship today, from OSx to iOS – there is no guarantee that simply because it is there, it is being used – or that the person using it is in fact blind. In fact many sighted users will have a legitimate need or desire to use screen reading technology, as VoiceOver has confirmed, so custom tailoring an ‘experience’ targeted to screen readers is sadly an effort not worth pursuing – you will continue to miss as often as you hit. (It kind of reminds me of web sites that will force an alternative version of their site targeted and optimized to mobile devices, and provide no means of getting to the actual desktop version of the site, even if the user wants that).

What I tell developers is this: code to standards, think about graceful degradation as well as progressive enhancement, and remember the original three legged stool approach to web development: the separation of content, design and scripting. I remind them that people with disabilities have a social reasonability to keep their software relatively up-to-date as well (no more or less so than any other user – who supports Netscape 4 today?) and/but as a designer/developer you must always be considering the “PlanB” for user interaction – if “Plan A” fails, what is “Plan B”?

Photo by Dirk Ginader

Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8

The Mozilla Developer Network web site has a ton of documentation. A lot of it is really good. However, we have a significant number of articles that could use some help from the experts. To that end, we’re introducing Wiki Wednesday. Each Wednesday, we’ll post a very short list of articles that need technical help. The list will be posted here on the Hacks blog, as well as to the relevant Mozilla developer mailing lists.

There are three key things you can do to help:

1. Technical review. Read the article, and make sure it’s factually accurate and makes sense.
2. Fill in the blanks. Make sure the article is complete; we have lots of articles that are missing key details, or are simply frameworks. This is particularly common with documentation about older technologies, where the source code isn’t well commented.
3. Add examples. Many topics need examples or code snippets to show how they work. Make sure that we have examples where they’d be useful, and that existing examples are correct.

If you have a few minutes to spare, and can look over an article or two covering a topic you’re familiar with, you can help make our documentation better. You can either edit the wiki directly, or you can send your notes by email to mdnwiki@mozilla.org.

Even if you can’t do all the work needed on a given article, that’s still a valuable contribution! In exchange for your help, you’ll get recognition in the following week’s Wiki Wednesday announcement.

The first Wiki Wednesday article lists will be posted tomorrow (February 9). We hope to see your contributions!

A few weeks ago Portsmouth in England hosted the first Heart and Sole conference. This new conference had quite some appeal to me because of its nature: it was organised by local people who want to boost the web development market, it had rather unknown speakers who show a lot of great stuff online (and I wanted to see how they perform in front of an audience) and it was incredible affordable for the price of a sandwich lunch in London.

Seeing that the audience consisted almost exclusively of students and small agencies I thought I write a talk about HTML5 explaining that is not only a plaything of large companies and “web development rockstars” but that everybody can be part of the cause and that we really need people’s input and real life implementations to make the new open tech revolution a reality.

Here are the video recording and slides of my talk. You can also find the detailed notes of the slides here.

Video

You can see “Multimedia on the web” on any HTML5 enabled device here (courtesy of vid.ly) or embedded here:

Slides

The slides are available on Slideshare:

More videos of Heart and Sole

You can see the other videos of Heart and Sole on Vimeo including a great Introduction to Canvas by Rob Hawkes, musings on Designing WordPress by John O’Nolan and Making Ajax userfriendly with the History API by Syd Lawrence.

There will be another Heart and Sole, so keep your eyes open.

After the huge success of our most recent documentation sprint for MDN, it seems too long to wait for the next planned sprint in June.

So we’re squeezing an extra sprint into the schedule, on the weekend of April 1st and 2nd. Mark your calendars:

Specific starting and ending times will be determined soon, probably at this week’s MDN community meeting (10:00am Pacific (18:00 UTC), March 2nd, in #devmo on irc.mozilla.org).

This doc sprint is not an April Fools joke! Please keep spoof contributions to a minimum (unless they’re really good).

We’re still planning to hold a doc sprint on June 6th to 8th, following the Open Help Conference in Cincinnati, Ohio. This sprint will include an in-person gathering for those who can travel to Cincinnati.

By the way, today (February 28th) is the last day to save US$20 off the registration fee for the Open Help Conference. Register now if you’re interested in open source or community-based documentation and support. Note that attending the conference is not required for participating in the doc sprint, and vice versa.

More details about both sprints are forthcoming. Stay tuned.