Two workshops today at the Future of Web Design conference: Real-World Accessibility for Web Designers with Derek Featherstone and Design Secrets of Digg with Daniel Burkha. It was tough to narrow down to these two - all of the sessions looked great - but I chose these for important reasons. [I’ll be adding more about Daniel’s talk in the next day or two - it’s too much to cover now!]
Accessibility is hugely important, and something I’ve tried to be aware of in my design and development of sites for a few years now. It’s impact on general usability is profound and there will be ever-increasing numbers of users on the web with real need for assistive technology and design as use of the web becomes ever more pervasive in everyday life. Making this a part of your thinking as a designer should never be an option. By pitching it as such we continue to leave the door open for clients to say ‘that’s not our market’ when you bring up compliance - even though it can easily be proven to not be the case.
More than that - good, accessible design is better for SEO, better for mobile, and in general better for almost every user, regardless of their mode of access. Particularly as Mac users, many designers are not as used to keyboard shortcuts as many PC users - so by not affording their use in our design we create unnecessary obstacles for more users than we realize.
I have to say that at first I was a little put off by Derek’s focus on AJAX and it’s usefulness in web apps. But allowing for the fact that this presentation was originally titled ‘Real-World Accessibility for Web Apps’ (or something close) it’s to be expected. My initial impressions notwithstanding - this guy was SUPER knowledgeable. Speaking with him a bit afterwards he related that he was pleased that most people seemed to understand the basics, so he was able to dive in to some really great stuff.
First - defining who accessibility is for. It’s not just screen readers - it’s users with low vision capability, so contrast and size are crucial; and users with motor control issues, so size, hit size of links, and general ‘trickiness’ of menu systems that pose the biggest challenges. Keyboard shortcuts are vital here as well. The biggest early point about AJAX for me was about context. The best thing about AJAX is that you can keep users in the context of their current task, avoiding jarring jumps and discontinuity in the mental model. If a user wants to create a new invoice but hasn’t entered the new client’s details yet, let them do so during the task they started, i.e. creating an invoice, without forcing them to jump to another page, enter details and start the invoice process over again.
With regard to approach - Derek’s advice is at its heart simple and pragmatic: cover the basics. Start with clean, semantic markup that makes sense. Think about the order in which the design flows, not just how it looks. Get the use flow right in the markup, get the visual flow in the CSS. Add the advanced behavior to enhance further in the JS. Nail the first step and you’ll be most of the way there for keyboard access. Factor in some smart nesting of tags to allow screen reading to flow and then shift position around with CSS to wrap it up for cleaner visual presentation. Very smart, simple steps that taken together are relatively easy to add to your normal workflow but improve usability for all in every way.
Here’s a gem: make sure you put alerts/error messages/status updates right in/around where the errors are. Don’t make users look behind them for a warning. Putting error and status messages at the top of the page may (sort of) make sense for a sighted user, but it’s really better for everyone to have it appear right in line with the ‘offending’ element. This way the screen reader user gets the message right where the error is, not 40 tabs away (and often ‘behind’).
Another: how do you manage linear flow of an application when that flow changes or branches? Heading tags. Screen reader users can automatically tab to headings on the page, so if you have used proper semantic markup then you likely already have the main anchor points of the page identified and findable.
Testing: early and often! Prototype with real HTML and get the basics: semantics, structure, color/contrast, tab order. As design develops, skip spending the money on a screen reader. Pay a few users who actually live with them to test the design and get their feedback. Much more useful, and at a more helpful point in the design cycle.
Get it right and make it a requirement of good design. Don’t just meet the letter of the spec - deliver the expectation of a good user experience solution for ALL your users. It’s important all the way around.
[Author’s note: there’s a lot more to say on the topic - Derek’s presentation was a well-used 4 hours - but I hope this serves as a good introduction to the topics he covered and that some readers might add their own commentary. When his slide presentation becomes available I’ll link to it here.]
References: check out http://www.wat-c.org/ to find some great testing tools. Also my own recommendation is this article on prototyping in XHTML as a good basis to start with good solid semantic markup: http://www.boxesandarrows.com/view/prototyping-with