Simple accessibility heuristics for UX walkthroughs

[Michael S Elledge]

Hi Colin--

Sounds like a great idea! It might be interesting to leave it up to 
reviewers how deep they want to go into the Phase 2 items once we 
identify them. Some people may want to try out the browser-based tools 
in addition to the more general UX items, which would be fine by me. :-)

BTW, I apologize for not being on the conference call this afternoon; I 
had to run a focus group.

Mike

Colin Clark wrote:
> 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
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070913/03e8ea43/attachment.vcf>