Our users must be able to interact with our websites, whether they are
visually impaired, hearing impaired, on older browsers, on slow connections,
or on mobile devices. HTML5 introduces some new elements,
such as audio, video, and canvas. Audio and video have always had
accessibility issues, but the canvas element presents new challenges.
The canvas element lets us create vector images within the HTML document
also causes problems for the 5 percent of web users who have disabled
There are a few roadblocks that continue to impede the widespread adoption of HTML5 and CSS3. Some are obvious, and some are less so.
y/ Joe Asks…
^ But I Like My XHTML Self-Closing Tags. Can I Still Use Them?
You sure can! Many developers fell In love with XHTML because of the stricter requirements on markup. XHTML documents forced quoted attributes, made you self-close content tags, required that you use lowercase attribute names, and brought well-formed markup onto the World Wide Web. Moving to HTML5 doesn’t mean you have to change your ways. HTML5 documents will be valid If you use the HTML5-style syntax or the XHTML syntax, but you need to understand the Implications of using self-closing tags.
Most web servers serve HTML pages with the text/html MIME type because of Internet Explorer’s Inability to properly handle the application/xml+xhtml MIME type associated with XHTML pages. Because of this, rowsers tend to strip off self-closing tags because self-closing tags were not considered valid HTML before HTML5. For example, if you had a self-closing script tag above a div like this:
the browser would remove the self-closing forward slash, and then the renderer would think that the h2 was within the script tag, which never closes! This is why you see script tags coded with an explicit closing tag, even though a self-closing tag is valid XHTML markup.
So, be aware of possible issues like this if you do use selfclosing tags In your HTML5 documents, because they will be served with the text/html MIME type. You can learn more about this Issue and others at http://www.webdevout.net/articles/beware-of-xhtml#myths.
Cake and Frosting
I like cake. I like pie better, but cake Is pretty good stuff. I prefer
cake with frosting on It.
When you’re developing web applications, you have to keep
stuff Is the frosting on the cake. Your website can be really good
without that stuff, and just like a cake, you need a foundation
on which to put your frosting.
I’ve met some people who don’t like frosting. They scrape It
off the cake. I’ve also met people who use web applications
Bake these people a really awesome cake. Then add frosting.
Internet Explorer currently has the largest user base, and versions 8 and below have very weak HTML5 and CSS3 support. IE 9 improves thissituation, but it’s not widely used yet. That doesn’t mean we can’t use HTML5 and CSS3 in our sites anyway. We can make our sites work in Internet Explorer, but they don’t have to work the same as the versions we develop for Chrome and Firefox. We’ll just provide fallback solutions Asoc wcee sdsoibni’lti tayn ger users and lose customers.
We need to be mindful of accessibility when we push ahead with new technologies and provide suitable fallbacks for these HTML5 elements, just like we would for people using Internet Explorer.
HTML5 has introduced a lot of new elements, but the specification also deprecates quite a few common elements that you might find in your web pages.4 You’ll want to remove those moving forward.
First, several presentational elements are gone. If you find these in your code, get rid of them! Replace them with semantically correct elements and use CSS to make them look nice.
Some of those tags are pretty obscure, but you will find a lot of pages out there maintained with visual editors such as Dreamweaver that still contain a lot of font and center tags.
Aside from the presentational elements, support for frames has been removed. Frames have always been popular in enterprise web applications such as PeopleSoft, Microsoft Outlook Web Access, and even custom-built portals. Despite the widespread use, frames caused so many usability and accessibility issues that they just had to go. That means these elements are gone:
• acronym gets replaced by abbr.
• applet gets replaced by object.
• dir gets replaced by ul.
In addition to deprecated elements, there are many attributes that are no longer valid. These include presentational attributes such as the following:
• link, vlink, alink, and text attributes on the body tag
• height and width
• scrolling on the ¡frame element
• hspace and vspace
• cellpadding, cellspacing, and border on table
If you use target on your links, like this:
<a href=”http://www.google.com” target=”_b1ank”>
The profile attribute on the head tag is no longer supported either, and this is something you tend to see in a lot of WordPress templates.
Finally, the longdesc attribute for img and ¡frame elements is gone, which is a bit of a disappointment to accessibility advocates, because longdesc was an accepted way of providing additional descriptive information to users of screen readers.
If you plan on using HTML5 with your existing sites, you’ll want to look for these elements and remove them or replace them with more semantic ones. Be sure to validate your pages with the W3C Validator service,5 because this will help you locate deprecated tags and attributes.
Competing Corporate Interests
Internet Explorer is not the only browser slowing adoption of HTML5 and CSS3. Google, Apple, and the Mozilla Foundation have their own agendas as well, and they’re battling it out for supremacy. They’re arguing over video and audio codec support, and they’re including their opinions in their browser releases. For example, Safari will play MP3 audio with the audio element, but ogg files won’t work. Firefox, however, supports ogg files instead of mp3 files.
Eventually these differences will be resolved. In the meantime, we can make smart choices about what we support either by limiting what we implement to the browsers used by our target audiences or by implementing things multiple times, once for each browser until the standards are finalized. It’s not as painful as it sounds.
HTML5 and CSS3 Are Still Works in Progress
They’re not final specifications, and that means anything in those specifications could change. While Firefox, Chrome, and Safari have strong HTML5 support, if the specification changes, the browsers will change with it, and this could lead to some deprecated, broken websites. During the course of writing this book, CSS3 box shadows have been removed and re-added to the specification, and the Web Sockets protocol has been modified, breaking client-server communications entirely.
If you follow the progress of HTML5 and CSS3 and stay up-to-date with what’s happening, you’ll be fine. A good portion of the things we’ll be discussing in this book are going to work for a long time.
But before you think too much about the future, let’s start working with HTML5. There are a bunch of new structural tags waiting to meet you over in the next chapter. So, let’s not keep them waiting, shall we?