Entries Tagged 'accessibility' ↓

A few weeks ago I had the privilege of presenting (virtually) to the New Zealand ColdFusion User Group on CSS and web standards. David Harris runs the meetings with both physical attendees in Auckland and virtual attendees through Adobe Connect.

The recording of that presentation (with slides) is now available. It sounds a little scratchy, unfortunately - no doubt a combination of my not-great headset and the extreme distance. The presentation covers how, as a ColdFusion developer, I came to be involved in web standards, what the term actually means, why I think they are important and why I think web standards could be more of interest to back end developers then they perhaps realise. I also include a couple of basic examples.

Web Standards for Developers - Adobe Connect presentation recording

My Web Directions 2006 experience started on Thursday with a workshop: Accessibility 2.0 with the inimitable Derek Featherstone.

Derek used to be a high school teacher and I think he must have been a good one - he holds the attention of the audience very well and makes accessibility interesting, even to the fully-sighted, mouse-wielding power users that most web developers are.

Why Accessibility 2.0?

The web 2.0 phenomenon has led to a massive increase in smart and sexy web applications that use Ajax to provide a slick, responsive interface - the functional web rather than the traditional, document-based web. But as with all things, just because you can doesn’t necessarily mean you should, and in some cases accessibility is falling by the wayside. Fortunately, there are ways to make web applications available to users of assistive technology such a screen readers, voice recognition software and alternate input mechanisms. For the workshop, Derek focused on a number of common problems in web applications using real-world examples, and then showed some techniques to provide the same functionality in an accessible way.

The Accessibility/Usability Cross-over

The first topic covered in the workshop was the cross-over that exists between accessibility and usability. Many accessibility issues could also be called usability problems, and vice versa. Often, fixing an obvious accessibility problem also improves the usability of an application for all users.

An interesting and unexpected point Derek raised was that in certain cases, creating an alternate version of a particular feature of an application specifically for users of assistive technology is the only way to provide a great experience for all users.

A web standards approach facilitates accessible applications

While it’s not a magic bullet, using valid code and separation of markup, presentation and behaviour (the dubious-sounding “three-legged stool” of web standards) goes a long way towards facilitating accessible applications, and the same thing can be said for usability. At the very least, web standards provide a solid foundation with which work from. Of course, being a web standards-focused audience, this didn’t surprise anyone, but it’s a nice affirmation.

Myths about screenreaders

Many web developers believe that providing a version of an application that works without JavaScript equates to providing an accessible version. This is simply not true - screenreaders work with modern browsers - Internet Explorer and Firefox, primarily - and they are able to access content provided by JavaScript. Derek demonstrated a common Ajax technique for providing form validation, and the screenreader read out the validation messages.

Simple problems with simple solutions

Most of the examples presented in the workshop were simple problems with simple solutions, but pointed to what would become the mantra of the session: proper user testing with assistive technologies is critical to making an application accessible. Real people do things that no web developer will ever anticipate.

The Hijax technique was briefly discussed - and I learnt more about this on Friday at Jeremy Keith’s session. Essentially, it means first making a regular application which functions without JavaScript, then using progressive ehancement techniques to add a behaviour layer to “hijack” standard links, form submissions etc at particular points and substitute Ajax functionality. If an application used this approach from the beginning, the task of ensuring it was accessible would be a lot simpler.

Some of the examples covered:

• Forms for tables
  • Problem: screenreader has problems associating labels with inputs
  • Solution: add semantic labels, drop the tables, user correct source order then absolute positioning to adjust the visual layout

• Changing elements using JavaScript
  • Problem: a form input area had default text which was cleared when the input received focus, but when focus was removed and then returned to the element, the user-entered text was also cleared
  • Solution: only clear input if default text is detected

• Voice recognition and alt attributes
  • Problem: voice recognition software couldn’t activate a menu image link where the alt text was different from the visual representation of the word
  • Solution: Make the alt text match the image

• Non-semantic elements
  • Problem: keyboard navigation between links not working in Google maps
  • Solution: using a proper anchor element rather than a styled span with an onClick handler

• Using colour to indicate change
  • Problem: Basecamp-style colour flashes inaccessible to visually impaired and users simply not paying attention at the exact moment they occur
  • Solution: rather than relying on the colour change, also change some text or use some other permanent visual marker.

More complex Ajax problems

Not all accessibility problems posed by web applications are so easily fixed. A major issue is how to make sure that when the contents of the page is changed using JavaScript (the basis of most Ajax apps), screenreaders and other assistive technologies are aware of the change.

Derek ran through a few examples using Basecamp lists and a form validation sample, but the results were not consistent - essentially, the only way to know for sure if an application is truly accessible is to test it with assistive browsers. If a particular technique doesn’t work, try another - there’s plenty to choose from!

Finally, Derek ran through an inaccessible, complex multi-step form and discussed areas that he was changing to make it accessible.

Now go away and do this…

I wrote four notes at the end of the session:

• Planning
  • Plan for accessibility at the beginning of the process, rather than at the end

• Do the simple stuff right
  • Layout forms correctly, validate html and markup

• Semantic interaction
  • Use the right elements for the job - e.g. links should be anchors

• Provide “options”
  • Accessibility has the potential to help all users
• And always test test test

Derek’s workshop was informative and entertaining - it’s always a real privilege to listen to him speak. I learnt lots and have heaps of tips I can start using in my work right away.

I was thinking of asking Nick to do a little interview about his upcoming Web Standards Group presentation…

…but he’s posted up such a good overview on his own blog that I’ll just point everyone over there: Accessible forms and more.

Nick explains his background as such:

Before I started building web sites for a living, I was a policy officer with the then Ministry of Fair Trading and I spent a lot of time working with legislation.

The first time I read that sentence, I thought it said “I was a police officer”… I was trying to imagine Nick in uniform. Not an image that really fits!

That aside, Nick’s presentation should be great, I’m really looking forward to it. Just a reminder, the details are:

Web Standards Group Meeting, Perth
Thursday August 31, 2006 - from 6pm
Edith Cowan University, Mt Lawley Tavern (Building 12)
Cover charge of $4 for nibblies and audio transcription

Please RSVP to perth@webstandardsgroup.org if you’re planning to come along.

Rightio kids, it’s that time again… this time, WSG favourite Nick Cowie is back by popular demand, to talk about accessible forms.

The date will be the 31st of August and the venue will once again be the ECU tavern at Mt Lawley.

Full details are available on the Web Standards Group web site. If you are planning on attending please email your intention to perth@webstandardsgroup.org so we know how many people to arrange nibblies for.

The last two Perth meetings have been very informative AND a lot of fun - hope to see you there!

There’s a very cool thing going on in some cities in the US that seems to be a lot like Port80 and the Web Standards Group combined.

Refreshing Cities says that:

Refresh is a community of designers and developers working to refresh the creative, technical, and professional culture of New Media endeavors in their areas. Promoting design, technology, usability, and standards.

Sounds like an admirable goal to me. Refresh Orlando are having a conference - Refresh06 - and so far they have a pretty good speaker line up: Paul Boag, Andy Budd, Jeremy Keith and Cameron Moll, amongst others.

My conference budget this year is going on Web Directions, but if you’re in the U.S. of A then you might wanna check it out.