KuraFire Network

When I registered for SXSW 2006, back in October 2005, I planned on attending a lot of good panels and meeting up with a bunch of people I have been chatting with regularly over the 'Net. What I didn't expect was ending up as a nominee for the SXSW Web Awards, team captain for The Avalonstar Bowling Extravaganza and panelist on Web 2.1: Making Web 2.0 Accessible. A report on the experience.

In the weeks before SXSW, my panel moderator James Craig got us all to talk with each other about the subject, get the discussion going in preparation of the panel. This was all done by e-mail, as the panel members live very far apart.

During SXSW's first few days, we gathered together to meet in person and discuss everything some more. We worked on James' slides together, figured out which bits to incorporate in our dialogue, which to scrap. On Sunday morning we had the Knowbility breakfast; Knowbility is the organization that put the Accessibility-related panels together. They organize a breakfast for all panelists on Sunday morning and it gave me a chance to meet the people on the other panel, which was a great experience.

The afternoon came, we prepared ourselves in the green room and then it was time to head to room 17AB for the panel session. A lovely staff lady escorted us through a network of hallways behind all the rooms, and as we entered, we (or at least, I) were amazed at how packed the room was. This was a panel on Accessibility and the room was packed! It was a great surprise, and for me it was especially reassuring to see so very many familiar faces in the audience. Perhaps almost everybody I knew that was at the conference was in the room, it was unbelievable.

James had us all introduce ourselves, and to get rid of my nervousness I threw a few jokes in mine. It worked, because right after that I felt completely at ease and it was smooth sailing for the rest of the session. Perhaps a bit too smooth, because we ended up discussing our material in great length and detail, spending the full 60 minutes on doing so and leaving only a meager 5 minutes of overtime for questions.

Part of why we ran short of time is that the entire audience seemed captivated from start to finish; we were talking to roughly 350 highly interested, focused people that were almost holding their breaths. It just spurred us on to be met with so much focus, even though we really should have been more succinct when discussing the various issues.

A lot of time was spent in the beginning explaining the overall outline of WCAG, ATAG and UAAG, respectively the Web Content Accessibility Guidelines, Authoring Tool Accessibility Guidelines and User Agent Accessibility Guidelines. Shawn Henry of the W3C told us not to read the WCAG 2.0, but instead read the document Understanding WCAG 2.0. This raised some eyebrows - when was the last time you heard someone from the W3C explicitly say you should not read their recommendations? - but it makes sense when you take into consideration the fact that WCAG 2.0 is made mostly for testing purposes.

Web Accessibility in general is still very much intangible and therefore difficult to grasp to many; to combat this, the W3C is working on making more testable guidelines. If you can clearly test your pages against certain goals, the principles of Accessibility become a lot more tangible. However, as a result (or maybe side effect?) the WCAG 2.0 itself is extremely convoluted and almost impossibly difficult to read and understand. Hence Shawn's comment on not trying to plow your way through WCAG 2.0 itself, but instead reading the supportive document that will help you understand what it's for.

ATAG and UAAG are guidelines that matter less to web publishers and more to those who provide the tools for web publishers. The Authoring Tool Accessibility Guidelines present a lot of information on how accessibility works in regards to authoring tools such as Dreamweaver, but a very important detail is that authoring tools are not limited to Dreamweaver-equivalents! Microsoft Word, Outlook, online services such as Basecamp, Flickr, blog software and CMS's… all these are authoring tools as well, and accessibility concerns apply to them just as much as they do to Dreamweaver (perhaps even more so, because most of these tools that people don't immediately think of as Authoring Tools tend to run behind quite a bit).

The User Agent Accessibility Guidelines provide invaluable guidelines to browser makers of any kind. This includes all mobile browsers, text browsers and Assistive Technologies' creators (such as the people behind screenreaders). While they are not intended for web developers, it doesn't actually hurt to go through them if you wish to get a deeper, more thorough understanding of how accessibility on the web works, on the user end.

Testing and breaking the rules

One of the major messages from the panel was testing: test, test, and then test some more. Test till you drop. Shawn even went so far as to pull her earlier statement and go even further: Don't read WCAG 2.0 and don't read the supportive document either - just test your sites as much and as best you can! Derek had an insightful experience to share with us: he recently hired a blind person to help them with testing for accessibility. Within the company, they use Basecamp for project management, but this new employee was having the most excrutiatingly difficult time using the application. What became clear as day in mere minutes was that 37signal's product was only ever tested by people who could see just fine, and not once by a blind user.

A very important thing to note here is why testing is really so much more important than following the rules to the letter: when testing a site or application with a blind user (for instance), you will get a much clearer idea of what the pitfalls are, where they are, and why they are there. This will provide you with enough data to solve the problem. Checking off items in a checklist does not and probably never will ensure that your site or application is accessible to all users. Websites and applications are so unique in build and nature that generic testing is insufficient to ensure real accessibility.

Besides, why shouldn't we break the rules? We may be here fighting for the greater adoption of web standards, but in some cases it makes sense to break the rules. We would all not have been here today if we had only ever adopted XHTML with the correct MIME-type, or if we would only ever have used the CSS Float property for floating images within our content. Us Standardistas have broken many rules to spread web standards awareness, but we've done so for the greater good. We've done so for the bigger picture, and it has been a big success. If we would have stuck to the rules and refused to abuse Floats for layouts, CSS would never have been picked up as widely as it has.

So don't be afraid to break the rules; worry less about following WCAG 1 and/or 2 to the letter, and spend that time and energy instead on testing your sites. Don't have "access to a blind person"? (that sounded horribly wrong, and I apologize) Just get a screenreader and turn off your monitor. Test as much and as best as you can, and you'll have much better results than those who purely play it by the book.

Bookmark: Newsvine del.icio.us Digg