Presentations: AbilityNet Rich Media: Notes

Ajax and Accessibility

Mike Davies

Hi there. I'm Mike Davies, I'm a web developer at Yahoo!, and my focus is on web accessibility. Before I joined Yahoo! I was the Lead Technical Developer for Legal & General delivering their accessible website and online services. That project became a case study for PAS 78 on the business benefits of web accessibility.

PAS 78 is a guide to commissioning accessible websites written by the British Standards Institution and the Disability Rights Commission and is written for owners of websites who are looking to external web design agencies to produce a website for them. Its highly recommended reading for anyone interested or needing to know what's needed to build an accessible website. It isn't a document for developers or technical people, although the guide does point to suitable technical references they should be adopting and using. It doesn't cover accessible Flash all that well, but the web standards material is well worth reading.

That was my day job for Legal & General, and it took about four years of evangelism, and about eighteen months of development to complete. And the company recouped that cost within six months because of the dramatically increased number of completed online transactions.

Outside of work hours I write, blog and give talks about web accessibility. I blog at www.isolani.co.uk, and I'm a member of the Web Standards Projects Dom Scripting Task force which is interested in promoting the mature and responsible use of JavaScript, which includes accessibility.

Ajax and Accessibility agenda

Our Agenda today covers Ajax and accessibility. We'll look at Web 2.0 and where Ajax fits into this. We'll look at the accessibility issues Ajax raises, as well as some practical case studies of implementing Ajax-enriched functionality. I'll cover recommended approaches to implementing Ajax, and talk about screen reader testing of Ajax applications. And at the end we'll have a questions and answers session - time permitting.

Ajax and Web 2.0

What is Web 2.0? Its rather a difficult question to answer, its actually not just one thing, but a whole group of characteristics, some related and some not. In the case of Web 2.0, its important to understand what Web 1.0 was and then look at the differences between the two. The version number of 2.0 is an inkling that its an improvement over version 1.0. So what was Web 1.0?

What is Web 1.0?

Web 1.0 is the classical web of the last century. It follows the traditional approach to publishing. Publishers produce websites and visitors (like readers) read the content they provide. You were either a publisher or a reader, it was a clearly enforced divide. Also, mainstream sites had minimal participation or feedback - like a newspaper, contributions from readers were sectioned off into their own part of the paper - like a letters to the editor section.

As a result, sites were largely static. Readers all saw the same content, nothing really change, there was no personalisation, no real contribution from readers. Publishers were the king of the web. Rarely sites adopted discussion forums, but this was the exception rather than the rule.

Characteristics of Web 2.0

Web 2.0 breaks the Publisher/Reader model, it encourages readers to become publishers and contribute content to the web. It can be something as simple as a reader rating a news story, the accumulated number of votes is added value, generated by users, and that value can be used to improve the value of a site as a whole. For instance, what if a newspaper put onto its front page the current stories that received high votes from users? Five years ago, in the Web 1.0 world, that idea was inconceivable, today its the cornerstone of major news sites like Digg, Newsvine and Netscape.

These social media sites user user feedback to gain an edge over online newspapers, and now major chunks of traffic to old fashined news sites are now through these social media aggregators.

Shared experiences are also about users becoming publishers. Sites like Yahoo! Answers allow visitors to ask questions and visitors to answer. They share knowledge freely. and that sharing adds value. Inside of a year, a social knowledge sharing site is Yahoo!'s second largest site. Shared knowledge is also behind Wikipedia - which is based on the concept that every page is editable by the visitors, and they are the publishers.

Essentially, the key characteristic of Web 2.0 is that the Web is not just a publishing medium, its a platform to build social applications and value. Lets look at some examples of Web 2.0 sites or applications

Examples of Web 2.0: Users sharing content

Flickr, YouTube, delicious and Wikipedia. Without visitor contributions these sites are hallow skeletons. The value of these sites are directly related to contributions from users. Flickr, the social photosharing site allows visitors to upload their photographs, and other visitors can comment on them, sharing conversations, making new friends with similar interests, gradually becoming a community. Communities are a valuable asset in a Web 2.0 world.

What's interesting about Flickr is that photographs of world events appear on Flickr before any mainstream media, be they online news sites, television news, or newspapers. For example, coverage of the terrorist attacks on London two years ago - the pictures first used by news services were photographs taken from Flickr. The first coverage of the underground carnage, from eye witnesses recording on their mobile phones, that footage was taken from YouTube.

Social media is about real people broadcasting the news in their own human way. Unfiltered, unedited, raw coverage as it happens. It tells a compelling story that makes it difficult for main stream media to compete against.

Examples of Web 2.0: Users becoming publishers

Blogging is a visitor publishing to the web, in effect, taking the role of the publisher. Blogging works because its slowly being recognised that the audience is every bit as clever or smart as the publishers. I dare say, the audience is smarter, more informed, and more intelligent than mainstream publishing. Visitors benefit in that they can chose only to cover topic that interest them, they are not burdened by mainstream publishings unbiased and general coverage.

Web 2.0 works because it embraces diversity, it allows communities to build around niche topics around subject matter that's seen as too small or insignificant for mainstream media to cover.

Blogging allows visitors to air their thoughts. RSS allows visitors to subscribe to certain content, in effect, tailoring the Web to cover what interests the visitor.

In the Web 2.0 world, it is the visitor that's in control of what they want to read, not the publisher.

Examples of Web 2.0: Social Networking

Social networks, again are an example of visitor generated content. Myspace succeeds because it brings together musicians and their fans. It is a community founded on music. Ning is a platform that allows communities to come together into their own shared network. Again, it encourages niche markets to come together and create value - something mainstream publishers can't do.

Examples of Web 2.0: Interactive applications

An interesting example of Web 2.0 is Google Maps. Its an interactive application, a vast improvement over the Web 1.0 versions of mapping applications which was just a series of images on html pages. Now, for the first time, you could zoom in and out of a map, drag it around, switch into a satellite mode. Even better was tagging two points and getting directions from one to the other.

The interactivity allows visitors to participate, but what makes Google Maps a true Web 2.0 application was its ability to be used in conjunction with third party data. By taking the data or applications from two or more sites and mashing them up together, suddenly we get an application that's unique, and something the two data sources could not do alone. The first mapping hack combined Google Maps with Chicago crime data, and showed graphically which parts of Chicago were best to avoid late at night.

Today with Geotagging and a mashup between Flickr and Google Maps you can find a place on the map, and look at photos taken in the vicinity. That suddenly makes finding your way to places even easier - since you'll recognise the place you're looking for from the pictures.

Google Maps succeeds because it enables its use in other people's applications. Its part of the Web platform of building applications.

Examples of Web 2.0: Web is a platform

Web 2.0 is a platform for building applications. Everyday more and more people are using web versions of applications rather than those on their desktop. I've been using web based email for over five years, its far more convenient than a desktop application installed at home.

Personalised homepages are becoming the norm. Instead of using MSN or Firefox default start pages, more and more people are using personalised homepages as their starting page in browsers. These pages can be configured to display headlines from favourite sites (be they mainstream news sites, or niche topics, or an aggregation of other sites). They allow the visitor to see what's new on the web based on their own interests, not those of a single publisher.

Building blocks of Web 2.0

These Web 2.0 applications are built using HTML, CSS and JavaScript (and a server-side component). AJAX is the real enabler of these applications. It allows seamless communication between the browser and server.

What is Ajax?

Ajax is a JavaScript interface that allows content to be sent or received by the browser without having to refresh the entire page. Gone are the days of clicking on a link, waiting for a page to load, click a link on that page, and wait for the next page to load.

Ajax offers a more interactive experience to visitors, and its that improved interactivity that's made Web 2.0 such a powerful movement. It makes it easier for visitors to engage in communities. Is the defacto transport of user generated content.

Summary of accessibility issues with Ajax

But its Ajax's interactive nature that gives rise to accessibility barriers. Particularly the emphasis on dynamic updates based on mouse movement. There's general issues that need to be considered, as well as issues specific to screen readers, screen magnifiers, keyboard only issues, as well as the more standard but overlooked movement and colour issues.

General accessibility issues with Ajax

The general accessibility issues behind Ajax is that it breaks the fundamental model of the Web. The Web is a simple system of clicking a link and a new page is returned, click another link and a different page is returned. Ajax and Web 2.0 makes the visitor experience a lot friendlier by its interactivity, but that enhancement creates a barrier to accessibility.

What's more Ajax can be used to keep a running commentary, it can interrupt a visitor to convey an important news flash. Those activities are largely user independent, they don't rely on the user initiating a request for an update. And its how that interruption is presented causes accessibility problems. Interruptions are rude, and distracting.

The third general barrier is visual dependencies. Web 2.0 lives and dies by interactivity, and many people use visual cues to make things more understandable and intuitive. A change of cursor may indicate a region of text is editable, but how is that visual cue going to be given when there's no visual layer?

Screen reader issues with Ajax

Screen readers are complicated pieces of software. Modern screen readers use a virtual buffer - a copy of the web page that can be scanned in a number of different ways. In older screen readers, the original HTML page can be updated, but this doesn't update the virtual buffer, so instead of hearing the most up-to-date version of the page, a screen reader is reading the stale copy in its virtual buffer.

This is the first of two big issues for Ajax applications - whether the updated content is available to the user. Solve that problem and we are faced with the second problem - is the user aware that the content has been updated?

Hidden content can trip up a screen reader. The typical approach for dropdown menus for instance is to hide everything but the top level navigation by positioning it off-screen. So where a sighted person sees a simple list of six navigation items, picks one of them and sees a second list of six items - its all fairly simple to navigate. The screen reader user on the other hand gets an indigestable chunk of a 156 links, many with identical link text and no way to determine how the links relate to each other - its hit and hope.

The general rule is never hide content with display none, because screen readers won't read that content out - but in this case, presenting a screen reader with 156 links is still criminal. Here, hiding everything except the top-level with display none is probably the best way - or not having the sub navigation on the page at all is better.

The dynamic update problem

Screen readers are handling user initiated updates decently. So a simple form validation function in JavaScript is fairly accessible.

Updates that are not user controlled are badly supported (unless you are using JAWS 7.1 and newer). The key problem is that a screen reader expects content to change because its been requested by the user, and its rude to change content when a visitor is trying to read it.

The difficulty with Ajax is that the update to content isn't instantaneous. Although it can be user initiated, screen readers expect the change to the document to happen within about a second, so if the Ajax request takes longer, the virtual buffer is probably not going to be updated with the new content.

There are some workarounds to this delayed update problems - notably the hidden input field hack devised by Gez Lemon and Steve Faulkner from the Paciello group. They noticed that in JAWS 7.1 and newer, the virtual buffer is updated if a form element changes. So they produced a hack that updates a hidden field on the page whenever an Ajax update occurs. Updating the hidden field forces the virtual buffer to update, causing the updated content to be available to the screen reader user.

In screen readers other than JAWS, and JAWS versions before version 7.1 things are more difficult, but not impossible. A visitor using these less capable screen readers will need to refresh their virtual buffer manually. It can be done - JAWS I believe uses Insert Escape to refresh its virtual buffer.

Manually updating the virtual buffer isn't the end of the world. But we need to consider what happens after the page has refreshed - how does a screen reader user track down what's changed. Gez Lemon and Steve Faulkner are pursuing the idea of a summary or log, which can be found by an accesskey. That summary would detail what has been updated on the page, and provide a way for the visitor to jump straight to the piece of content that's changed. A bit like a fast forward and rewind buttons on CD or DVD players.

The applications that are more problematic are those where the timeliness of the message are critical to a web applications functionality. An instant messaging client's core feature is that messages are instant, and don't queue up. We need to ask ourselves in this case, is it that important for a screen reader user to be interrupted from their current task when such an event occurs. Perhaps we should be asking our visitor whether to allow those interruptions, or allow our visitor to queue up those messages till he is ready to read through them.

Screen magnifier issues with Ajax

The main issues with accessibility are geared around screen readers. Its only because blind and vision impaired users are the group most affected by accessibility barriers. Accessibility isn't just about screen readers, and Ajax issues aren't just limited to screen readers.

Screen magnifiers offer us another group of issues. Because screen magnifiers magnify, we need to be careful that when a user initiated action, like clicking on a link, leads to an update of content, we need to be sure that there's something in the field of vision that signals that a change has occurred on the page. Otherwise, a screen magnifier user will think that the link they've clicked is just broken.

We also need to spend some time thinking about the implications of automatic updates, and what happens when those updates will change the content a screen magnifier user is currently reading.

Keyboard issues with Ajax

People using just a keyboard presents another set of problems. The typical barrier in Ajax applications here is when content is placed offscreen to hide it from view, very frequently when this content is focused on through tabbing through the document, the content remains offscreen. There's no visual cue for the keyboard user where the focus is, and what's going to happen if they activate the currently focused anchor or element.

The logical approach is to ensure that any content that is focused on is moved back into the visible screen. The second approach is to ensure that content that is offscreen can't be focused on. The first approach of bringing focused content back on screen is perhaps the better method.

Case studies of retrofitting a web page with Ajax

I've got two examples of JavaScript enhanced functionality built with accessibility firmly in mind. One is just a simple search widget, the second is an accessible Ajax-powered map.

I would strongly discourage building an Ajax application on top of any old webpage. For dynamic content updating, its really necessary that the underlying markup is structured, semantic and accessible. No amount of Ajax can improve the accessibility of a badly markedup page.

The second pre-requisite for accessible Ajax applications is to be very mindful of visual cues that are on the page, and making sure that those visual cues are complemented by a textual alternative.

Steve Marshall's Yahoo! UK TV Search widget

The first example comes from Yahoo! UK TV Search.

This is a tabbed search widget. Each type of search is represented as a tab, underneath that is an input field for entering your query, followed by a submit button.

Its a typical modern search box, you'll see this on all major search engines, Google, Yahoo, Ask, Altavista. And every one of them gets it wrong.

What web developers see is a link for each type of search, followed by a standard input field and a search button. So they markup a link for each tab. And then they bodge some JavaScript up to highlight the selected tab. Some more JavaScript then to somehow figure out what type of search is being done, and then they change the form action to call the right search.

It works. It goes into production. Years later someone makes a slight change to the Javascript and causes a JavaScript error. Suddenly the entire search functionality fails completely.

Then, after a day spent in an accessibility 101 course, they try tabbing through the search widget and realise that they can't even do the simplest Web search.

They then realise that this same widget has been live on their website for a few years now, and its always been broken - for keyboard users and for screen reader users. Its at this point the developer throws his hands up, pretends to forget the problem he's found, and hopes that no-one else will notice. He's supported by the fact that no-one has reported the main search is broken, or no-one has passed the message on.

Its a nasty job. But its nasty because it broke the most fundamental rule of web development - core functionality has to work and be accessible without CSS and without JavaScript.

Now in Yahoo! UK, we've probably hired the best web developers in the country. And even though the team has years and years of experience, they do like to think things through from the beginning.

Steve Marshall, the developer behind this search widget took a long look at this widget and realised an astonishing fact. The tabbed search widget is nothing more than a simple form.

The type of search is nothing more than a group of radio buttons. They are just styled to look like tabs. Immediately that solved the problem of the form determining which type of search to use - the radio buttons would pass that through to the server as a name value pair.

In that observation, Steve had solved about 80% of the accessibility problems faced by other search widgets. By marking up the form properly, with a fieldset legend, and explicit labels on all the radio buttons Steve solved the next batch of problems - identifying options and making them keyboard accessible.

In the screenshot above, you'll notice that the labels are slightly longer than the text that appears on the tabs. Here Steve is taking advantage of the screenreader's handling of form labels - it reads out the fieldset text "Search" along with the label for each field. Instead of one word ripostes to every form element, the screen reader has a conversation with its user. Instead of the tab options of "Web", "Pictures", "Video", "Audio", the screen reader presents the more pleasant "Search the Web", "Search for pictures", "Search for video", "Search for audio". By making the form easier on the ear, Steve has improved the readability and understandability of the form.

All that's left is to add a layer of style and some scripting. The basics of structured and semantic HTML are well and truly covered.

The additional text to make the form sound better in a screen reader are actually wrapped in spans and positioned offscreen. That way only the tab shortened versions are visible, but the screen reader can still access the entire label text.

So Steve styles the radio buttons to look like tabs, by hiding the radio buttons themselves and styles the labels to look like tabs.

Keyboard accessibility is handled entirely by the browser, because form labels are focusable, as well as clickable. There's no need to add any links to the page. Labels avoid the need for any gnarly JavaScript.

One piece of JavaScript is needed. When you click on a label, it updates the state of the input element its explicity attached to. That doesn't really help us when we want to style a tab as selected. So a small piece of JavaScript is added to update the class attribute on the selected label, and this is based on which radio button is currently selected. Again we are taking advantage of the strength and accessibility of HTML, and leveraging it to style and add behaviour to the search widget.

The fieldset legend is also not visible on screen. One oddity about styling fieldset legends is that they can't be positioned offscreen, so we hack this with a negative text-indent style, a zero height and width. This collapses the legend into zero pixels while still being available to the screen reader.

Once those bits are all in place our search widget is complete.

We took this widget through a number of tests. We had some unofficial help from the RNIB, as well as testing support from our inhouse screen reader users. The feedback we got back was extremely positive - especially from screen reader users and keyboard users.

Although our search widget looks no different that other tabbed search widgets, underneath is well structured and accessible HTML. If the JavaScript collapses, the whole search functionality still works. Using this widget with a screen reader sounds like using a simple form, the screen reader still announces a group of radio buttons - a metaphor that regular screen reader users are used to. Whether JavaScript is on or off, the Screen reader user gets the same exact and stable experience.

Matthew Somerville's Fix My Street

The second case study is from a site called Fix My Street, developed by Matthew Somervill from My Society. Its an example of an accessible Ajax map.

The key to making an Ajax map accessible is by progressive enhancement. You start with something simple that works, and then you layer it up one step at a time with increased functionality, making sure that you don't compromise the foundations.

Fix my street is a site where you can report problems in your neighbourhood to your local council. Anything from broken streetlamps, to potholes, grafitti, uncollected rubbish and abandoned cars. Essentially the application collects information as to what the problem is and where the problem is.

Fix my street uses an Ajax map that allows you to accurately move around your neighbourhood and mark on the map exactly where the problem is. This interactive approach simplifies the reporting of problems, which is important in getting problems fixed.

So you scroll (by dragging the map, clicking the direction arrows by mouse or keyboard) the map click where the problem is, and then you enter details of what the actual problem is. This information is forwarded to your local council and the issue is tracked until your local council fixes the problem.

When JavaScript is disabled, all Ajax maps basically fail. Except this one. Because Matthew is using progressive enhancement, when JavaScript is stripped away, the Map still works. But this time it works in the Web 1.0 style. Instead of the map scrolling when you click the direction arrows, the current page reloads with the map moved in the direction you had clicked. You can also still select a particular spot on the map because the map is just a clickable clientside image map.

With a keyboard, you can scroll the map by tabbing to the arrow keys on the map, or by using the keyboard's own arrow keys. Of course, marking a particular spot on the map will be very difficult, so for keyboard users, the map can provide the general area where the problem is, and a supplementary textfield is used to describe or narrow down the exact location of the problem.

For screen reader users, the map is of no use, which is why the basic fallback is a simple form where the visitor can fill in exactly where the problem is, along with the details of that problem.

Because the application starts by asking for your postcode, the end result is a high-quality incident report of a problem.

Development Best Practices

In development, progressive enhancement is very important. You need to create solid foundation where the core functionality of the application works in HTML alone. Then you layer in the CSS, adding visual cues - making sure those visual cues are already available in a text-equivalent form in the HTML. Then layering JavaScript and Ajax to enhance the user experience, taking into consideration the issues I covered earlier.

Testing Best Practices

Testing is very important. First your inhouse testing team should test the application from start to finish with CSS and JavaScript disabled. This is important, since it tests that the foundation of your application is solid. If the application works in this state, you have the best chance of the overall Ajax enhanced application can be accessible.

Only when the application is completely working with CSS and JavaScript disabled should testing be done with them enabled. Testers need to identify what visual cues are being used and test whether the same information is available in a text-equivalent way. They need to keep an eye on the use of colour, placement, arrows and GUI metaphors and determine what visual cues they offer.

Another important test is an end-to-end test without the use of a mouse. This test absolutely has to work.

The last test is on a slow connection - just to see what happens when Ajax requests take a few seconds - does the application provide a way of indicating progress?

Testing with a screen reader

Don't let a test team or web developer test with a screen reader. The only people who should ever test with a screen reader are those people who use one day in and day out. Even the best JavaScript developers have outfoxed themselves testing in a screen reader, they end up spending too much time fixing the wrong problem - mainly because they don't know how a screen reader really works.

I suggest a first pass test with an experienced screen reader users - this is good for ascertaining whether the application is accessible. But this result must not be relied on. Experienced screen reader users know screen readers inside out, and know how to battle through some really awkward barriers. One screen reader users I know did his Christmas shopping on Amazon last year - that site is inaccessible, but he battled and battled and found a way through. This isn't common.

You really need a normal screen reader user to test your application - this is more accurate in terms of how accessible your application is. The normal screen reader user is just a regular visitor that browses the web, not one who builds their own sites or consults for businesses wanting to build a site.