boogdesign posts

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.

Patrick started with an explanation of web standards, what they are and why they're good for you. The list of benefits he gave were fairly standard, but it's always worth reminding yourself:

• Lighter code - your HTML content is more lightweight as it doesn't contain repeated copies of your presentation code
• Ease of maintenance - when HTML is structured semantically it's much easier to make updates without breaking things than in pages built with five levels of table nesting
• Easier to change look and feel - because your look and feel is defined seperately from your content
• Multiple output media - handheld, print etc. from the same content
• Accessibility - reduce the number of potential customers who can't use your site
• SEO - increase the traffic to your site

The second section of the talk covered common pitfalls that CSS noobs fall into (been there, done that was my reaction to most of them, though I'm probably still guilty of some of them on occasion):

• New technology, old habits - the font tags have all gone, but they've been replaced by spans with inline styles
• Meaningless content - the font tags have all gone, but everything (including the headings) is a paragraph with an inline style
• Non-semantic class and id names - people often assume that class and id attributes are just there to hang CSS rules off of, but in fact they are an independent part of the HTML spec, they are a way of adding semantic value to your markup so don't use class names like 'red' when you mean 'important'
• Classitis and Divitis - adding unnecessary classes and ids to every element in your document when you could just use CSS selectors

The third section of the talk was the 'advanced' part where Patrick moved on to some specific CSS techniques. First up he covered tables, pointing out that the goal of standards based developers isn't to eradicate all tables from their markup but to use tables properly. A rule of thumb: if your data is the sort of thing you would lay out in an Excel spreadsheet, then you should probably mark it up as a table. Tables are an excellent way of showing data relationships and screen readers have built in functions for navigating across rows and columns, when designers build 'fake tables' out of divs and spans then you lose these good properties. These are good points, but I think the whole thing hinges on what your definition of 'tabular data' (or 'Excel-like data') is - my excuse for building 'fake tables' is when I want to lay things out differently on different devices (ie. on a web screen 7 columns and 4 rows, on a handheld device 4 columns and 7 rows, or even just a single column). This section also had some useful examples of the scope attribute as well as th in relation to thead and tbody and how it can styled, stuff which I'd not really appreciated before.

Next up were a number of techniques for 'fluff images' - using CSS background images instead of cluttering up the content with images which are purely presentational followed by a quick demonstration of the sliding doors technique. The talk was already running pretty late by this point so the section on image replacement was rushed through and I had to leave for the next talk I wanted to attend as Patrick moved onto forms, so I missed that, the layout portion and the conclusion.

The presentation was given in an engaging manner, and Patrick clearly has a very deep understanding of his subject, but the main problem was that he was trying to fit enough material for two talks into one hour of presentation. This spoiled a lot of the more advanced stuff, which was my primary interest, because it had to be rushed through. I still learned several useful things, and was given a few timely reminders of stuff I ought to know already, but overall this was the most disappointing talk of the day - 3 out of 5.

This was the first talk of the day, it was in the smallest room but it was packed to overflowing (people were sitting on the floor!) which is surely a good sign for the future of Microformats. The first part of the talk was a whirlwind tour of Microformats - what they are, how they're used and some examples. I was already familiar with this material so I didn't make any notes. The most interesting bit (for me) was the slide with a quote from Dan Cedarholm which referred to Microformats as 'oblivious development' - by adding semantic value to your markup you allow other to build value on top of it while you remain oblivious. A quick search today reveals I've been a bit oblivious myself, as this term seems to be in quite common use in the community, but at the time I thought it was nice.

In the second half of the talk Glen went on to the API part. His basic premise was that you should just add Microformats randomly to your web app and hope that the seeds would grow, you should think about how developers might want to use the information in your site and organise it in a consistent manner. He listed his REST-like principals for Microformats as API:

• Design URLs for maximum clarity and discoverability
• Design URLs into a schema to act as an API (his term here was 'faceted structures'
• Remember URLs have semantic importance
• Remember URLs can look and act like method calls (ie. composability of URL values, like searching by multiple tags in del.icio.us)
• Use HTTP verbs that work (a la REST, though Glen felt PUT and DELETE were not practical currently and POST should be used for updates)

His final advice for APIs was borrowed from the Microformat ethos: keep it simple. Simplicity gives you a lower barrier to entry which in turn increase the chance of take up. There was quite a long question and answer session after the talk which demonstrated Glen's in depth knowledge of the subject (in fact he appeared, to me, a lot more comfortable and knowledgeable in this interactive role than he had in the first part of the talk).

Overall pretty good, 4 out of 5. I think, given the popularity of this talk, there was scope for having an introductory session and one or more advanced sessions rather than having to rush through the first half of it, but I learned a few things and enjoyed it.