boogdesign blog

Niqui started off with some justification. many web developers believe that Flash can never be accessible, and this is not true. Flash has a lot of built in support for accessibility such as access keys, labels and captions, and in addition can be used to detect the presence of a screen reader (if you're using IE on Windows...). It is also a misconception that a block of HTML content is necessarily more accessible than a Flash movie - the phrase 'a picture is worth a thousand words' can be applied here, some disabled users will have far more trouble reading a large block of text than they would assimilating an animation.

No technology is 100% accessible, but the process of making Flash as accessible as possible is the same as with any other technology - identify the barriers stopping people accessing your content and work out how to get around them. Flash has a number of built in mechanisms to help the developer overcome barriers - as previously mentioned it can communicate with screen readers and notify it of content updates, it can be keyboard driven and labels can be added which will be read out. Niqui then showed us a demo of a simple accessible Flash game she'd built, using it with a screen reader and keyboard, and showed us some other useful tricks which were possible - dynamically adjusting/inverting colours and contrast in the movie, and a simple script which allowed the movie to scale as the browser font size was changed. She also had some interesting points about the relationship between Flash and standards - there aren't going to be any standards for accessible Flash content until the 'standards people' accept Flash.

Niqui was enthusiastic about her subject matter and had excellent presentation skills, the talk was a definite eye opener in some respects, but Flash was unfortunately the thing I was least interested in so 4 out of 5.

Anne's talk covered some common pitfalls in building an accessible website, I noted down some highlights:

• Don't assume - not all disabilities are the same, some groups don't even class themselves as disabled even though they have accessibility requirements, so you can't predict how accessible your site will be to all of them. Also don't assume that disabled people won't be interested in what you have to offer.
• Don't ignore - if people complain about the accessibility of your site then that needs to be treated as an opportunity to improve, feedback is valuable.
• Don't forget the background - not everyone browses with a default background colour of white, if your site design depends on having black text on a white background it can look pretty horrible (and be hard to read) if a user is browsing on Windows using the high contrast theme if you don't explicitly set those colours in your stylesheet.
• Don't waffle - cut out unnecessary text like 'click here for', don't duplicate content across alt and title attributes and the link text as it could end up getting read out three times (and don't put crucial content only in the title attribute, as it may end up not getting read at all). Also remember that the popup boxes for alt and title attributes can often obscure important content for screen magnifier users, who need to keep the mouse pointer near to what they're reading. Don't make your pages unnecessarily long as vast swathes of text will fill up the screen reader's buffer and slow everything down.
• Don't be shy - biggest users of skip links are people with motor disabilities, not blind users, so hiding skip links and keeping them only for blind users is counter productive. Don't forget the :focus and :active pseudo classes as these are the ones which will be activated by keyboard only users.
• Don't leave it to chance - put unique information first on the page, don't take the chance that disabled users will leave before getting to the interesting content. Put instructions before the form to which they apply. If you have help info for items on your form then put the links to that help inside the labels otherwise they may be ignored by screen readers in 'forms' mode. Put the labels in the expected places (before inputs and selects, after checkboxes and options) so that users using screen magnifiers will see them. Also remember that, when using legends with fieldsets, many screen readers will read out the legend before the label for each form field - so keep the legend short and sweet (Anne mentioned one example she'd seen which had a 38 word legend!).

The subject matter of this talk was far better aligned with my interests, but Anne was a bit soft spoken which made it difficult to hear at points, and there weren't too many practical examples, so 4 out of 5.

Mike's talk focussed on the business case for accessibility, and mostly related to his work in transforming the Legal and General website. His opening slide was quite impressive, he asked "What if a web agency walked into your office and promised the following things for your website re-design?":

• 40% increase in traffic
• Double the number of successful conversions
• Double the revenue generated by the site
• Get a return on investment for the re-design in five months

Although none of these were the explicit goals of the re-design, but they happened as a result of accessibility improvements.

Mike discussed some of the things which were required to get the whole project pushed through:

• Clear responsibility and vision - the goal of accessibility was driven from the top
• Define a role and career path for 'web Developers', don't let web pages be the thing trainees do before they move on to 'proper' development
• Have a consistent vision for the whole website, educate the content developers to understand accessibility requirements
• Choose a design agency which demonstrates an understanding of accessibility (assess the accessibility of websites in their portfolio, assess the accessibility of their own website, ask them to explain any shortcomings when they come in for an interview) - they chose Fortune Cookie

He also discussed the role of web standards with an anecdote from the early part of the project. One of Legal and General's web applications worked in IE but didn't work at all in Firefox, an attempt at validating the page showed several thousand errors but it turned out the main issue was a missing double quote on a single attribute. The point here is, if the page had been designed to validate from the start then an error like that would have stuck out like a sore thumb instead of being lost in a sea of other validation errors - Mike estimated this particular error cost the company approximately £20000 in lost business. One other thing Mike mentioned which stuck in my mind was that the biggest single asset in producing and accessible website was the imagination of the developer - they need to be able to imagine how differently abled people will interact with the site.

Overall this was probably the best talk of the night, there was a lot of information on the slides over and above what I discuss above including some detailed statistics, but, as the focus was on business issues, there was again a lack of practical examples, 4 out of 5.

This was the final talk of the day and I was flagging a bit, I'd originally planned to go to Scott Guthrie's WPFe talk, but that was packed out and, following Dave's stellar performance in the previous talk I was interested to see what he had to say on a subject I was a bit more familiar with.

The talk started with a little motivation, why would you want to make your javascript unobtrusive? The main benefits, if your sites are built to work with or without javascript, are:

• Accessibility - if no part of your site depends on javascript to provide the content then it will naturally be more accessible
• Mobile Browsing - an increasingly more significant market segment, but most mobile browsers don't handle javascript very well if at all
• SEO - search engine spiders don't pay any attention to javascript and won't see any content generated by it

Aside from the 'big three', Dave also mentioned the Dutch web accessibility law, which mandates unobtrusive javascript (and will possibly be a model for new laws in other countries), and that separating behaviour from content is just good practice, in the same way as seperating design from content with CSS is.

Next Dave showed us an example of 'good' and 'bad' web applications. We saw Google Maps in which all the basic functionality is available even if javascript is turned off in the browser, and Zoho Planner which is impossible to even log in to without javascript. Then we moved on to some common issues:

• no target="_blank" - this assumes your user is browsing in a windowed environment
• no href="#" - this link conveys no useful information if javascript is not enabled
• no onclick="... - this assumes javascript is available, better to make sure the default functionality works and add event handlers with javascript instead

Finally Dave showed us a demonstration of developing a web app using unobtrusive techniques. He showed us the LowPro, an extension of Prototype to make it easier to implement unobtrusive scripting. This is part of the UJS Rails Plugin which extends the Ajax helpers available in Rails to be unobtrusive, making it all very easy. One of the key points from the demo was that because everything needs to work without javascript, anything which a user without javascript is going to need should be in the HTML. If some of those items aren't needed when the page has been Ajaxified (submit buttons on auto-completing search fields for instance) then they can be hidden with javascript, but it is impossible to have javascript add things in when it's disabled.

In conclusion, Dave recommended that we develop our sites so they work without javascript and then add the script in afterwards. He also recommended that, as we were considering adding an Ajax effect to our page, we asked ourselves three questions:

• Do we really need it?
• Will my links still work?
• Does this break the back button?

Another great talk from Dave with much useful advice, 5 out of 5. I must admit to doing a lot of the href="#" stuff in my daily work as a sort of reflex action, it's a habit I should get out of!

After a brief spell writing a Ruby on Rails app last summer I always meant to do more stuff with it, but somehow I never got around to it. I was hoping this talk would re-ignite my enthusiasm and give me some good pointers.

Dave started off with some general background for the benefit of the .Net crowd, positioning C#/VB as comparable with Ruby and ASP.Net as Rails equivalent in the Microsoft world. He then moved on to an overview of Ruby:

• Ruby is Object Oriented - a lot of languages claim to be, but not many are as aggressively object oriented as Ruby, even null is an object
• Ruby is Readable - there were some good examples: 2.weeks.from_now.utc for the date two weeks from today; punctuation for tests as in x.null?; punctuation for destructive and non-destructive methods as in arr.sort compared to arr.sort!
• Ruby is Dynamic - and this is taken full advantage of in Rails, there were some more examples using method_missing and the Linguistics add on, which extends built in objects

Next we moved on to Rails, and after some general discussion of convention over configuration the bulk of the presentation was a live demonstration of building a web application. The eye opening part of this for me was that Dave approached this in a completely different way to how I'd previously done it (in my admittedly limited experience). He started by defining his model and then adding fields using Rake migrations. I'd never paid any attention to Rake before but it looks very useful once you know what to do with it, basically you define your database upgrades and downgrades in Ruby so then it's easy to roll databases backwards and forwards.

The talk finished up with some references to how Microsoft is 'borrowing' some of the ideas in Rails, LINQ being quite similar to ActiveRecord and BLINQ performing similar tasks to the Rails scaffolding.

I really enjoyed this talk, what's not really coming across in my dry description of the talk above is what engaging presenter Dave Verwer really is, if you have a chance to go see him present I can highly recommend it. Overall this was my favourite talk of the day, 5 out of 5.

I got "Don't make me think" for Xmas and so I've become quite interested in the concept of cheap usability testing, I was looking for this talk to give me a fresh perspective on what I'd read.

Zhivko started off with a short introduction on what usability is (ease of use, user efficiency, user satisfaction) and why it's important. Increased user satisfaction leads to:

• Increased sales
• Decreased development costs (more testing means less fire fighting)
• Improved brand image
• Improved user productivity (ie. when using internal applications)

The talk then moved to comparing remote testing (screen sharing over the internet) with 'traditional' testing methods (with usability labs and all the paraphernalia). Remote testing gives you:

• A realistic context of use - you're testing users in a 'real life' environment, where they're more comfortable
• Better geographic representation - with traditional methods it's very expensive to test outside the area where your office is located
• Access to professionals - if you're selling to a certain market, such as software developers, you might not be able to persuade them to travel to your lab
• Lack of non-verbal signals - this is a disadvantage, you don't see the non-verbal cues that indicate users are getting frustrated and so have to depend on what they're telling you

Zhivko discussed some research which demonstrated that, despite being much cheaper than traditional usability testing the results gained with remote testing is at least as effective.

The final part of the talk walked through the process for running usability tests at Telerik, here's a summary:

• Define Objectives & Target Audience
• Set up Test Scenario
• Recruit Test Users
• Carry out Tests
• Analyze Findings
• Design Report & Brief Stakeholders

This was littered with practical advice, such as good software to use (GoToMeeting, Camtasia), what sort of compensation to offer to ensure enough respondents (a little bit more than your target group's average hourly rate), how often to use the same testers (no more than twice a year) and even how to avoid putting testers under unnecessary time pressure (don't tell them in advance how many tasks there are).

An excellent talk, just the sort of thing I was looking for with all sorts of useful tips. The only problem I had was reading the slides off the TV screen (I was unfortunately right at the back) and sometimes hearing what Zhivko was saying (probably the being at the back thing again), 4 out of 5.