Simple accessibility heuristics for UX walkthroughs
barbara.glover at utoronto.ca
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:
> *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.
>> <AIS Web Accessibility Toolbar.ppt>
> fluid-work mailing list
> fluid-work at fluidproject.org
More information about the fluid-work