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.
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.
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.
input field of
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.
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 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.
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.
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.
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.
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.
- Juicy Studio: Making Ajax work with screen readers
- Juicy Studio: Improving Ajax applications for JAWS users