Simple accessibility heuristics for UX walkthroughs

[Colin Clark]

Hi Mike,

This is a good point as well.

My goal is to make this process super-simple and not impose much in the 
way of technical knowledge. Do you think the accessibility browser tools 
are suitable for someone who might not know much about HTML?

As for the issue of content organization, I completely agree. Do you 
think this fits into #1 on the checklist, or deserves a separate item? 
Any chance that you might be willing to add a little blurb into the 
checklist?

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

Colin

Michael S Elledge wrote:
> Hi Colin--
> 
> I would also add some more specifics about content organization, such as 
> if there are paragraph headings, table captions and section headings in 
> forms. Although their presence doesn't guarantee that there is related 
> accessibility coding, it certainly takes us a step closer to its 
> implementation. I'd also add a comment about ensuring that link phrases 
> make sense on their own, since they are a common means of navigation.
> 
> We may also want to give reviewers the option of using a browser-based 
> tool to look at particular accessibility elements that otherwise are 
> hidden from view, unless you think it would make the us process too 
> lengthy, or intrude on the access expert role.
> 
> See the template and protocol we've used for Sakai: 
> http://confluence.sakaiproject.org/confluence/x/14k as an example.
> 
> Mike
> 
> On Sep 7, 2007, at 11:29 AM, Greg Gay <g.gay at utoronto.ca> wrote:
> 
>> Hi Colin
>> The only thing I might add is a check for text alternatives for graphic
>> content. Usually that means including Alt text with images, but also Alt
>> for image buttons, clientside Map areas, etc, and empty Alt for
>> meaningless or decorative images. Unfortunately it normally means
>> examining HTML, though in IE 6 if one holds a mouse pointer over an
>> image with Alt text, it will display.
>>
>> Missing text alternatives for visual content is the #1 accessibility
>> barrier, and as such is listed in the guidelines as the first
>> requirement for compliance (WCAG 1.0 Guideline 1.1)
>>
>> greg
>>
>> Colin Clark wrote:
>>
>>> Hi everyone,
>>>
>>> I've drafted a page that outlines the simple heuristics I have been
>>> using for the UX walkthroughs while evaluating accessibility:
>>>
>>> http://wiki.fluidproject.org/display/fluid/Accessibility+UX+Walkthrough+Group 
>>>
>>>
>>> To be clear, this is intended as an easy process that anyone can pick up
>>> relatively quickly, even without any expertise in accessibility. It
>>> isn't intended as a substitute for testing with real assistive
>>> technologies, evaluation tools, and an "under the covers" inspection of
>>> the markup.
>>>
>>> On the other hand, they're easy, low cost, and don't require any
>>> substantial technical or accessibility expertise. A perfect fit for
>>> anyone doing a UX walkthrough of Moodle, uPortal, or Sakai.
>>>
>>> Thoughts? Suggestions?
>>>
>>> Colin
>>>
>>>
>>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>

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