Weblogs: Web Accessibility

WSG London JavaScript Evening, May 2007

Monday, May 21, 2007

Wednesday 16th May 2007 saw another WSG London event organised by Stuart Colville. This time the subject was JavaScript, with a healthy dose of accessibility. Steve Faulkner talked about demystifying screen readers, and Christian Heilmann spoke about the reasons for code bloat.

There wasn't much raw JavaScript code to be seen, but both talks were packed with content, and both speakers well worth listening to.

Steve Faulkner

Steve is the Technical Director of the Paciello Group, and the Director of the Web Accessibility Tools Consortium. He's part of a very fruitful partnership with Gez Lemon in forging a deeper understanding of how to make JavaScript powered web applications accessible to people using screen readers. Steve provides the screen reader testing as well as the technical understanding of how screen readers actually work.

Steve makes it pretty clear that accessibility is not just about screen readers, its about all disabled people whether they are using assistive technologies, like screen readers or screen magnifiers, or not.

Although there are a plethora of screen readers, when it comes to the web, only two really stand out: JAWS and Window Eyes. In the UK, HAL by Dolphin is the third screen reader to reach such prominence. A conversation with a member of the National Federation of the Blind estimates that Jaws makes up 65% of the market, and Windows Eyes takes the other 35%. This is not scientific or completely accurate, but I guess its not far from wrong.

The main problem with making JavaScript driven applications accessible is the virtual buffer. Screen readers take a "copy" of a webpage, and they then provide access to that copy to the screen reader user. Steve draws a line between screen readers: JAWS versions 7.1 and above, and versions of JAWS prior to 7.1 (including all versions of Windows Eyes).

The virtual buffer is used when the screen reader is in Browse mode, but not when the screen reader is in Forms mode. In Forms mode, only activatable elements like input fields are available (does this include links?). Forms mode doesn't use a buffer, and reads directly from the browser, that means any JavaScript application that only uses form elements will be accessible to a screen reader.

In the pre JAWS 7.1, the virtual buffer only updated when the user activates something - pressing Enter or the Spacebar. Any updates to the page between keypresses are not available in the virtual buffer until the user activates a link or a form control. This means, as I understand, that any JavaScript entry that is driven by user interaction can be accessible to a screen reader.

There is a limitation of dynamic updates with user interaction. If the dynamic update doesn't happen within a short time after a user has clicked a link or changed a form element, there is a risk the virtual buffer update won't have picked up the change in content. The limit is about 1000 milliseconds. This is a risk to Ajax-based applications.

In JAWS 7.1 and above, the range of events that cause the virtual buffer to update is a lot wider. The virtual buffer will update when JavaScript changes the DOM (e.g. by an appendChild, or changing the innerHTML property - if you must!). (So this solves the Ajax delayed updating problem to some extent)

Steve and Gez discovered that if an input field updates, JAWS before 7.1 updates the virtual buffer. This opens up a clever hack for making dynamic screen updates appear in the virtual buffer without user interaction - by simulating user interaction by updating an input field.

Using a input field of type="hidden", a piece of JavaScript that updates the value of this field will force the virtual buffer to update, and thus make the newly appeared content available to the screen reader user in the virtual buffer. This simple technique means that an Ajax request can do its work in the time required, and when its completed updating the document, finally change the value of the hidden input field, and those changes will be available in the virtual buffer.

One barrier to consider is if a user is currently reading through a block of content that's going to change - we need to consider the usability of the application at this point and ensure that the screen reader user is not confused by our updates.

Unfortunately, JAWS was being a royal pain in the demonstration examples, which prevented Steve from showing us how JAWS deals with the situations above. But its clear that Steve has done extensive work in this area, and his findings and conclusions are sound enough. Its just a pity JAWS wasn't behaving itself.

Steve's talk solidified my understanding of his work with Gez Lemon over the last eighteen months. Together they are leading the field of accessibility into making Ajax applications accessible. Ajax isn't going to disappear (perhaps it may be usurped by technologies rapidly catching up in accessibility - like Flash), so we need an accessible solution that reliably works, and Steve and Gez' work in this area is a good bet for future success.

Christian Heilmann

Chris talked about the seven reasons for Code Bloat. He talks about how code bloat is the biggest problem in web development today, which leads to slower loading times and maintenance nightmares. Working at the coal-face on web development project its getting critical to delivering long-term benefit.

We, as web developers, are expected to pick up existing code and know right away how it works, what it does, and how it needs to change to add in the new features. We fail to allow sufficient time for getting a feel for the code and how it all fits together. The end result is we have to over-engineer solutions, leading to extra markup, extra JavaScript (sometimes duplicated functionality), and overusing CSS selectors to ensure what we do won't have an impact on existing parts of the site that seem to still work. Sometimes, with a deadline looming we resort to inline styles and !important to get things working - the deadline is accepted as being more important than the long term maintenance of the site.

Firebug is the web developer's saviour. With it we can identify immediately what styles apply to a particular element in the document, which style properties are being overridden. The JavaScript debugger is unobtrusively brilliant. Thank you Joe Hewitt. This addresses the concerns of how styles apply to the document, so give us a better feel as to the minimum changes we need to make to deliver said list of features.

We, as web developers, are also bad at documentation. Javadoc style comments aren't documentation. We fail to find the time or resources to adequately produce documentation for users and technical documentation for developers. So we end up with systems that can only be maintained by the original developers.

Chris suggests that developers aren't the right people to write documentation. Instead, we should sit down with a technical writer and explain how our application is built - explain it well enough so the technical writer can write the documentation that another developer will find useful. Chris suggests a Cookbook approach of how to get tasks done - this is a great idea, since it focuses on tasks, not technical minutiae. He also suggests avoiding the Hello World type examples, and focus on real world scenarios.

We make things more difficult for ourselves by not reading before diving in. Even in the face of very binary indicators like the toilet in-use indicator, we fail to observe, thus causing some embarrassing moments in what's supposedly a private space.

Chris presents a number of instances where his original code was butchered by third parties - particularly demonstrating that the third party did not understand how the code was written (unobtrusively). Even though writing the code to be unobtrusive was a requirement, the third party clearly failed to comprehend the technique.

The mathematical conclusion is that people are morons. Our nature is to solve problems ourselves, so we fail to take advantage of solutions generated by others. Ikea is a fantastic example of this failure. We know we won't follow the instructions for assembling their furniture, so its made deliberately obtuse, and with almost all IKEA furniture, you never get the right set of parts for the appliance - there's always extra pieces left over, or not enough. As Chris explains, it turns furniture assembling from a chore into an adventure.

And so we are into Heilmann's law of documentation: Your document is only as good as its worst recipient, and its conclusion that the worst recipient is that ends up contacting you, and will be the only person who will tell others how bad your product is.

The lack of awareness is another reason for code bloat. We see many examples of JavaScript functionality that relies on multiple JavaScript libraries, so one page contains references to JQuery, Dojo, YUI, Prototype etc. Particularly for YUI, we find people using the fully commented versions of the code rather than the minified versions. I've also seen an application using the YUI Event, DOM, Connection and Animation libraries, while also using the YUI Utilities - which is an amalgamation of the individual YUI Components.

We fall for the trap that JavaScript is seen as a given, so we fail to consider what happens to the user experience when JavaScript is not available. This is something that should always have an associated test case. It will help us avoid the situation where content is present on the page (but styled not to be visible) and that's only used when JavaScript is available. This sort of content, if it requires JavaScript before it can be accessed, should be loaded in using Ajax when needed.

We see many examples from online tutorials teaching CSS - bad examples of overused class names. It seems like we forget the Cascading feature of CSS. Chris suggests starting with a simple reset style, and styling a set of common elements (like headers, paragraphs and list items). Only when different styling requirements are needed for elements in certain positions should extra styles be used. For the rest of the page, it should just inherit what's been set at a higher level.

Another reason for code bloat is the failure to specialise. In the rush to add more features, we fail to consider whether the additional bloat is worth it, particularly with optional features. We end up with a large piece of code where most of it isn't used in one particular implementation. Chris' suggestion is that we build a simple component that provides the basic functionality (so keeping the code small), and using extensions and modules to add different effects, so the code only contains the features being used, and thus kept as small as possible.

JavaScript libraries present a similar problem. The main reason for a library is to make the browser behaviour less random. It does this by hiding the browser differences inside the library, and presenting the developer with a simple consistent API. Unfortunately all libraries (except for Dean Edwards') succumbs to feature bloat, and with it a level of complexity that makes the bulk of the library indigestible.

The other source of code bloat is the delivery process. The web front-end is still tweakable, and since the backend is frozen, its easy to parachute anyone that knows how to use vi or emacs into adding a font tag here, a center tag there. Its a problem of perception, that web development is so easy anyone can pick it up and run with it.

One of Chris' ideas to cure this is to generally obfusticate the code from the wannabe developer, by minifying the JavaScript and CSS, as well as the liberal use of build like HTML comments to ward off the non-web developer. At least to the stage they understand the implications of their deeds, in which case, they'll see through the little charade.

Questions and Answers

The Q&A session went very well, no doubt as a result of an accessibility focused audience. I started off with a question on whether pursuing a "Graded Browser Support" approach to Screen readers would have any traction. When using recommendations like the User Agent Accessibility Guidelines, we can use this Graded Screen Reader Support to guide screen readers into adopting features that are beneficial to their users, and take advantage of structured and semantic markup. The idea seems to go down well, albeit with the criticism that screen readers are expensive (is this really a web developer problem?)

Another excellent tid-bit (from Niqui Merret) was that Microsoft offer a developer tool called inspect32 which allows the developer to see all the information that the MSAA makes available to applications. This got me thinking about how difficult would it be to build a screen reader using MSAA alone.

The audience was great, a number of well known accessibility people there, people from various organisations, charities and businesses, all seriously interested in understanding accessible JavaScript. Also a good turnout from the Flash crowd. This is one podcast that will be well worth listening to when it becomes available.

Alastair Campbell, from Nomensa, was there, and I finally got to meet and talk with him. We've been corresponding via email for about two years now, so its great to meet him face-to-face. Also great to catch up with Henny Swan from the RNIB's Web Access Centre. Birmingham-based Bruce Lawson came along, so did Aral and Niqui from Brighton. With Alastair Campbell coming in from Bristol, and Karl Dawson coming in from Ipswitch, so people from various far-flung places outside of London. For an event with very short notice, it turned out to be a very high-quality evening.

Congrats Stuart, on another excellent WSG event. Its been my favourite one so far.

Related links

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]