Simple accessibility heuristics for UX walkthroughs

Colin Clark colin.clark at utoronto.ca
Thu Sep 13 18:54:11 UTC 2007


Hi Mike and everyone else,

Sorry for the delay in responding. It's good to know that you think 
these browser-based accessibility evaluation tools will be useful for 
more in-depth assessments of site accessibility without requiring a lot 
of HTML knowledge.

On the other hand, to bring this back to the original topic, my goal 
with the simple accessibility walkthrough procedure was to capture an 
approachable set of steps that anyone can use to identify some prominent 
accessibility issues. The idea is to make it easy to recognize issues at 
a certain level of abstraction appropriate for identifying possible new 
Fluid components.

http://wiki.fluidproject.org/display/fluid/Accessibility+UX+Walkthrough+Group

I think using browser-based tools, under the covers checks, and testing 
with assistive technologies will be critical as we start digging into 
specific areas of uPortal and Sakai and building components. Perhaps 
after the summit we can work on a "Phase 2"-type of procedure for this 
type of testing based on synthesizing all the materials we've already 
collected in the walkthrough area of the wiki and in your Sakai QA 
procedure.

What do you think?

Colin

Michael S Elledge wrote:
> Hi Colin (and Everyone)--
> 
> One of the great things about the browser tools is that you don't need 
> to know html to use them. If there aren't headings (i.e., headers in 
> html-speak) it will say "no headings present." If there are, it lists 
> them with where they fit in the hierarchy. Similarly, it shows a list of 
> link phrases, a list of alt tags, etc., so the reviewer can look at a 
> page, check a couple of items, and then fill in a form that says what's 
> there or missing without ever looking at code. I've attached a short 
> form we use for Sakai that covers these items and what a reviewer should 
> find:
> 
> *Links
> *Headings
> *Accesskeys
> *Frame Titles
> *Tab Order
> *Functionality
> *Style Sheets/Linearization
> *Text Zoom
> *WAVE Results
> *W3C Validation
> 
> It doesn't take much time and it's a nice complement to a visual review. 
> Some things, like reviewing a document with CSS off (stylesheets) and 
> using an evaluator like WAVE, could be left off the visual list and left 
> to the access expert so not to overload the ux reviewer.
> 
> So, here's a powerpoint page that shows what's in the VisionAustralia 
> AIS toolbar. Not that we would ask our reviewers to use all its 
> elements, but as an example of how helpful this kind of tool can be.
> 
> Mike
> 
> Colin Clark wrote:
>> Hi all,
>>
>> Daphne Ogle wrote:
>>> I wonder if we can make an assumption that the folks doing this 
>>> evaluation have at least a basic knowledge of HTML?  I don't want to 
>>> make this assumption for everyone but I know for me, as much I'd 
>>> prefer not to write code, I can make my way through HTML just fine 
>>> :)  Thoughts?
>>
>> Yes, this is a good question to bring up with the community.
>>
>> One other motivation I didn't mention for leaving HTML out at this 
>> stage: so far, we have found in our preliminary walkthroughs that we 
>> were able to identify a large number of accessibility issues that were 
>> at a higher-level. More conceptual problems, if you will.
>>
>> So one advantage to not looking too far under the covers is that you 
>> stay within the level of abstraction that helps to identify 
>> large-scale issues and components. Once we choose to delve into 
>> specific problems, then a careful look at markup and detailed issues 
>> will be critical.
>>
>> Thoughts?
>>
>> Colin
>>

-- 
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org



More information about the fluid-work mailing list