boogdesign posts

Longer posts on standards based web design, portable web development and Linux, intermingled with some stuff on my other nerd interests.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now

Category: Usability & Accessibility


12:40:37 am Permalink London Web Standards: Beautiful Design for Everyone with Ann McMeekin

Categories: Web Design, Usability & Accessibility

Review: LWS May: Beautiful Design for Everyone at The Melton Mowbray, 18 Holborn, EC1N 2LE, London 19:00 to 20:30

This event was originally going to be a double act, but Antonia Hyde unfortunately had to pull out. We were fortunate to have someone of the calibre of Ann McMeekin to pick up the slack. Ann had some very beautiful slides and spent a lot of time talking about each one, I made some necessarily limited notes from which I will attempt to reconstruct the gist of what she said (hopefully I don't misrepresent anything too badly!) and tried to locate some of the pictures from the presentation to give the flavour of it.

Ann began by talking about her background as an accessibility consultant, which she initially thought would be her dream job but, over time, she came to realize that what she really valued was not great accessibility but great design. Great design, of course, includes accessibility, but the focus is not on a check-list of requirements but the overall experience each user will have.

While accessibility is a widely accepted goal, honest discussion about it is often difficult as many people find talking about disability uncomfortable. A common reaction when seeing for the first time the rigmarole a screen reader user has to go through to get useful information out of some websites, is to feel empathy and start thinking how terrible it must be to put up with that, which leads immediately to that uncomfortable feeling. However, to provide accessible design solutions we must get past the stage of empathy in order to develop understanding about what tools we need to provide. Disabled people are not passively waiting for us to make their lives better, they just want the tools to make a better life for themselves.

Next Ann showed us a segment from a TED talk by Aimee Mullins. Aimee, who had her lower legs amputated as a child, famously competed in the 1996 Paralympics on a set of carbon fibre 'cheetah legs' (this TED talk includes a description of her experiences at the games) and has since gained fame as a speaker, model and actress. Aimee talked about her collection of prosthetic legs and the different abilities and attributes each provided her with, like the cheetah legs for running or the set she was wearing for the talk which added six inches to her normal height:

I have a variable of five different heights. (Laughter) Today, I'm 6'1". And I had these legs made a little over a year ago at Dorset Orthopaedic in England and when I brought them home to Manhattan, my first night out on the town, I went to a very fancy party. And a girl was there who has known me for years at my normal 5'8". Her mouth dropped open when she saw me, and she went, "But you're so tall!" And I said, "I know. Isn't it fun?" I mean, it's a little bit like wearing stilts on stilts, but I have an entirely new relationship to door jams that I never expected I would ever have. And I was having fun with it. And she looked at me, and she said, "But, Aimee, that's not fair."

For Aimee the loss of her lower legs is not so much a disability as an opportunity. And the opportunity isn't just to 'be normal', whatever that may mean, she can exceed normal.

Aimee Mullins gives a TED talk, standing in front of slide which highlights the popular negative connotations which go with the term disabled - showing the synonyms listed in a thesaurus

She doesn't see herself as limited, and so she isn't limited (from another TED talk by Aimee):

I loved almost everything about my time spent at this hospital, with the exception of my physical therapy sessions. I had to do what seemed like innumerable repetitions of exercises with these thick, elastic bands -- different colors -- you know, to help build up my leg muscles. And I hated these bands more than anything. I hated them, had names for them. I hated them. And, you know, I was already bargaining, as a five year-old child, with Dr. P to try to get out of doing these exercises, unsuccessfully, of course. And, one day, he came in to my session -- exhaustive and unforgiving, these sessions -- and he said to me, "Wow. Aimee, you are such a strong, powerful little girl, I think you're going to break one of those bands. When you do break it, I'm going to give you a hundred bucks."

Now, of course, this was a simple ploy on Dr. P's part to get me to do the exercises I didn't want to do before the prospect of being the richest five year-old in the second floor ward, but what he effectively did for me was reshape an awful daily occurrence into a new and promising experience for me. And I have to wonder today, to what extent his vision, and his declaration of me as a strong and powerful little girl, shaped my own view of myself as an inherently strong, powerful and athletic person well into the future.

Good design should create this same feeling of empowerment, for everybody. It is not about ticking off boxes, but about enabling people to achieve their goals, provide tools for augmentation, not just equalization. And just because a tool serves a purpose, doesn't mean it can't be beautiful:

This is where it really hit home for me -- that my legs could be wearable sculpture. And even at this point, I started to move away from the need to replicate humanness as the only aesthetic ideal. So we made what people lovingly referred to as glass legs even though they're actually optically clear polyurethane, a.k.a. bowling ball material. Heavy! Then we made these legs that are cast in soil with a potato root system growing in them, and beetroots out the top, and a very lovely brass toe [...] Then another character was a half-woman, half-cheetah -- a little homage to my life as an athlete. 14 hours of prosthetic make-up to get into a creature that had articulated paws, claws and a tail that whipped around, like a gecko. And then another pair of legs we collaborated on were these look like jellyfish legs. Also polyurethane. And the only purpose that these legs can serve, outside the context of the film, is to provoke the senses and ignite the imagination. So whimsy matters.

So prosthetic legs are not just a utilitarian accessibility tool but something beautiful in their own right, a work of art, and the same can be true of our own designs. As to how to achieve beautiful, accessible design, Ann covered that in three sections: Structure; Alternatives; and Flexibility.


The foundation of good design is structure, which implies planning. As an example of what happens when there's no structure Ann talked about the Winchester Mystery House. This was a house built by the widow of a member of the Winchester Repeating Arms Company dynasty, she believed that the ghosts of all the people ever killed by one of the rifles were out to get her and the only way to keep them at bay was to keep building the house. So it was built, 24 hours a day for 38 years with no plan or goal in mind other than to be building continuously.

The Winchester House, California

Although the end result is, in many ways, fascinating, from the point of view of being a usable living space it's a complete disaster - it's almost impossible to navigate without a map, and so unusable. If you are willing to do a little planning, and from the recent boom in User Experience it seems companies are able to appreciate the value, then you can build an accessible structure without compromising your design. Ann had a number of examples, the first was these bus stops in Bristol:

Integrated Accessibility: Raised paving at Bristol bus stops

The paving is raised at each bus stop, even well out into the suburbs, so that people on wheel chairs (and mothers with wheelchairs) can simply roll on to the bus - no need for leaning buses that the driver has to remember to operate, or special ramps that have to be got out and attached, slowing everyone's journey. The bus stops are a shared space, anyone can use them, there was no need for having 'normal' bus stops and 'special' bus stops. Another example of shared spaces in action is the steps at the Brunswick Shopping Centre. Ann had been walking up and down these steps for two months before noticing that they had an integrated ramp:

Integrated Accessibility: Integrated steps and ramp at the Brunswick Centre


As we've just seen, alternatives don't have to be hidden - there doesn't have to be a ramp round the back while everyone else goes up the steps at the front, but they do have to be discoverable. An example is Braille labels - you see these all over the place now alongside the visible labels on signs and buttons, but how do these actually help blind people? Does anyone really expect blind people to walk around feeling all the walls on the off chance there'll be Braille there? Designers have ticked the box - 'provide an alternative for blind people' - but they've not really thought about what a blind person needs to be able to navigate the environment. Don't simply provide a Braille version of the menu, think about what a blind person needs to be able to independently go to a restaurant and order a meal.

One area where it's always appropriate to provide text alternatives is for pictures and videos. Captions on images can be integrated into the design fairly easily, like, for example, on the The Big Picture blog on Transcripts for videos have traditionally been regarded as prohibitively expensive, especially for small producers. But there are a number of cheap options these days:


Not all disabilities are constituted of a fixed and unchanging set of symptoms (eg. MS sufferers can vary from day to day and hour to hour). An insufficiently flexible site, may, even for the same user, be reasonably usable one day, but unusable the next.

Also not all people who would benefit from making use of 'accessible' options will self identify as disabled. Older users are likely to benefit from font sizing and readability options just as much as the partially sighted or those with learning disabilities, but they may be unlikely to click on a link for 'disabled users' in order to find them.

When thinking about flexibility bear in mind that people don't need to have the same experience, but that doesn't pre-dispose that anyone should have a lesser experience. Ann used an example of a blind friend of hers who liked to visit the Tate Modern. You might wonder what a blind person could get out of looking at a painting, but he could listen to the painting by listening to ambient sound reflected off them, the different colours get reflected in different ways. Obviously he's not getting the same experience a sighted person would do, bet then sighted people aren't getting the experience he is and both can get a lot out of it (and, by the way, the Tate Modern has help and tours for blind and visually impaired visitors).

If you have compelling content, of course, you'll get users no matter how badly designed your site is. Amazon, for a long time, had terrible accessibility, but everybody liked cheap books. In this situation users develop coping strategies - Ann told us about one blind user who'd worked out a very detailed method of getting to what he wanted on Amazon, to the extent that it went "do this, then hit the tab key 43 times." Sure you might take comfort in the fact that someone has figured out how to use your site anyway, but did you need to make it that painful?

To finish with, Ann reminded us that while good design can be difficult, it's from solving the difficult problems that we derive the most satisfaction.

Post Talk Discussion and Questions

To conclude the talk, instead of going straight into questions, Ann asked us for examples of good design to add to her, regrettably, somewhat small collection. The first example was a blind person who went around sticking irreverent and subversive Braille messages on to signs, a sort of graffiti that few people are aware is even there. Another person mentioned some recent improvements to the riverside area in Bedford which had been done with accessibility in mind so that everyone could enjoy the river.

As counterpoint, another attendee described a lift he'd seen where they'd put Braille labels on the buttons, the only problem was - they were touch sensitive buttons! This was clearly an example of ticking the boxes rather than trying to understand what a blind person would need in order to use the lift.

There were a lot of other good examples and discussion but I'm already closing in on seven days to write up a two hour talk, so I'll leave it there. Another excellent LWS event, 5 out of 5 once again. Antonia will hopefully be able to make a future talk, in the meantime watch out for the June event on Flash vs HTML5.

Technorati tags for this review:    

Tweet this!
Send feedback »PermalinkPermalink


12:23:08 am Permalink London Web Meetup: Top 10 UX Gotchas

Categories: Usability & Accessibility

Review: London Web May: Top 10 UX Gotchas, Conference learnings & Traffic kickstarts at Hoxton Apprentice, 16 Hoxton Square, London. N1 6NT. 19:30 to 21:30

With UX London in full swing, this month's London Web had a usability focus. Google's George Zafirovski was in town and had agreed to give a talk on the top ten User Experience gotchas. By way of introduction George talked about the user experience design team at Google. Many people with long experience of Google's products may be surprised to hear they have any usability engineers, but there is increasing focus on usability throughout the company. There are UX teams in many of Google's offices available for to engineers and product managers for consultation, and (apparently) there are adverts for their services in the toilets. As well as being the 'fluid glue' which holds the engineers and product managers together, user experience research can also initiate products such as the recently launched mobile services in Africa.

In order to assemble this talk George asked his UX colleagues at Google to nominate their own gotchas, and then compiled the top ten from their feedback:

1. "I skipped the wireframes and produced hi-fi mocks instead." - By going straight to a hi-fi mockup you lock yourself in to a single solution. Better solutions can usually be found by comparing a number of approaches, and you can produce multiple lo-fi mockups in the time it takes you to produce a single hi-fi one.

2. "We don't have time to test it." - You never get a second chance to make a first impression, don't spoil it by having a glaring issue which would have been quickly picked up in testing.

3. "Just make it a setting." - This can lead to a cascade of UX issues, both in controlling the settings themselves and in the combinatorial explosion of possible interfaces engendered by the settings.

4. "We only want to test with savvy users." - If only savvy users can use it, then you don't have a usable application. "Passengers will one day become drivers" - if you just consider the needs of the main user (the 'driver'), then the less experienced users (the 'passengers') will not choose your product even when they've gained the experitise to use it.

5. "We'll let the translator worry about it." - Issues like sizes of buttons to accommodate labels and bidi need to be dealt with in the original design, the translator can't be expected to re-design your application just to make it usable in a different language.

6. "We'll launch this and then figure out how people use it." - If you don't know how to use it when you launch, how will your users figure it out?

7. "We'll fix this in version two." - Similar to 2, if you mess up the version one then many people will not even look at version two.

8. "The target user is a late-twenties technology professional." - There's no such thing as a late-twenties technology professional. Even within that seemingly homogeneous group there is huge variety, don't kid yourself that because one late-twenties technology professional finds your application usable that anyone else will.

9. "If you build it, they will come." - If it's not usable, they'll leave again.

10. "Who is this for?" - Don't ask this question, assume it will be for everyone.

After the talk there was a Q&A, I made some notes about the ones I found interesting. The first question referred to point 8 - do they use personas at Google? George said that they don't, they try to design for everyone rather than focus on individuals.

The next question referred to a comment George had made during the talk, that Google would never compromise the user experience in order to make more money. Several people advanced the opinion that advertising decreased usability, and, since advertising is Google's primary revenue stream, there was a built in conflict of interest there. George said that people do click on the ads, so the ads are useful, and advertising is subject to usability testing the same as everything else.

There was a question about what user testing tools are used at Google, George's answer was "everything." They do wireframing, paper prototyping, cognitive walkthroughs, usability studies every one to two months during development and also, because they practice dogfooding, they get period of free user testing from a pool of ~20000 users, all of whom have direct access to the bug database, before public launch.

An audience member asked that, since Google is famous for releasing lean products, is that strategy not in contravention of several of the gotchas on the list? I think this question struck a chord with many of the attendees - George himself had said Google have an agile, "release early, release often" approach which seems to contradict at least six and seven off his list if not more.

For the second talk, Mike Martin had been drafted in at the last minute to cover 'Growing a Social Network' in place of the originally planned 'Site Traffic kickstart'. I didn't take too many notes for this one, the basic advice is:

  • Pick a niche or an event to focus your site around initially, people don't want to join a site with no activity
  • Provide good (link worthy) content, and provide (and consume) APIs so that others can take advantage of it
  • Take part in the conversation, talk about your site, your network and your content on other social networking sites

Another good evening, interesting to see inside the UX mind of Google, a shame Mike hadn't had a bit more time to prepare his talk, but 4.5 out of 5.

Technorati tags for this review:    

Tweet this!
1 feedback »PermalinkPermalink


04:57:10 pm Permalink London Web Meetup: Accessibility in the Days of jQuery, Flash and AJAX

Categories: Usability & Accessibility, Front End Web Development

Review: London Web February: Accessibility in the Days of jQuery, Flash and AJAX at Wahoo Sports Bar, 14 Putney High St, Putney, London, SW15 1SL 19:30 to 21:30

This week, accessibility has been a bit of a theme for me, after LWS Inclusivity on Monday I was at the London Web Meetup on Accessibility on Thursday night.

To start with, Nathan gave a short presentation on HTML5 and CSS3. It was an introductory talk, so nothing new to me, but there was a very interesting open discussion afterwards. The focus was whether we'd even be able to use this fancy new HTML5 and CSS3 stuff while IE6 continued to account for 20% (or more) of the users of any given website. The Yahoo! home page still sees a huge number of IE6 visitors, and people who worked a lot with city clients said IE6 was still the default browser for many of their customers, the recent security scares do seem to have created an impetus for change among some of the banks. There was also some discussion about whether we even need to provide a pixel for pixel identical experience in every browser, or whether we needed to have the visual bells an whistles at all - apparently a front end engineer at Yahoo! Sports turned off all the rounded corners and showed the result to a designer and the designer couldn't spot the difference. My contribution to the discussion was that as more and more people use a mobile device to browse the web, and a lot of the browsers on those do support HTML5 and CSS3, you may be able to start using these much sooner if you're targeting these users.

After a short break we moved on to Artur Ortega's demonstration of screen readers and WAI-ARIA. Artur had JAWS, the leading commercial screen reading software, and NVDA, the free and open source alternative. He also mentioned Orca, the Gnome Linux based screen reader, and VoiceOver, which comes free with Mac OSX, including the iPhone version, which Artur used (this reminded me of Sandi's comment at the end of Monday's talk - including the tools in the operating system brings wider benefits).

Artur started off with a discussion of how the needs of screen reader users differed from fully sighted users. Although web pages are two dimensional, a screen reader sees them as a one dimensional audio track. This means a screen reader user needs 'timestops' if they are to navigate the page efficiently. These can be provided, in a well structured page, by headings - a screen reader can navigate from heading to heading with a keystroke without reading all the text in between. So the first simple improvement you can do to make your pages more accessible is make sure your page uses headings in appropriate places. Another small change which can make a big difference is to indicate language correctly with the lang attribute. This is very important in pages where multiple languages are likely to appear, such as search engine results. Currently, Yahoo! is the only search engine to do this - Artur demonstrated the huge difference it made to the screen reading experience, a set of multi-lingual search results became almost unintelligible when the screen reader was in the wrong language mode. Since search engines already work out the language of a particular page and expose that information, as evidenced by them providing 'translate this page' links in the results, this ought to be a simple change to make.

Next, Artur moved on to WAI-ARIA. ARIA is Accessibility for Rich Internet Applications, web apps with heavy use of Javascript and AJAX. For a general introduction see the W3C WAI-ARIA Overview, or More Accessible User Interfaces with ARIA which I attended in December. Support for ARIA is available in IE8 (there was some, but not much, support in IE7) and Firefox 3.0 (and up), when used with JAWS 10 or later (or recent releases of NVDA). Artur showed us ARIA landmarks and the aria-required attribute as well as, briefly, ARIA live regions.

There were a lot of questions all through the talk, so we had to cut it short at the end. I think many people, like myself, were totally in awe of Artur and his ability to navigate the web with a screen reader - especially when he demonstrated doing it at 'normal' speed near the end (he'd had it set to slow mode to give us a chance to keep up during the demos). I was inspired to spend a few hours the following morning implementing aria-required on a form in my web app at work :)

Another great event, 4 out of 5. I'm not sure a bar is the most comfortable environment for listening to a presentation, it seems that few in the London web community agree with me there, though. On the plus side, unlike most the events I attend this one was within ten minutes walk of where I work, so no need to be fighting my way through London rush hour to get there. The talks themselves, and the discussion afterwards, were excellent.

Technorati tags for this review:    

Tweet this!
Send feedback »PermalinkPermalink


05:57:30 pm Permalink London Web Standards: Inclusivity with Sandi Wassmer

Categories: Usability & Accessibility, Front End Web Development

Review: LWS February: Move over Web Accessibility, inclusivity is heading straight at you! at The Square Pig, 30 - 32 Procter Street, Holborn, London, WC1V 6NX 19:00 to 20:30

I'm always interested to learn more about accessibility so, after I enjoyed last month's LWS so much, this event was a must attend. As before, Jeff live-blogged the talk and I will be covering most of the same ground, but hopefully with a different enough emphasis and perspective to make this worth reading too.

Picture of the question and answer session at the end of the talk

Sandi started off here talk by discussing the need for the new term, 'inclusivity'. Accessibility has had a lot of powerful advocates in recent years but that has resulted in a somewhat negative image and a narrow approach. The need for accessible websites has been driven into people's conciousness, but not the underlying principles. Accessibility has become,"that thing you have to do to make disabled people happy." So to make people happy developers are resorting to a checklist approach which isn't actually benefiting users. Marketers fear that implementing accessibility will devalue the brand; designers fear it will limit their design options; developers worry that it will reduce functionality. In fact, accessibility, when done right, need not cause any of these issues.

Inclusivity is an effort to repackage accessibility with a more positive spin, by returning to first principles while combining with other elements of usability and remaining practical. The focus needn't be completely on screen reader users - only 3% of the UK's registered blind people are totally blind. Providing an alternate text only version of your website is not the same thing as having an accessible website, according to Sandi the aim of accessibility should be,"an unobtrusive bridge between myself and the world." Inclusive design allows people to have a choice in how they interact with your website. The pay off to taking an inclusive approach to design can be huge: there are 10.6 million registered disabled people in the UK, 19% of the working population is registered disabled and they represent approximately 80 billion in annual purchasing power.

Inclusive design is the embodiment of seven principals, it is:

  • Unbiased
  • Flexible
  • Straightforward
  • Clear
  • Sensible about errors
  • Minimises physical effort
  • Emphasises appropriate shape and size
To embrace inclusive design you also need to attack three assumptions:
  • Disabled vs Not disabled - People are people, disability is not a binary attribute, there is a range of abilities
  • Accessible vs Inaccessible - Accessibility is subjective, there is not such thing as an accessible site, sites will always be more or less accessible to different groups of users
  • Disabled people do not appreciate design - Anyone can have bad taste, this is orthogonal to their abilities in other areas

You might worry that you will never get accessibility 'right' - Sandi offers the advice,"just do your best." You just have to keep learning - accessibility is a process, not a finishing state - and you have to use that knowledge whenever you can.

Sandi then moved on to how the design process should be structured in order to take account of inclusivity:

  • The Brief should not be brief and should include a discussion of the principals of inclusivity.
  • The Plan should include user testing (with real users) and nominate an inclusivity champion.
  • The Functional Scope is where the real world will impinge, how much and what type of user testing does the budget allow?
  • The Technical Scope has everything nailed down, at this stage you just need to make sure everyone is communicating so that the overall goals are not compromised by a simple misunderstanding.
  • Learning, Designing, Testing, Tweaking and repeat as often as necessary (or you can afford).

Next Sandi discussed the relationship of inclusivity with web standards and best practices. The key misconception many people have about WCAG is that last letter - they are guidelines, not rules. The difference is that while rules are inflexible, they can only be complied with or not, guidelines are a relationship, they guide you on the way to discovering the best interface for your users.

Usability has much crossover with accessibility, though unlike accessibility there are no legal requirements to make your site usable. With usability you're asking yourself how specific users are going to accomplish specific goals in a certain context and evaluating your solution according to its effectiveness, efficiency and (user) satisfaction.

Web standards form the foundations of good accessibility, but they are just the beginning. Having your page pass the W3C validators doesn't guarantee it will be accessible.

The two most popular strategies for delivering good accessibility are progressive enhancement and graceful degradation. Sandi said that while progressive enhancement is a strategy, graceful degradation is an afterthought. Progressive enhancement is the way to go because it allows you to build your web site in layers and so make available a good experience to everyone.

Finally Sandi discussed why user testing is important, even if you have excellent market research and analytics. Consider three users: Peter, George and John. All are marketers in their mid-thirties, with 2.4 children and are demographically identical. They are all using Firefox on the same brand of computer, so are basically indistinguishable from the point of view of market demographics and browser identification data, however:

  • Peter is an internet lover, he's maxed out his browser with nearly every extension he could get his hands on
  • George is a luddite who only uses a browser because he needs it for work, he's turned Javascript off because he heard, some time ago, that it was dangerous to browse the web with it enabled
  • John is technically savvy, like Peter, but is visually impaired and so uses a screen reader

Clearly these three users have very different needs, and yet you're only going to see the difference between them if you do user testing.

After a wrap up, where Sandi re-iterated the need to always keep learning, we moved on to the question and answer session. There were a few questions which stood out for me:

  • Providing mobile access, is this accessibility, inclusivity or usability? - All of the above! Sandi's advice was to just try your best, not all content needs to be available on all devices. While the holy grail may be a site which is completely accessible on desktop and mobile, budgetary constraints will probably limit you before you get there.
  • How can we get the message of inclusivity to banks and other large and slow moving institutions? - Bring it to the mainstream, social change is hard work but it's the path to ultimate victory. Also, challenge people's stereotypes, don't let them think of a small number of completely blind people using screen readers, get them to think more broadly. One of the audience pointed out that one of the best business cases for accessibility had been at Legal & General. Also you should consider the people with the most power at these institutions tend to be older, and while they may not consider themselves disabled they are likely to suffer from impaired vision and other ailments simply due to old age making them a ready made market if you phrase things well.
  • What's the best way to develop an accessible website, where should your concentrate the effort, on semantic code? - A problem is that technology is always changing, and assistive technology doesn't always keep up, so you can't always provide the best solution now, and often the best solution now won't be the best in the future. This is why the WCAG is not about technical solutions but about guiding you to an understanding of your users.
  • Is there ever a place for exclusive design? - No, stuff is more usable when built for everyone. For instance the Mac accessibility tools built into the OS, now everyone can use them even if they don't consider themselves 'disabled'.
Another excellent event, 5 out of 5, I'll be watching out for the next one.
Technorati tags for this review:    

Tweet this!
1 feedback »PermalinkPermalink


01:04:35 am Permalink YDN: More Accessible User Interfaces with ARIA

Categories: Usability & Accessibility, Front End Web Development

Review: More Accessible User Interfaces with ARIA at Skills Matter, 116-120 Goswell Road, London, England EC1V 7DP 18:30 to 20:00

I've long been meaning to take a closer look at WAI-ARIA, so last week's YDN talk at Skills Matter by YUI developer Todd Kloots seemed like an excellent opportunity to learn the basics. With them starting at half six, forcing me to travel halfway across London in the middle of rush hour, I often miss the start of Skills Matter events and this one was no exception - though this time the main problem was that they are now at new offices and I went to the old one first.

The talk was split into four parts, followed by some Q & A:

  • How ARIA solves problems of perception
  • How ARIA solves problems of context
  • How ARIA solves problems of discoverability
  • Tips and tricks for working with ARIA

How ARIA solves problems of perception

One of the problems faced by screen reader users is working out what a page element they come across is for and what state the element is in. A sighted user can look at a web page and easily see an area devoted to navigation and an area for main content, what things are toolbars and buttons and what state they're in (eg. bold mode in a text formatting toolbar).

How ARIA solves problems of context

HTML has only a limited palette of context setting elements - headings, lists and form grouping elements, such as h1 and fieldset can be used to indicate section breaks in your content. But if you wanted to indicate a tab control or a toolbar to assistive technology there's no standard markup to do that.

To address this ARIA has landmark roles, as we saw earlier, but it also allows you to indicate which sections of your page should be treated as a document and which should be treated as an application. In document mode, the screen reader responds to its own keyboard shortcuts for browsing, in application mode you can provide keyboard shortcuts for working with your widgets. ARIA also provides recommendations for keyboard shortcuts to use.

Todd discussed two ways of making sure your widget is keyboard accessible without drowning the user in choices. For example, if you have a toolbar widget you may not want the keyboard user to have to tab through every item on the toolbar every time they encounter it. It would be better if they could tab to select the toolbar but then tab again to skip over it if they didn't need any toolbar functions at this time. The two techniques are to use aria-activedescendent or to use a roaming tab index - set a tabindex of -1 on all the child elements of your widget and then adjust focus programmatically in response to key strokes. Todd has previously published a blog post which describes both focus management techniques in detail, he currently prefers the roaming tabindex approach because of its backwards compatibility (though watch out for the known focus event delegation issues).

How ARIA solves problems of discoverability

After you've created a keyboard accessible widget using ARIA roles and states you need to make sure users can actually discover your widget - all your good engineering work goes to waste if users never realise the functionality is there. This is where aria-live and aria-describedby are useful.

A live region allows text to be spoken to the user without that text gaining focus, thus losing the reader's place in the content. Depending on the nature of the message it can either be polite, assertive or rude - ranging from waiting until a pause or interrupting the user whatever they may be doing. An auto-complete list would be an ideal candidate for a live region - Todd demonstrated how live regions work on the Yahoo! Suggest feature on their search page.

The aria-describedby property allows you to link to a longer description of what your widget does, so you can inform the user, the first time they focus on your widget, of how to access the functionality of your widget as well as what to expect when they interact with it - again this was demonstrated in the suggest feature on Yahoo! search.

Tips and tricks for working with ARIA

The key tip if you're going to delve in ARIA is to install a screen reader and test things yourself! There are free ones for various platforms (eg. Windows and Linux). If you're unsure where to start, read this tutorial about setting up a test environment with NVDA and Firefox.

The second tip was more of a warning - ARIA gives developers a great deal of control over the end user experience, because it allows them to bypass the virtual buffer of the screenreader and talk directly to the user. This brings with it a risk - having all web browsing mediated by the screen reader made for a consistent user experience, now there's the potential for every site to be different leading to user confusion.

Q & A

There was an interesting question and answer session at the end. The first question was about the new semantic elements in HTML5 and whether screen readers were taking advantage of them yet - not so much, Todd felt that mush of ARIA is available today to far more users. Further questions brought up the frightening prospect of web developers having to take into account not just compatibility across various browsers but also a second dimension of cross screenreader compatibility and finally if any of the popular Javascript libraries had built in support for ARIA (YUI 3 has built in support).

All in all this was an excellent talk, 5 out of 5. One of the most technically detailed talks I've attended at Skills Matter - far more stuff was discussed than I've managed to fit into this blog post. If you're interested I recommend you watch the video.

Technorati tags for this review:    

Tweet this!
Send feedback »PermalinkPermalink


11:55:14 pm Permalink Standards.Next Cognition and Accessibility

Categories: Web Design, Usability & Accessibility, Front End Web Development

Review: Standards.Next Cognition and Accessibility at City University, Room C343, Northampton Square, London, England EC1V 0HB 13:00 to 17:00

Last weekend I went to the second Standards.Next event, a whole afternoon devoted to talks and discussion related to the often ignored and misunderstood area of accessibility for people with cognitive impairments.
Picture of the audience listening attentively to Ian Pouncey

Accessibility beyond code - Antonia Hyde (slides)

Antonia talked about some of the issues in enabling access outside of the details of code. With the range of disabilities, plethora of personal preferences and array of access methods are there any general approaches which help to address all the combinations? To provide some context we watched two video clips of Martin, an experienced web user with learning difficulties. First we saw him using a site he was familiar with, eBay, then a site he was unfamiliar with, Amazon.

Martin got on very well with eBay, he made extensive use of its consistent search features and the nature of the site means that it features a lot of large meaningful pictures which are the focus of the content. Even so, there were some details which caused issues which perhaps were not significant enough that the designer would even think of them. For instance there is a 'Buy it now' button on the product pages which, not surprisingly, allows you to bid for the item, but there is also an identical 'Buy it now' image on the search results which wasn't clickable.

On Amazon, a site often lauded for its usability, Martin had a great deal of difficulty. There was a lack of meaningful icons, a lot of the most striking imagery on a page was unrelated to the main content, there was often bad typography and poor contrast and the buttons were not clearly defined. Martin had great difficulty first of all trying to sign up for the site and then trying to buy something.

Antonia then talked about some general strategies for making sites more accessible:

  • Be literal: This doesn't mean going in to excruciating detail, it means saying things simply and clearly with no contradictions. It also means grouping page elements and respecting the hierarchy of visual language, having consistent colour coding and using meaningful icons with related words. There was a great (but bad) example taken from a warning sign on the Underground - the text says "Don't run on the escalator" but the graphic shows a man happily running down the escalator with his briefcase.
  • Make things bigger: Not just literally, for instance having space around items can make them appear bigger. Also having obvious tools for text sizing, alternative colour schemes and content access methods can really make or break the accessibility of a site. We got into a bit of a side discussion at this point about why users didn't just use built in browser functionality for this, the gist of it was that browser manufacturers need to find a way to make stuff more discoverable.
  • Responsibility: Accessibility is the responsibility of all people involved in creating a website - designers, developer, content producers and managers are all equally responsible. Cohesion and consistency is a key factor in accessiblity, and content is useless if it can't be accessed.

What is Autism - Jamie Knight (slides)

Jamie is a web developer who is autistic. He gave a presentation on what autism is and this was followed by an open discussion. Autism means having a thinking process which is slightly different in the way it processes ideas and inputs from the environment. Some things which are problematic for autistic people are:

  • Background music on websites, and background noise in general, make it impossible to read
  • Language coming too quickly (eg. in video or audio), especially if there are multiple speakers with no delay or visual pause between them
  • A literal mindedness can lead to confusion, eg. "Add friends" means a different thing on almost every website, especially in Facebook where it means different things on different pages

On the other hand the web can be extremely liberating and empowering for autistic people, because it removes a lot of the time pressures of traditional social interaction (Antonia also mentioned this). In the interesting discussion that followed Jamie discussed how he used a screenreader (originally one he'd written himself) when he was too tired to read, highlighting that the set of people that are using screenreaders is not necessarily identical to the set of people that can't see your site. I also learned about the different voice options available in screenreaders - a faster 'robot voice' or the slower but more 'human' voice which differ in the algorithms used to determine sounds. Jamie used different voices in different situations - the robot sounded a bit strange reading out text in the first person, the human voice has difficulty with some pronunciations.

Why user testing beats dogma - David Owens

David had recently completed a project which included a lot of testing with users who have cognitive issues. There were no slides but it was good to hear from someone with practical experience of the sort of issues which can come up:

  • Before they even started their testing they had to rewrite all their user testing scripts as they were too complex and lacked context - it's not just your website that needs to be accessible.
  • Don't overcomplicate. When developing they'd paid particular attention to the source order - putting the main content first and the navigation after it. What this does is completely confuse screen reader users, especially the partially sighted ones for whom the layout of the page on screen no longer matched what they were hearing.
  • Reiterating one of Antonia's points, you must signpost the tools. Mostly users won't remember how to find their browser's text size option, or the key combination required.
  • If it comes to a choice between 'best practice' or the standards and what your test results show, always choose to make things easier for your users.

Content and Cognition - Ian Pouncey (slides)

Ian presented some practical advice based on his years of experience working in web accessibility:

  • Consistency: Make your navigation consistent, don't chop and change main navigation between pages; use a small number of fonts, counting different sizes and weights as different fonts; make sure your interactive elements, links and buttons, are the same across all pages and clearly are links and buttons.
  • Structure: Make sure your headings are clear and meaningful and represent their associated content; Break content up into lists, keeping each point short and concise; Make use of whitespace, particularly horizontal spacing; clearly differentiate content types, eg, quotes.
  • Focus: Avoid contrasting blocks of colour, eg. don't make your navigation more visually appealing than your main content; Avoid unexpected sound and moving content; Avoid popup windows and (after some comments from the audience) light boxes.
  • Readability: Make sure you have adequate text size and line height; Limit your line length to 70-80 characters but avoid justification because of the 'rivers of white' problem; Make sure you have good colour contrast; Keep your paragraphs short.
  • Transformability: Bearing in mind that you can't please everyone, you should make sure your content is easily transformed - ie. allows for resizing; Supports user stylesheets; Works well with images and/or styles disabled;; Make sure your content is printable, as many people prefer to read from paper; Provide an API or feed for when all else fails. In this section also mentioned that he thinks elastic layouts (where the size is based on the font size) are a bad idea - they make text resizing behave like page zoom, in effect taking an option away from the user.
  • Content: Pay attention to your spelling and grammar, if you can't get someone else to review your writing then leave it for a few days and look at it with a fresh eye, also getting a screen reader to read it to you may help; Define your terms, avoid jargon but not at the expense of clarity; Always summarise your content - point, example, explanation, summary.
Ian then gave a practical example of reworking a simple web page to be more accessible and some of the techniques you might consider. In the discussion we got on to CAPTCHAs and related techniques:
  • Don't assume that 'simple' tasks are simple, eg. 2+2 and Dyscalculia.
  • Similarly, questions like "What colour is the sky?" can cause problems both for those with a literal turn of mind and for those who struggle with language.
  • Remember it's your job to determine if it's spam or not, not your user's.

The day concluded with Bruce asking for people to get involved with the WHAT-WG HTML5 work and share their opinion on two particular issues:

  • The table summary attribute is to be removed in HTML5, as in HTML4 it is little used and is only to be read out to screen readers. The alternative currently recommended by the working group is to summarise the table in the preceding content.
  • Another issue of concern is with the new HTML5 form controls. Currently they are not styleable with CSS, which means they will present as the host operating system defaults, which is good for consistency. On the other hand, if they're not styleable it's far more likely designers won't use them and will instead come up with their own non-standard controls, thus losing the semantic benefits.

If you have any opinions, please contact Bruce.

All in all another great day, 5 out of 5. Watch the website for news of future events in the series or follow #standardsnext on Twitter.

Technorati tags for this review:  

Tweet this!
Send feedback »PermalinkPermalink


11:45:23 pm Permalink Standards.Next HTML5

Categories: Usability & Accessibility, Front End Web Development, Standards, HTML and CSS

Review: Standards.Next HTML5 at Bricklayer's Arms, 31 Gresse Street, London, W1T 1QY 13:00 to 17:30

This was a free event with several speakers covering several aspects of the draft HTML5 standard. It wasn't an ideal venue for presentations as there was a big pillar in the middle of the room, and as a result I couldn't see the right hand side of most of the presentations, but I think I got the gist of it.
Picture of the audience listening attentively to Martin Kliehm

HTML5: Are you mything the point? - Bruce Lawson

Bruce covered several popular misconceptions people have about HTML5:

  • Evil browser vendors dominate - while they do have a lot of influence, because ultimately it's the browser vendors who have to implement it all, the key point is that all the browser vendors are collaborating so they'll all be implementing the same standard. Also the spec takes a 'pave the cowpaths' approach - if browsers already support it, and it is in common use, the spec defines and legitimizes it - for example the embed element.
  • Hello tag soup, goodbye XML - while it's true that you don't have to close elements if you don't want to (unless you're using XHTML5), the HTML5 spec defines what browser should do with invalid markup, so invalid markup should look the same in all browsers.
  • Kills Flash/Silverlight/Javascript - while it provides an open alternative to Flash and Silverlight, they're not going away any time soon. The Javascript one is a bit hard to understand, but Bruce had been asked about it several times so he felt it was worth mentioning - HTML5 provides several things which replace the need for lots of the 'little' stuff that JS is currently used for, eg. the details element.
  • It'll break the intertubes - HTML5 has been designed to be backwards compatible and the choice between several options has been decided by what works in current browsers: for example many people wanted the href on arbitrary elements but this didn't work in any browser; however allowing the a element to wrap arbitrary content does work, so that's what's in the spec.
  • It hates accessibility - the philosophy behind the WHATWG's approach to accessibility is to build it in to the elements, for example the new form elements provide lots of extra data and functionality, so the accessibility happens without any special effort by the author, while the approach taken by ARIA is more to 'bolt on' accessibility. Of course, there are some issues with this approach - ARIA can do a lot of things HTML5 doesn't support, and assistive technologies already support ARIA, while the AT suppliers have not gotten involved in the HTML5 spec process despite being invited.
  • Can't use it until 2022 - in fact a loot of it can be used right now, even in Internet Explorer. The definition of 'ready' comes from a misinterpretation - Ian Hickson was asked when the spec would be finished, since 'finishing' requires two complete and fully interoperable implementations he said it wasn't likely to be finished until about 2022.

Bruce then discussed several of the new elements in HTML5, many of which I covered in my earlier blog post, the outlining algorithm (so you can have multiple h1 elements in the page), and then covered the new form elements - now supported in Opera 10 beta. The forms stuff looks quite cool, so I'll try and do a full post on that in a few weeks.

HTML5.js - Dean Edwards

Dean is the creator of ie7.js, a script "to make Microsoft Internet Explorer behave like a standards-compliant browser" and now he's done it again with html5.js, a script which adds support for HTML5, including all the new structural and form elements to browsers which don't currently support it. He did a very impressive demo, which included demonstrating all the form elements inheriting the windows theme and rendering correctly. There was some discussion about how he'd achieved all this, and Dean admitted to "quite a lot of browser sniffing," but "the good kind of browser sniffing."

Javascript APIs - Remy Sharp

Remy gave an overview of several of the new APIs in the HTML5 spec, including some which are now in separate specs:

  • Canvas - supported in every major browser except IE, and even there you have options.
  • Drag and Drop - Supposed to work in Firefox, Safari and Opera, but Remy had only managed to get it working in Firefox. Instead of writing a whole load of javascript to implement drag and drop, in HTML5 you just declare draggable=true on an element and then hang some functions off the dragstart and dragend events.
  • Offline Apps - one of the most interesting possibilities presented by HTML5 is the possibility of offline web applications. Native support is coming in Firefox, Safari and Opera and is available already, sort of, in other browsers thanks to Google Gears. Remy covered the application cache, online and offline events, the flag (which, unfortunately, only appears to work in Firefox) and the cache manifest file.
  • Geolocation - supported in the latest Firefox and the iPhone version of Safari and in other browsers, again, sort of, by Gears. The interface is fairly simple, just call getCurrentPosition and pass in a callback function.
  • Messaging - an API to pass messages between pages in different domains, supported by all the latest versions of the major browsers (even IE). Remy showed us the postMessage function and onMessage event, and discussed some of the security features.
  • Web Workers - threading for Javascript, supported by Chrome, Firefox and Safari and also another feature of Gears.
  • Storage - actually two different types of storage: key/value stores for both the window and the domain plus a SQL storage engine, sessionStorage, localStorage and Database respectively.

Remy has several examples online if you want to have a more detailed look.

The HTML5 Canvas Element - Martin Kliehm

The bulk of this presentation was made up of a bunch of demos of really cool stuff done with the canvas element, so a bit hard to describe in a blog post and keep things short. Hopefully it'll appear online shortly, in the meantime this is one of the more blogged about and well known parts of HTML5 so I'll not go into details. Martin discussed several 'fake 3D' rendering techniques, some of the performance advantages over stuff like SVG as well as some of the possibilities to come once full 3D support was available.

HTML5 Accessibility - Steve Faulkner

Steve started off with a couple of entertaining slides illustrating the contrast between what he thinks is important as far as accessibility in HTML5 is concerned and what has seen the most discussion. So far everything has centred around whether or not to require the alt attribute and various apocrypha of tables, where it needs to discuss ARIA, the canvas element and text alternatives. So while so far things have not been so great there is a great deal of potential in HTML5. All the extra semantic elements (header, article etc.) can provide additional information to assistive technologies, as will the new form controls. While canvas and the new video element don't currently offer much (canvas is worse than Flash - fallback content placed inside of it simply disappears as far as ATs are concerned), having these elements as first order members of the DOM presents opportunities in the future for screen readers and other technologies to interact directly with media experiences at a deep level. Steve then discussed the compatibility (or otherwise) of HTML5 with ARIA - after some argument the validator accepts valid ARIA attributes and browsers already implement support in HTML5 anyway, so in many ways it doesn't matter whether the WHATWG adds specific support. He finished off with some slides showing the level of browser, screen reader and Javascript library support for ARIA (IE, for once, leading the pack in a standard alongside Firefox, Dijit leading the way in libraries - though several major JS libraries were surprisingly good).

This was a great event, in spite of the pillar, and I've just skipped over a lot of it (we overran by more than an hour :) ) so 5 out of 5. Watch the website for news of future events in the series or follow #standardsnext on Twitter.

Technorati tags for this review:      

Tweet this!
3 feedbacks »PermalinkPermalink