For me, this whole journey started over a year ago when I first started seeing some HTML5 examples in the wild. At the South by Southwest Interactive (SXSWi) conference in Austin earlier this year it became apparent to me that most everyone else in the web design/development industry started getting excited as well—it was everywhere! At every turn I heard people repeating the same sort of thing: “Hey, did you see that cool HTML5 demo in that last session?!” So I decided it was time to start building some demos and see what was possible.In an effort to stick my toes in the shallow end of the pool, I started developing some small bits and pieces on some of my freelance projects. I think the first HTML5 thing I implemented—other than the dramatically simplified doctype—was the <video> element, complete with extensive fallback for browsers that didn’t support it. On this latest project, I decided to go all out. It became a game for me to find all the cool new toys I could use to construct my new invention—while at the same time maintaining the integrity of the content in multiple browsers/platforms. It may not look exactly the same in every browser, but the content is consistently usable, highly accessible, and search-engine friendly. For Internet Explorer 6 and below, I decided to use Andy Clarke’s method called Universal Internet Explorer 6 CSS in order to avoid wasted time and effort that, in my opinion, just leads to heartache. Andy’s beautifully elegant solution delivers “just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.” I think it’s a great solution to a much-debated issue. Your results may vary. Discuss amongst yourselves. Rinse and repeat.I used a bunch of HTML5′s new structural elements like <header>, <footer>, <nav>, <aside> and others. So far so good (with some coaxing for Internet Explorer… surprise, surprise). I decided not to use the new HTML5 outline algorithm until a later date (it’s optional anyway). I added some ARIA roles for accessibility help. Then I explored some CSS3 features such as rounded corners, drop shadows for boxes as well as text, and transparency. And finally, I threw in some web fonts for good measure (on headings mostly). I’d like to come back at some point and explore web fonts in more detail, but again, that’s a post for another day.

So, enough tech talk. Let’s see the results already! Take a look at the newly re-designed Baatz Consulting site and let me know what you think. If you’re a tech geek like me, please peek under the hood and have a look at the source code. More importantly, if you’ve been having fun with HTML5 (and CSS3, web fonts, etc.), send me a link and we can compare notes about what we’re all learning together.

Simple Interactions

I think the first point that needs to be made is that Ajax, by definition, requires the use of JavaScript. Even if you’re not making a call back to the server using the XMLHttpRequest object, JavaScript is a key component in many websites today using an increasing number of animated browser effects. That’s not a bad thing by itself. But what if JavaScript is disabled or not available? For instance, some mobile devices have limited, if any, JavaScript support. Some screen readers have better JavaScript support than others. Search engines are unable to follow JavaScript constructed links, so search engine optimization strategies could be hindered. For all of these cases, developers need to provide an alternate means of reaching the website’s content. However, creating two different versions of the same content can be a maintenance nightmare as well as an expensive development option. What if there was a better way? Let’s take a look at some alternatives that might offer some assistance to web developers.

Creating New Scripting Habits

Before we get into the more complex Ajax examples, let’s start with the simpler methods, such as JavaScript enhanced links. In a book called Bulletproof Ajax, Jeremy Keith presents a new method which I find very useful. He calls it hijax and it is built on the idea that you can “hijack” regular links, through the use of DOM scripting, to add an unobtrusive behavior layer to your web pages. Without this layer, the links still work as expected, but if JavaScript is available, the user gets an enhanced experience. Jeremy encourages us to avoid bad habits of the past where we used scripting methods that caused accessibility issues. Here are two methods in particular to avoid:Using the JavaScript pseudo-protocol:

1

<a href="javascript:window.open('help.html')">contextual help</a>

Using a fake link:

1

<a href="#" onclick="window.open('help.html'); return false;">contextual help</a>

A better method uses a real link with some added scripting. If JavaScript is unavailable, the link still works:

1

<a href="help.html" onclick="window.open(this.getAttribute('href')); return false;">contextual help</a>

But, we still have some inline JavaScript and that’s not always the best way to go. Here’s where things get exciting. How about creating a normal link and add a CSS class that can be “hijacked” by a simple JavaScript function?Here’s the HTML code:

1

<a href="help.html" class="help">contextual help</a>

…and here’s the JavaScript function to go along with it:

1

function doPopups() {if (document.getElementsByTagName) {var links = document.getElementsByTagName("a");for (var i=0; i < links.length; i++) {if (links[i].className.match("help")) {links[i].onclick = function() {window.open(this.getAttribute("href"));return false;};}}}}

See how that works? The doPopups function creates an array of all the links on the page and then adds an onclick event (the popup window) for any links that have a class of help. This is a very simplified example of Jeremy’s hijax concept. There are additional recommendations for dealing with data retrieved via the XMLHttpRequest object which are more appropriate for true Ajax development methods. I encourage you to check out his excellent books, Bulletproof Ajax and DOM Scripting for additional details.

More Complex Interactions

When it comes to more complex Ajax methods, the subject of accessibility becomes even more important. Some Ajax techniques dynamically add new content to the page in a way that might not be obvious to the casual observer (or completely hidden in the background and therefore invisible to the user). This situation becomes critical for screen reader users since they may not get any sort of notification when the page has been updated and therefore the screen reader may not read the information. Imagine how frustrating it would be to fill out a form and receive no feedback about potential errors. You click the submit button and it just returns you to the form. In order for dynamic page updates to be accessible, there needs to be a way of effectively notifying the user so that they can read the new content.

Accessible Rich Internet Applications (WAI-ARIA)

There’s so much more that can be done to make Ajax (and other complex scripted interactions) more accessible. The Web Accessibility Initiative is currently developing a specification called Accessible Rich Internet Applications (WAI-ARIA) that enables web developers to create web applications in a more accessible way.

Keyboard Navigation

Being able to navigate a website using the keyboard alone (without the aid of a mouse) is an essential requirement for basic accessibility. By default, only links and form elements can receive focus (make it available for user interaction). Try it out for yourself and you’ll see what I mean. Start at the top of a web page and press the Tab key several times to “focus” links and form elements as you go down the page. However, a dynamically displayed error message, for example, wouldn’t be focusable for keyboard-only and screen reader users. Therefore it would likely be missed altogether. WAI-ARIA helps alleviate this problem by enabling all visible elements to be focusable by extending the tabindex attribute in HTML.

Roles, States, and Properties

WAI-ARIA provides the role attribute to help define widgets (sliders, tree menus, etc.) and page structure (sections, navigation, etc.). See the full list of roles available. Additional information about how a user can interact with a widget can be provided with WAI-ARIA’s states and properties. See the full list of states and properties available.

Live Regions

Areas of a web page that will change dynamically using Ajax can be specified as live regions. Live regions provide a mechanism for notifying the assistive device (such as a screen reader) that new or updated content is available on the page and how the user should be notified about the content. The WAI-ARIA specification provides additional information on live regions.

Additional WAI-ARIA Resources

I’ve included only a few of the many features available with WAI-ARIA. Here are some additional references available for further reading.

• Accessible Rich Internet Applications (WAI-ARIA) 1.0
• WAI-ARIA Best Practices
• WAI-ARIA FAQ
• WebAIM’s Accessibility of Rich Internet Applications
• Opera’s Introduction to WAI ARIA
• CodeTalks’ ARIA Quick Reference

• Edit in Place
• Sortable Table
• Modal Window
• Content Slider
• Photo Gallery
• jQuery UI
• jQuery Tools

• standards-based presentation (XHTML, CSS)
• dynamic display and interaction (Document Object Model)
• data interchange and manipulation (XML, XSLT)
• asynchronous data retrieval (XMLHttpRequest, also called XHR)
• JavaScript to bring everything together

It’s the fourth item, asynchronous data retrieval, that makes it truly unique and exciting. Here’s an easier way to think about it: “grabbing data from the server and displaying it on the web page without refreshing the browser.” It’s a more seamless approach to present content to the viewer since everything else in the browser window stays put while a small area updates per the viewer’s mouse click or key press. You may have experienced this before without knowing that it used Ajax. Some popular websites that include extensive use of Ajax include Google Maps, Flickr, and Gmail.Using the less strict definition — not including the hidden round trip to the server — you may have seen things like accordion navigation, sortable tables, fading yellow highlights, and photo galleries. They don’t necessarily use Ajax, but I’m including them here since they’re so prevalent in web development today. I think you know what I mean… that ubiquitous “Web 2.0″ look and feel on many social networking sites (including the glossy, lickable buttons and child-friendly rounded corners).I think that’s enough introduction on Ajax for now. In the next post we’ll take a closer look at some individual Ajax elements and how they can be used to enhance a website.