Ajax Kung Fu Meets Accessibility Feng Shui

• Download my slides from this presentation.
• Listen to the audio recording of this presentation.

Derek Featherstone: Hello, welcome to the intimate and interactive Ajax Kung Fu Meets Accessibility Feng Shui. I didn’t realize the lights were going to be this low but I think I’ll keep my voice like this for the whole time.

Yeah. Good morning everybody! A lot of empty seats, must have been a big party night last night. Everybody here reasonable? Or are you still hung over? Do we need to get some water passed out to the audience? We going to be all right? One thing to note, if you’ve been following the South by Southwest calendar, we are Ajax Kung Fu meets accessibility Feng Shui, but I do need to point out that I do not work for Prawn Song Records.

This actually happened to me when I checked in, they gave me my badge, and they said “You’re Derek Featherstone?” “Yes, this is me.” “But there’s this other picture on your profile, did you want to replace that?” I guess because it didn’t look like me—I thought it was from a previous year. So I get my badge and it’s Derek Featherstone of Prawn Song Records who is here apparently as a panelist for the music festival. This has never ever happened to me before, I didn’t know what to do but I really want to meet the guy so if anybody goes to the music part and they find him, please tell him to come find me or hold him down so I can come and find him or something. This is definitely not me, Prawn Song Studios. Definitely not.

We’re going to keep things really quick short and brief today. I know Jeremy and I both talked about this beforehand and we very much enjoy the interactive setting and we encourage and want a lot of Q and A. So we’re going to try and keep ourselves to 15 minutes each, maybe 20 minutes, and then really open it up, open the floor because I know this happened we did a refresh thing on Friday night and there was a lot of really good questions that came out of the audience and I would hope that there are some good questions here too so we’re going to try and keep it brief and with that I’m going to turn it over to Jeremy for his Ajax Kung Fu.

Jeremy Keith: All right, thank you very much, Derek, and thank you all for coming. So yeah, I’ll do the Kung Fu and Derek will do the Feng Shui, so I’m doing the sexy stuff because Kung Fu is cool. And of course I’m completely pandering to the crowd by having screenshots of The Matrix. I mean it’s a geek audience, right? I can’t go wrong.

So, Ajax Kung Fu. We’re going to be talking about accessibility and Ajax and in a way I’m going to be talking about accessibility now, but it’s a certain kind of accessibility.

There are two ways of looking at accessibility: accessibility where it’s directed at the people and the particular devices those people use, so, making sites accessible for screen readers and people who use screen readers. The other way of looking at accessibility is this idea of universality where you’re not doing it for any particular device, you’re trying to reach as many devices as possible and as many people as possible, usually by following standards. And this is what I want to look at, the idea of universality.

We’ve clarified that universality does not mean that everyone gets the same experience—that everyone, no matter what their device or browser goes to a Web site or Web application and they all have the same experience. That’s not the idea. I don’t think that really follows the spirit of the Web anyway. I’m talking more about a site that can adapt to the needs of the people who use any particular device.

So universality is the goal, and achieving that goal is generally pretty easy when you follow the principle of progressive enhancement. Is everybody here familiar with the principle of progressive enhancement?

Great, excellent. The term itself was actually coined here at South by Southwest a couple years ago by Steve Champeon and Nick Finck at a panel here. It’s normally applied to CSS more than anything but for me it defines my workflow for everything. Really, progressive enhancement is at the heart of everything I do.

I’ll quickly run through how progressive enhancement works. The idea is pretty simple. You begin with your content. Content is king, it’s a cliché but its true. You begin with your content you decide how to structure it. I’m thinking of semantic structure here. You’re deciding, “What does this mean? What is the best element to describe this particular bit of text? What is the best element to describe that bit of text? Is this a heading? Is this a paragraph”? All of that kind of stuff. Remember, at this stage you’re not even thinking about how this should look or how should this behave. You’re purely thinking about what does this mean.

So you begin with your content, then you add your structure. And only then do you add your presentation. You start to think, “Okay, I want this to look a certain way” so I start applying my styles. So CSS at this stage. How should it look? And then is the time to start thinking about behavior. How should this work? The idea is that, because you’ve applied these layers one on top of the other, if you were to strip any of those layers away that would be Okay, because you still would be able to get your content no matter what. The content is always there regardless of presentation, regardless of behavior.

So that is the theory of progressive enhancement, and in practice we have technologies for each step of that process. So when we come to structure our content we have HTML. That is what it’s for, semantically marking up your content. And then for the presentation we have CSS. And for behavior we have, on the Web, JavaScript is pretty much the only option. JavaScript plus the Document Object Model and, of late, Ajax. Ajax is a way of adding behavior to your site.

Here’s the problem—a lot of the Ajax applications out there are built like this: the Ajax comes first. Before you even get to content, people are thinking about how this should behave. It’s the interaction coming before the actual content. I see this as a problem because now immediately Ajax is a requirement to get to any of those other layers. We can’t even get to the content unless we have Ajax, so you’re pretty much throwing out the idea of progressive enhancement and saying “To go any further, you must have Ajax”.

I don’t think this works too well. I better define what I mean by Ajax because it is a term that’s getting a bit muddied. Ajax isn’t those flashy effects and the yellow fades and things moving about, Ajax specifically is about communication with the server. It’s the asynchronous part of Ajax that really makes it cool, frankly the fact that you can update part of the page with information from the server without refreshing the whole page.

That’s not a very sexy definition I know, but I think it’s the most accurate. So it’s nothing to do with moving things around, it’s nothing to do with fading things in and out, it really is that communication with the server and the fact that you can retrieve information from the server without refreshing the whole page. I just want to get out of the way what I mean by Ajax.

So the traditional Web, the Web that we all love, the Web that’s been around since Tim Berners-Lee invented it is a pretty typical model of the thin client. Now the thin client on the Web, what we have is our browser and our server. On the server is where we’re storing our data, where we’re storing our information because that’s what servers are good at. Also, that’s where we’re processing information and processing data. So the business logic of our applications, the business logic of our websites. This is where all of the smart stuff gets done generally is on the server in some server-side programming language—PHP, JAVA, Perl, whatever. The browser is simply there to display the information, the data, the content, to the user. This is the traditional Web. This is the classic example of the thin client—all of the hard work going on in the server; the browser is just displaying it.

Now you throw Ajax into the mix and you get the rich client, or what looks like a rich client. So Ajax, I kind of imagine it sitting between the browser and the server. It doesn’t really, it’s a browser technology, it’s a JavaScript object really, XMLHttpRequest. This is the way I like to visualize it: you’ve got the browser, the server, and sitting between it you’ve got Ajax.

So Ajax can take that information from the server, pass it along to the browser, and update part of the document currently loaded into the browser. With this model you still have the server storing the information, and you still have the browser displaying the information. And here’s the danger when Ajax enters the mix; it’s really tempting to get the browser doing the processing, the browser starts doing all of the heavy lifting.

This is how you end up with the problem of Ajax being a requirement for a site, because now you are saying you can’t even use this site unless you have Ajax, because Ajax, JavaScript, all this clever browser programming and stuff, is what is required to do any kind of processing—a rich client essentially.

The client now, the browser, is more powerful than the server. I don’t think that’s where the strength of Ajax lies at all. I have what I hope is a solution for this problem and I call it ‘Hijax’, because if I have learned anything from Jesse James Garrett, it’s that having a snappy little buzzword will get you everywhere in life. So this is my contribution to the buzzword cloud; Hijax. Hijax, yes, Hijax! So Hijax is a pretty simple idea, you don’t have to use the word, it is a silly word but it is more the idea that I want to get across.

Let me explain what Hijax is. Hijax is simply progressive enhancement but applied to Ajax. So you begin with your content, you begin with your structure, then you’ve done your presentation and finally you add Ajax. It really is as simple as that. It sounds pretty simple. There are challenges thrown up by this but the great thing about Hijax is what it results in is what I like to call the deceptively rich client.

So you’ve got your browser, you’ve got your server, this is the traditional model of interaction on the Web. In the browser you’ve got links, maybe with query strings that contain information, and you’ve got forms that the user fills in. So this is how information gets sent to the server generally. Clicking on a link, filling in a form. It’s been that way for as long as the Web has existed. That’s pretty much the way that we send information to the server.

So we click on a link or we fill in a form and that information gets sent to the server. Now, the server sends back a whole page to the browser, that’s the way the Web works. Though generally, it’s not like, on the server there are full pages of HTML sitting there waiting to get served up. Usually what you have is a more modular approach.

So you have scripts on the server that are in charge of putting together the header, the nav, the shopping cart or whatever and they all get put together, baked into one page on the server and then served up as a page. I think that is pretty much the way that most websites are built these days, there is some kind of processing going on, that stuff is put together on the fly rather than sitting there ready-made, waiting to go.

Now we introduce Ajax into the mix. So again, the browser has got links, the browser has got forms. We click on the links, we fill in the forms. Now instead of that information going all the way back to the server, this time what we do is we intercept those links, we intercept those forms. It’s almost as if we hijacked them. Eh? See what I did there? So we intercept those links, intercept those forms, take that information and say, Okay, don’t send it all the way back to the server, instead just send it to the Ajax object; to XMLHttpRequest, which, like I said, I like to think as sitting halfway between the browser and the server.

So we send it along to the Ajax object sitting there right in the middle. It then passes it along to the server. Now the server takes that information from the XMLHttpRequest object, and in this case, instead of baking together a whole page of the header, the nav, the footer and all that stuff—no, no, no, this time actually because we are only updating part of the page, just give me that one little bit. I just need search results or I just need to update a shopping cart with some parts of the page and then that gets sent back to the browser and you get parts of the page updating.

So I like to call this the deceptively rich client. The reason is we’re still using the server for storing, obviously, but we’re still using it for processing and the browser is still just displaying the information: but to the user now, it appears to be processing. It appears to be doing lots of powerful interactions because we’re just updating parts of the page. Actually the browser isn’t doing anything clever at all. All the heavy lifting, all the business logic is still happening on the server but to the user, they can’t tell. It looks like, “Wow! This is a really rich interface, everything is happening in my browser.” Hence the deceptively rich client.

So if you think about it, in this case I am using Ajax, the XMLHttpRequest object, as a dumb waiter. All it’s doing is passing information backwards and forwards. The browser gives it the order, it sends it to the server, comes back, it’s not doing anything clever at all, and I think that’s the way to do it. It is almost like Unix pipes, doing just one thing really well rather than trying to get it to do too much clever stuff.

So if you do this, if you have the deceptively rich client and then if you were to take Ajax out of the equation, that would be okay, because the links and the forms would still work in the old-fashioned way. Because you built it with progressive enhancement, you could strip away that Ajax layer and you will be able to degrade gracefully to the original application that uses old-fashioned, un-sexy links and forms.

Now, there is a little bit of a paradox in what I am saying here because, on the one hand I am saying, yeah, to build an Ajax application, you start by building a regular old-fashioned Web page. You just start by having links and forms—you don’t even think about Ajax. On the other hand, that server-side architecture is kind of vital. You do need to have this modular approach on the server side where things are baked together rather than having whole pages sitting ready to go.

So I think this paradox can be resolved by following these two simple rules. One is that you plan for Ajax from the start. When you are thinking about the server side architecture, have it in mind that it should be as modular as possible, just in case you might want to use Ajax in the future.

So you plan for Ajax from the start, but you don’t implement Ajax until the end. That is the crucial part and as long as you follow those rules, I think the paradox sort of resolves and you get the best of both worlds.

Things to watch out for. Theoretically, so you should be thinking purely semantically to begin with, then you could think about presentation, and finally about behavior. If you find yourself doing things like this, you need to catch yourself. If you find yourself saying, a href="javascript:, right, the javascript: pseudo-protocol, beware, because clearly, if you’re thinking semantically out of the Web page, and you have an href value that has the javascript: pseudo-protocol, then you are not really thinking semantically, you are thinking about behavior at that stage.

Also I just hate the javascript: pseudo-protocol. What’s a pseudo-protocol anyway? Protocol’s a thing like HTTP, FTP, they send information over the network. You can’t send information over the network with JavaScript, sorry. So if you catch yourself doing this, watch out, you are jumping the gun, you are thinking about behavior too early. Also if you find yourself doing this, and this is something you see a lot if you have view source in Ajax applications: a href equals octothorpe, and then you start having event handlers right there in the markup. This won’t degrade, you are not really applying progressive enhancement, so watch out for this kind of thing.

So here is the pattern I want you to think about. As I said, think about Ajax from the start but don’t implement it until the very end.

You are on a page or your user’s on a page, and there is a link and they click that link. Now exactly the same page comes back where only part of it has changed. Or alternatively, here is the other pattern. You are on a page, there is a form, you fill in that form and exactly the same page comes back and only part of it has changed.

So some examples would be when you are rating things. Things like Amazon, those star ratings, really small, discrete parts of the page. You could have a really, really, really long page with ten products on it and you’ve got those five stars and you can click one to five. Now you click those stars, if the whole page was to come back and the only thing that changed was to say, “Yup, okay, four stars, got it”, that’s really frustrating. That’s the perfect opportunity to use Hijax or to use Ajax because you just want to update that really discrete part of the page.

So ratings, you know I think it is really, really, really good use of Ajax. I know when most people think about Ajax, they are thinking about Google Maps, they are thinking about GMail, these big, big sexy applications, but for me it’s the small stuff. It’s the small stuff that ease the path, that makes things just that bit more usable that really, really add value to your sites. So ratings, that’s a good place to do it.

Registering—okay, particular bugbear. You’re on a site; there’s a little form, choose a username, choose a password, click submit. Off it goes to the server. The whole page comes back, just to give you the same page, and say, “sorry that username is already taken”. And if it’s Yahoo or Hotmail, then you repeat this a couple of thousand times.

So that’s a good place to do it. I saw this happen with the whole Flickr and Yahoo merging-of-identities thing a while back. Paul in my office didn’t have a Yahoo account, so he had to try and choose one. He was there for a long time, inputting usernames. At one stage he mashed his keyboard randomly, and it still came back and said “sorry, that username is already taken”. So that would be a really good opportunity to just update that one part of the page so that the pattern really holds true.

Comments—we’re getting to bigger areas of the page now, but I think it still works in this situation. Think about a blog post. You’ve got the header, the navigation, probably a sidebar, the blog post itself, all the previous comments and then a form where you fill in your comment. Now you fill in that form, you click submit. And what do you get back? The whole page. The header, the sidebar, the navigation, the same blog post, all those comments again. And the only thing that’s changed is that your comment has been added to the page. So there I think that the pattern still holds true, and that would be a good place to use Ajax and update just that one part of the page.

Shopping carts—I’m really surprised that Ajax hasn’t been used more in e-commerce applications. Because you’d think you’ve got 10 products on a page, and you click that “add to cart” button, whether it’s a link or a form, probably should be a form, it brings back the whole page. The only thing that’s changed is over in the sidebar is your shopping cart, and you’ve added that one product to the shopping cart. That pattern holds true. You’re clicking a link, you’re filling in a form. You are getting back the exact same page. Just one discrete area of that page has changed.

So it’s a very simple pattern, but you will see it over and over again once you start to look for it. You develop a smell for this. You start to sniff out these patterns, “Oh, this might be a good place to use Ajax”. So you stick with this, and what you end up with what Dan Cederholm coined his term bulletproof to describe sort of, catering for those edge case scenarios, by making sure that you got really solid approach.

It’s basically because of progressive enhancement, because you can strip away those layers, because you can deal with the 5-10% who don’t have the typical browser, who don’t have the typical platform you are expecting. It’s also coincidentally the name of the new book I’ve just written, Bulletproof Ajax, and we do have copies of that book and we will be giving them away to the people who ask the best questions. But for now, you know Kung-Fu! So well done, and let’s hear from Derek, who’s got the really hard job.

[applause]

Derek: I don’t think I have the hard job, actually. I’ve think I’ve got it easy because Jeremy’s just laid a really great foundation for a lot of the things that I want to talk about.

The stance that I want to take on accessibility is a little bit different than what Jeremy was talking about. He was talking about accessibility as being universality or that at least being one component of it. I believe in that, and I think that’s an important goal, but I’m also very much rooted in the practical nature of Web development. I have a lot of clients where they don’t have the money or the time to do both. To make something that is a Hijax-type applications where you have it work in the old-fashioned model, and you have it working with Ajax as well.

In a lot those cases, my goal is really to focus on accessibility as a part of user-experience for people with disabilities and ensuring that the application is built in such a way that it does have compatibility with screen-readers. And it does work with voice-recognition software, and screen-magnification software. And that it’s as easy to use as possible for people with cognitive disabilities. When I look at this whole accessibility, dare I say, “camp one versus camp two”, I think that it’s really just, you know like we should all just be camping together in the first place, and let’s just balance this out.

Because a lot of what we do is a bit of a balancing act. That’s why I like the idea of accessibility as being about a bit of Feng Shui. Because Feng Shui is all about harmony and balance and finding ways of creating environments where things can peacefully coexists. Did anybody write that down?

[laughter]

That’s kind of the stance that I take on it, and what I’m hoping to share with you a little bit here today. I thought of this because we used Feng Shui in the title of the session so I better work some of that in here. So I’ve worked some of that in here.

Feng Shui literally translated means “Wind and Water”. It was actually interesting reading it because they talk about wind as being full of energy and being very transformative. And they talk about water as being something that actually stores energy and is quite stable. I thought that’s an interesting way to approach what we’re doing here. We want to have a lot of energy and a lot of vitality and interactiveness in our applications, but we also want to have that core stability that gives everybody what they need.

Wind and water to me was this utopia, this peace-and-harmony type metaphor. And then I really thought that we can extend that. We’ve seen this in a lot of places. Wind and water can really be quite destructive. It has a lot of destructive power in it. When you look at some of these storms that are out there in nature, that just absolutely obliterate places. That’s the feeling I get with a lot of Ajax applications now. Take those same core elements, wind and water, and they can actually be used in such a way that is quite destructive.

So let’s look at not being destructive. Briefly talk about Ajax and scripting and accessibility, and how this all fits together and how it ties together with what Jeremy just said.

So in 1999, accessible scripting meant that your site works both with and without JavaScript. Basically what that meant was, we used JavaScript in such a way that we’d have a noscript tag that will provide some other alternate functionality. That was one of the original ways of making your site work with scripting on and off. Over time that progressed so that we got smart and we did other things where we ensured that if JavaScript was off, our links still worked. When we were generating drop-down menus we didn’t generate the whole menu with JavaScript, we just generated the second level fly-out menus. And we had the top level of the menus still just function as a regular old link.

These were some of the things that we did in trying to ensure that we were scripting in an accessible way. That for the most part comes from WCAG 1.0, Web Content Accessibility Guidelines. The landscape in 1999 was such that this is what we were told. Ensure that your pages work with scripting on or off. And that was going to deal with a lot of different scenarios. Screen readers at the time didn’t really support JavaScript. They were much simpler than they are now.

So what we started to see, and I first started really noticing this in 2004 and 2005, was that accessible scripting actually meant something completely different. Here’s one of the examples why. This is a quick screenshot from a site that we built—not our design—that we built in 2005. It uses some simple drop-down menus, JavaScript based drop-down menus. You mouse over the link, or in this case it even worked with the keyboard. When that top level link receives focus, the second level menu shows.

We started doing some testing. This was using an old Dreamweaver script, the way Dreamweaver generates it’s drop-down menus. You know, pretty typical types of things that you’d see in a lot of government shops where people are using Dreamweaver, and a lot of people still use it. This was partly a menu that was generated from that.

And then I took some other menus, like Brothercake’s ultimate drop-down menu, which is really heavily scripted but really deals well with progressive enhancement and graceful degradation and fallbacks and it uses a strategy where we have a link as the top level menu and when the page loads an onclick is dynamically attached to that link so that the onclick behavior will display the next level of the menu or however it’s working.

We started doing some testing with screen readers on this and in this particular case, when the screen reader got to the ‘about’ link, that was going to display the second level menu, it actually told the screen reader user, ‘onclick’. So there is an audio cue that an onclick was available. In the other examples that we were looking at, the onclick was not announced, and I started trying to do experiments and figure out why, so what it turns out happens is that the screen readers at this time is a JAWS 5 and 5.5 and Window Eyes maybe version 4. What they did is, they were looking for inline hard-coded onclicks that were put in there by the Dreamweaver code and so what was happening was when we created this dynamic menu that attached the onclick and it was not listed inline, it was actually added after the fact, the screen readers were not recognizing that.

I thought “this is ridiculous!” because we are trying to do the right thing, we are trying to code in the right way and use progressive enhancement and yet the screen readers aren’t understanding that. We are doing the right thing and they are not. So I didn’t really like that and this is when all these red flags started going up in my head, that this just can’t be right. The other side of this is that the onclick behavior that’s exposed to a screen reader user, it goes, something like this: onclick is announced and there the screen reader user is expected to know instead of hitting ‘enter’ that they are supposed to hit ‘control enter’ and that activates the onclick.

Then the screen reader tells them the page changed at line 54, at which point the screen reader user hits the ‘J’ key for ‘jump’ and they enter the line 54 and then they hit ‘enter’, which then kind of takes the focus to the spot on the page where the page changed. So clearly, everybody that uses a screen reader knows how to do this and it has been a very, very successful behavior.

This is one of my very first real frustrating moments with the screen reader was trying to get past this, why is it not understanding the onclick. So then in 2006, Jeremy started talking about Hijax, I thought fantastic, this is great. But one of the things—and Jeremy and I talk about this all the time, Hijax—and I am going to show you an example here of an actual, real—Hijax is not just this theoretical concept, it is actually happening in the wild. And a little while ago I looked at a site from Canada, chapters.ca, it’s our online book store, similar to Amazon but still doesn’t even have nearly the market share I think that amazon.ca has but these guys are kind of getting it. This is a new enhanced version of their site, I thought it was really cool. They are actually—when you get to a product page when you are looking at an actual book, they are doing all kinds of things that are kind of progressive in terms of conceptually anyway.

They are allowing people to tag their products, they are trying to help people find things after the fact, they are really jumping on board with that, which I think is great. So I saw what they were doing here, they have got this little link that says, ‘what is this?’ which I think is great because when you are introducing something new, a new feature, you need to help people understand what it is.

So they use this Hijax approach, where when you click on the link and you have JavaScript on, it goes and does some fancy magic with Ajax and brings this content back and puts it in the page. So it is like a little bit of helper content. So I thought okay, well what happens if JavaScript is off and I totally didn’t expect this: with JavaScript off, it just goes and loads another page that tells people what is Ajax. I thought brilliant, great.

Now, let’s look at this though because why did they use Ajax for this in the first place? This is if you take a look at the screenshot here, we’ve the ‘what is this’ link. There is this extra little bit of content that really we probably didn’t even need to use Ajax for in the first place. I am glad that they hijacked it, and I am glad that they used that approach. But can we do something more simple that is going to make this work? And here is one of the issues. If we pop up some new content on a page, what happens to a screen reader user that doesn’t actually know that anything is popped up on the page? We used to use pop up, little tiny pop up windows for this, right?

How many people have done a pop up window before? Don’t be afraid, put your hands up. Almost at least 50% of people in here have done that. Well, here is the thing with the pop up window—and it is almost blasphemy to say this but what if the fact that a pop up window, little tiny pop up window that only contains this new little bit of content and not the whole wrapper page like everything else that goes around it, it is only containing the relevant content, what if that little tiny pop up window is actually more accessible than this strategy because the screen reader here doesn’t get the update, they don’t know what is happening, they didn’t know where to go next, they have had this thing magically appear and no new window was announced, because that is not a window. That is something that we’ve done with JavaScript and CSS, so what if that is actually the case? Are we actually making things worse?

This is one of the things that we have to start—we really have to start asking this question, are we making it worse by doing this because it is doing something that is so different from the conventional Web? So how do we get around that? And in this case I think I wouldn’t even use Ajax for this, they may have their own reasons why, but this is helper content.

It is extra content that is related to one specific area of the page and what I would do in this particular case is all that ‘what is this’, the extra helper content, I would just embed that in the page maybe somewhere down at the bottom, it can be in a help section for that page, but what I would do is when that page loads, I would hide it, use the CSS to hide it and then use the CSS and the JavaScript to bring it back at this stage.

So then of course the critical component to this is this ‘what is this’ link. If that extra helper content is already in the page, what should the href be for that ‘what is this’? Take it to a named anchor in the page or to some fragment identifier, to an ID. A much simpler strategy that doesn’t use Ajax, that just already has that helper content there in that page, so that is kind of a critical component and the nice thing is with using a real href, maybe instead of totally hijacking that link, we should actually just let it go, because if we hop to a named anchor in the page, we can potentially go right there with the screen reader and that will continue reading from that spot.

Andy?

Andy Budd: [inaudable because he didn’t wait for the mic]

Derek: But they have chosen to do that though, that is the thing, it is helper content, so they have chosen to do that… yes, yes, potentially… and here is another solution to that. The question was, “doesn’t that taking them to another part of the page, potentially disorient them and take them away from what their actual goal is?” And part of my response to that is yes, it is potentially possible but they have chosen to do that. So one of the ways around that is to take that close link and style it appropriately so that it is at the end of the helper content and when you click the close link, where should they go? Back to where they were.

So there are ways around it and that may not be the perfect solution. It may not be the perfect solution but at its core, that is fundamentally what we are doing and that kind of builds on what Jeremy’s talking about in terms of hijacking links and forms. Let’s use the default behaviors that exist to our advantage, rather than doing onclicks and adding in all these onclicks and things that don’t actually work as real links. Let’s create linear pathways through the page if we can, if such a linear pathway exists.

So what we’re really talking about, and this has always been the case, we’ve talked about HTML being our core of content and CSS being our core for presentation and JavaScript being our behavior. But there are core behaviors that are built into HTML that we need to utilize and allow those things to do some of the hard work for us—things like named anchors within pages—creating a linear path through the page, if we can.

This is an example that I’ve shown before, and I’ll just explain it very quickly. This is based on testing as well; it’s not just pure theoretical work. One of the things that we always see in scripting, and in any Web development, is we have to deal with error messages, in particular, with forms—things like your user name.

So, in this particular case, I’ve got a form field with an advisory type message saying, “The username must not contain spaces.” That’s there as information beforehand to help the user understand what they are required to fill in or what some of the parameters are for that field.

One of the ways that this would be coded a long time ago would be to put this in three table cells. And even if you have “username” as a label, if you had your label and then your table cell that had your text box, and then another table cell beside that that has your “must contain only spaces,” a screen reader user may never get to that. Because it’s not actually part of the form; it’s just this extra advisory text.

So what we start to do is find creative ways of making this information, like, “must not contain spaces”, well, that “must not contain spaces” is actually information about the field, so it should be part of the label that is associated with that field. So what we come up with is code structures like, as part of the label for our username field, we include something that’s potentially emphasized, and emphasized because we’re actually emphasizing that particular phrase about that field. That make sense?

We just use some fancy CSS to push that “must not contain spaces” over to the side. The nice thing is we can now use that structure and change it so that when we have an error occur—and I’m not a visual designer, but I still think that this is reasonably okay—instead of using the emphasis tag or an em element to specify the advisory information, we’re now in an error situation. Let’s put that error into a strong tag, because now that it’s an error, we want to strongly emphasize that. Make sense?

Here’s the really, really cool thing. And this is what gives me goosebumps. In testing this, if we used this strategy, because the text is part of the label, even though, visually, it doesn’t look like it’s part of the label, a screen reader gets that update. There’s been a lot of talk about screen readers—and I say it, too—not being compatible with JavaScript. But this is really exciting, because screen readers do get this. If we use JavaScript or Ajax, or whatever it is, to update the contents of a label, that is exposed quite well to a screen reader.

There are some caveats. One of the problems with this is that, in order for it to get the updated label, you have to leave that field and go back to it. Which is a bit of a problem, but that’s one that we can solve. And we won’t go into all the details, but we can do things like change the status bar in the browser. People know what a status bar is, so, for an application, that’s one of the first keystrokes that they know is what to do to check the status.

We can change the title of the page to say that an error occurred in such and such a place. We can change the legend text that goes in the fieldset that this is part of. There’s a lot of different things that we can do.

One of the experiments that we’ve done with this is to add a label to the submit button that tells them that there is a problem somewhere in the form and that they can go back and review it. It’s not perfect. We haven’t gone to the point where we’ve done this for every possible combination, permutation, but this kind of thing does work.

I’m going to skip over that, because it’s frustrating. Okay, no, we’ll do it. We’ll do it. This is a screen reader demo of using JavaScript to update part of a page, in a way that I thought would never work.

[computer sound effects]

Derek: This isn’t supposed to work, right? This is one of the things that I…

Computerized Voice: Title is “Populate table with inner HTML, dash, Microsoft Internet Explorer.” Heading level four: available meetings. Heading level four: available meetings. Heading level four: available meetings. Wrapping to top. Heading level four: available meetings.

Derek: That’s just me goofing around.

Computerized Voice: Wrapping to top. Populate meetings button. Space, populate meetings button. Link. Heading level four: available meetings, April 11th, 2006. Link. Table with four columns and five rows. Link. Visited link graphic plus. 8:00 dash 9:30, graphic audio…

Derek: I’m going to go past that, because it just basically goes through and reads it all. This was using a method that was not supposed to work. So now you know why I got frustrated with it.

One of the things that is happening in scripting right now, in heavily scripted applications that are using Ajax, or just scripting and screen readers, is that we don’t have enough test cases. And so, one of the things that we’re working on is trying to figure out, “Well, this wasn’t supposed to work. Why did it?” So there is a lot of work that needs to be done.

I don’t want to paint a really rosy picture and say that we can do anything we want to. But at the same time, there are some test cases that we need to sort through first to understand why it is that that worked. Maybe it worked because it was, dare I say, in a table. Maybe something about the fact that it was a table has some effect on the way that the screen readers are processing it.

We don’t have a whole lot of time left. I want to go through a couple of quick things, and then we’re going to go to questions for everybody. I guess one of the main points that we looked at, with that Hijax example, is the idea of, “Where next?” If you have an application, a complicated application, if you click on some button or some link to activate something and you’re using Ajax or scripting to populate another part of the page, if it makes sense, we should take people there.

And so, this is where we start using things like href equals [speaks with British accent] “octothorpe”…

[laughter]

We start using structures like this to take people to the next spot in the page that makes sense. And sometimes we need to use a tabindex of minus one. I won’t get into the details of that, but we can programmatically focus on things that have a tabindex of minus one, even if they’re not normally focusable. So we do have a means to lead people around the page. This can actually work.

Another possibility is using semantic functional state. And what I mean by that is using the disabled and read-only properties of a form field to your advantage when you’re scripting. These things are completely scriptable. So we had this application where we wanted people to be able to go through and edit a lot of things in the page, and what we did was we started scripting to disable form fields so that they didn’t appear in the tab flow.

Disabled form fields are not focusable when you’re using the keyboard, so that reduces a lot of the auditory noise that would come from going to all these things that aren’t even editable or activatable. Same thing with the read-only. So, starting to use some of these things in your scripting, because they have meaning, and they’re there for us to use.

I like to call that sort of semantic interaction, right? We’re not just talking about semantics in terms of headings and paragraphs and list items and block quotes. We want to talk about semantic interaction—things that actually make sense and are used for the right reason.

I’m going to skip over emulation, because we could spend a whole day on that. But basically what it means is that the future of a lot of this stuff and compatibility with screen readers is going to an emulation type thing where we say: “This component of the page or these components of the page are related to a specific form-field. So, that the screen reader can actually understand that, that message that you just put on the screen is something to do with that particular form field.

Or this big block of…this div up here that’s collecting all the errors is actually something to do with errors. And that when it pops up in the page, we might give that a role of alert. So, we might say that this should function the same way as an alert in that it tells the screen reader user that something has just happened up there and it draws attention to it.

Right now a lot of what we’re doing is kind of making things up as we go. This is one of the things that W3C and IBM and Mozilla are working on to have scripting actually talk directly to screen readers through the accessibility API. That’s really hardcore geeky stuff that I don’t even understand all of it yet. That sounded like I might understand at all at some point but it’s quite possible that I won’t. It’s really hardcore geeky stuff that we’re definitely not going to get into.

One of the things that I guess I want to leave you with is that it’s always an option to choose not to use Ajax. If there’s a simpler solution available, great. If not, maybe Ajax is fine and maybe what we need to do is start considering that an alternative might be quite reasonable or allowing to set a preference that says and I wouldn’t word it this way: “You can turn Ajax off” but we might do something that we enable a preference that says: “Enable page refreshes.” So, that is easier and compatible to use and the Hijax approach really allows us to do that.

My last slide is: I heard that Jeremy and Andy had a saying in their panel, How to Bluff Your Way in Web 2.0, and it was that Accessibility Just Ain’t eXciting. But I believe that accessibility is just as sexy as anything else going.

[audience laughing and clapping]

So, speaking of sexy, I think we’ve got about 10 or 12 minutes, I think. So, there’s microphones for questions and we’ll be happy to answer.

Man: My question is regarding Drupal or other similar type tools where you can download packages and add modules and that sort of thing and how that sort of fits in to the progressive enhancement way of building sites because it seems like there could be a tendency to focus on the structure and presentation before you even start putting any content up in there. And so, maybe just talk a little bit about that with respect to progressive enhancement as well as how you can incorporate the Hijax method you’re talking about.

Jeremy: Yes. So, this kind goes to the idea that I was talking about—of building things in a modular way on the server so that you can then later make the decision to perhaps use Ajax to update parts of the page after you’ve already got the pages working fine without Ajax. The CMS you use is obviously a going to be a big factor in that server-side programming language you use and how modular that is. I think it’s going to change on a case by case basis and it’s probably something you should have in mind when you’re deciding what CMS to use.

If your CMS doesn’t allow you to do this thing, get a new CMS. And yeah, it’s the decisions…it’s something to bear in mind way, way, way, way back in the decision making process of deciding what to use or whether to use a CMS or whether to hand roll it.

Derek: And one thing on that, I know that there are some people that are working on Druple stuff where it’s kind a standards compliant theming mechanism for it. So, I know that some of the stuff is possible but I don’t know…I haven’t implemented Druple anywhere but it’s definitely something to consider at the beginning whether you can get themes that support Web standards in how to approach or not. And how, you know, do have the ability to do anything with the scripting that’s done on the page or is it all hard coded in the head or off in external files. So, there are theming, I know that people are working on theming for it.

Glenda. Oh no.

Glenda Sims: No, I’m not going to ask them to remove that slide. I think it’s sexy.

[laughter in background]

So, I’m inspired and hopeful about rich Internet applications being accessible. But South by Southwest only scrapes the surface. So, if I wanted to mind-meld with you for hours, what opportunities I might have?

Derek: Wow.

[Glenda and other audience laughing]

Derek: Yeah. Intimate and interactive.

Glenda: Shall we?

[audience laughing]

Derek: You know what, you’re probably best to go off to the Knowability booth in the trade show because there is…this is so cheesy I can’t believe I’m doing this. [laughs]

[laughter in audience]

Glenda, you totally set us up.

Glenda: I totally did.

Derek: The Knowability booth, there’s a conference called Access U in May, that’s here in Austin. A two-day conference. I’m also doing a (shameless plug)…doing a full day workshop the day before that is all about what goes in…like it’s a full of some of the stuff that I did in 15 minutes up here. So, there are other opportunities, always. Especially for you, Glenda. [making a cat sound]

[audience laughing]

Woman: Well, I kind of have the same question in that as I work to build my business and I’m working hand in hand with my engineers, how do I make sure that they’re as up to date as I want them to be, fluent as you two maybe on all of this cutting edge work?

Jeremy: Well, things are changing in the JavaScript world generally. Things are getting more savvy. A few years ago it was really hard to find good JavaScript resources. Everything was old and it was old-school style scripting, nobody was thinking about this stuff.

In the last few years, it’s incredible. I mean, just the fact that with people like Derek and with people like James Edwards and Christian Heilmann, where the skills are JavaScript and accessibility and there’s a Venn diagram of JavaScript and accessibility coming together. Now, just a few years ago, those two circles would have been miles apart. The mere idea that the people who do JavaScript were even thinking about accessibility is crazy.

So, I’m actually pretty hopeful that there are good resources out there now. There certainly weren’t and a lot of people have sort of frozen perceptions of JavaScript and they’ve written it off as being inaccessible and all the resources are rubbish and all this kind of stuff. That perception was true in ‘99-2000 and it’s changing now. The problem is that Google never forgets, right? So, you Google something and you get an outdated resource that’s just inaccurate or…

Woman: Right. Would you say that your book is one of those resources? [laughs]

[audience laughing]

Jeremy: Yeah, Okay.

[audience laughing]

Derek: I would say his book is one of those resources and this one is great too but the DOM Scripting book that Jeremy wrote before this is fantastic for that as well especially for beginners.

Woman: Right, for beginners and I asked because I want to have a certain awareness in order to speak with my engineers and to know that I’m kind of believing that or that I have a general awareness so that, I don’t know, I can work with them as best as I can. So, is your book accessible for someone like me?

Jeremy: Yeah. It’s a dummy’s guide sort of. It’s pretty basic.

Derek: Ah…he didn’t mean that.

Jeremy: No. No offense. That was pretty…sorry.

Derek: That was mean.

[audience laughing]

Woman: All right.

Jeremy: You know, it is specifically aimed not on programmers because there’s lots and lots of books aimed for programmers coming from…especially now that Ajax is big and sexy… you got people from the server-side world using Java and other proper programming languages and now having to learn JavaScript, there’s plenty of resources out there for them but I’m aiming for people from the other end who are more designers, more front-end people or…

Woman: Right.

Jeremy: Or project managers, or whatever, who need to have some understanding and get a good head around this without all the jargon and all this stuff. So, yes. So, I’ll give you your payment in the corridor later for setting that up.

[audience laughing]

Jeremy: That’s great.

Woman: [inaudible]

Jeremy: Stop now stop.

[audience laughing]

Man: I have a question about the “What’s this” link that you guys were talking about with the pop-up.

Derek: Yeah.

Man: The solution that you described about using the anchor, that using the Hijax approach would hijack the link click and make it appear, but now for an accessibility for a screen readerer that might have JavaScript turned on, that would still Hijax that, and would that then be inaccessible to that user?

Derek: That was exactly the point that I was trying to make, so apparently I did not explain it very well. But, ultimately, that it is exactly it. We deal with a situation where ninety-nine times out of a hundred, screen reader users are using a JavaScript-enabled browser and scripting is on. So that is part of what this balancing act is about. Trying to find a way to actually make it so that it is accessible, so that when that Hijax approach does popup and appear, that we actually use JavaScript to our advantage to put the focus in the right spots, so that a screen reader can continue reading from there, and it does makes sense.

Jeremy: The process that’s looking pretty promising is is the tabindex = -1 approach. Gez Lemon has been doing a lot of cool research on that. That is looking promising. It basically comes to down the fact, that screen readers have biases towards things like forms and links because those are focusable, so if we can give things like divs that same sort of bias and expose them, then that will help. It still feels hackish, but all we have got is hacks now because we are we dealing a hacky situation.

Derek: Yes.

Man: Is that there in the other book?

Jeremy: No, I’m not going to plug a book again.

[laughter]

Jeremy: I’m going to plug Gez Lemon. Go to juicystudios.com.

Man: Com?

Jeremy: Yes. He’s done great work.

Derek: I think we have got about three or four minutes left, so we will try and get through all the questions that we have here.

Man: So, there are a lots of great patterns that we as developers, can use to make our Ajax applications more accessible, but where are the screen readers falling short, but what can they do to improve that, and why are they so damned slow?

Jeremy: Great question. Great question.

Derek: Yeah. We are actually working on this right now, with some of them, or trying to, through the Web standards Project, the Accessibility Task Force. We have tried to open the dialogue, and trying to work on that but one of the biggest things as you saw with that one example that I showed, with the actual screen reader clip, is that that wasn’t supposed to work but it did, and so now one of the big things that we are taking up on with the Accessibility Task Force, is trying to write test cases, so that we can see where the shortfalls are.

A lot of the screen reader manufacturers right now are starting to do this, a lot of research into the Rich Internet Applications, to make things work, like the stuff that I was talking about, emulation. Window Eyes has some preliminary support for that. They are working on that with their betas right now, and in some of their live, real stable versions. It is happening, it is slow because they are not cutting edge. And the other thing is that they also have to have backwards compatibility with all of the other crap sites that are out there, that don’t use real modern data approaches to Web development because they were built in 2000 and 2001, and they do not muster, pass muster with our current standards.

Man: Is there one thing that your dream, this one feature, that would be added to screen readers?

Derek: I cannot nail it down to just one. There are too many things.

Jeremy: Essentially, we are facing the innovators dilemma, where, our knowledge has advanced, the browsers have advanced, but the screen readers are further back, and we are having to hack our way around that. The future, it will all be sorted out when we have got jet packs and flying cars, but we have to find solutions that work today with screen readers today, but that is where the frustration comes.

Derek: Yes.

Man: I have a question about, it is more a question for Jeremy, it is about, when you said, it is a better idea to not use the JavaScript suite of protocol in the onclicks. I think a lot of the reason that a lot of people use that is that we do not really know the alternative. What would be a good alternative to doing that?

Jeremy: Well, that you use…, when you come to put an a element into your page, which is an anchor element, the href attribute is hypertext reference. It points to a resource, either in the same page or on the World Wide Web. And if it does not, you are using the wrong element. It should not be a link to begin with.

The only time it would be acceptable to use a javascript: pseudo-protocol, or anything like that, is if you were generating the link with JavaScript to begin with. But if you are thinking, about a behavior at the stage of what is the hypertext reference for this a element in this HTML document, you are thinking about behavior way too early.

So you think “Where is this resource? Where is this pointing? Is it in this page? Is it in another page on the Web?” And that is what you put in there, and later you hijack it, and intercept it. And do your behavior.

Man: How do you intercept it? Do you use an observer pattern?

Jeremy: Oh I see. Definitely an observer pattern sort of thing, where you are watching, waiting for a click to happen. That kind of thing. If you got a lot… I mean I just tend to attach events to the individual links and forms, but obviously that does not really scale too well, what Yahoo for instance do, when you’ve got a really big heavy page, like the home page, they just have something looking at the whole page, waiting for something, just anywhere in the page to be clicked, and then they look, and say “Okay, which part of the page just got clicked?” and then look for the right event to do that. So it depends on the scale of it really.

Man: Thank you.

Derek: Just before we get, I think we are almost running out, but we want to go over to John Slayton who is with us for a quick question in the audience.

John: Thanks. I think my question is actually about the semantics of links and buttons. I am running into a lot of pages lately, and not all of them are Ajax pages, but a lot of them are, an increasing number of them are. Things like Yahoo mail, on the page where you are composing a message, or blogger, on the page where you can post your posts. I am getting increasing confused, because there are things that are links, like changing the restyling chunk of content in the compose window, if I can actually get into the compose window. And there are other things that are buttons, like “Publish”, or no, “Publish” is a link, and “Save” is a button.

Jeremy: Yeah.

John: And because the screen reader basically allows me to jump through the page, according to what element, whether it is a link or a button, and so on. If I am going through links I do not hear the buttons, if I am going through the buttons, I do not hear the links, and I lose the ability to control what I am doing.

And the question is, is that happening because of people not simply thinking about it, or is there some semantic thing going on there, that I have not got my mind around yet?

Jeremy: I would just say that, I think it is because people are not thinking about it.

Derek: Yes.

Jeremy: Again, when you are first coming up with the page and deciding semantically, you are just thinking about structure: “What is this? What it is?”. And there are, not rules, but there are definitely guidelines to decide when to use a form, and when to use links, when something should be GET, and when something should be POST. And these were formulated many, many years ago. This is nothing new. But people don’t tend to think about this stuff any more. And they really should. Loads of problems crop up, because people use links, when they should be using form buttons.

For instance, in 37 Signals’ Basecamp, they had a delete link on the page. Now you should never, never have anything that will update something on the server be a link. What happened was… okay, they think that this is pretty safe, because no search engines are going to spider that delete link, because people have to be logged in. But people were logging in who had the Google toolbar accelerator, that prefetches pages in the background…

And of course, they were prefetching the link to delete. There should have never been a link to delete in the first place. That should have been a form. It should have been a POST request: you were posting the information.

Derek: And just to follow up on that, it does not necessarily need to be, an ugly form button. You can use image based submit buttons, with proper alt text that are quite reasonable to use for forms. And you can even style form buttons now as we are getting browser support for styled buttons. You can style them quite nicely now so they do not have to be ugly. You can make them look good. We want to balance this stuff together, so that we meet everybody’s needs and there is no reason that it could not be an image based submit button.

Jeremy: The button element is the best kept secret in the HTML specification. Go check it out. It is pretty coherent. Years ago, we could not do anything with it but now we can style it to look like anything we want. So the button element is really, really useful.

John: Okay.

Derek: I think we’ve run over all ready.

Jeremy: Okay, Thank you all so much.

[applause]

Derek: Thank you.

Jeremy: Seven thirty tonight at the Lava Lounge: The great British booze-up, come along. We have books for questioners.