Simple accessibility heuristics for UX walkthroughs

Michael S Elledge elledge at
Fri Sep 7 19:59:47 UTC 2007

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 

*Frame Titles
*Tab Order
*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.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AIS Web Accessibility Toolbar.ppt
Type: application/
Size: 37888 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sakai_Sample_Test_Template.xls
Type: application/
Size: 20480 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <>

More information about the fluid-work mailing list