Simple accessibility heuristics for UX walkthroughs

Barbara Glover barbara.glover at
Fri Sep 7 21:08:02 UTC 2007

There's a book i got in our ATRC accessibility centre that has a  
chapter on testing for Accessibility.  The book itself looks very  
thorough though aimed more at a Dev audience than UE.  Title "Web  
Accessibility: Web Standards and Regulatory Compliance".

I'm in the process of reading it and will post anything of interest  
if applicable for our UX walk-throughs.

On 7-Sep-07, at 3:59 PM, 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
>> <AIS Web Accessibility Toolbar.ppt>
>> <Sakai_Sample_Test_Template.xls>
>> <elledge.vcf>
> _______________________________________________
> fluid-work mailing list
> fluid-work at

More information about the fluid-work mailing list