Simple accessibility heuristics for UX walkthroughs
daphne at media.berkeley.edu
Fri Sep 7 17:46:18 UTC 2007
One comment below...
On Sep 7, 2007, at 10:21 AM, Colin Clark wrote:
> Hi Mike,
> This is a good point as well.
> My goal is to make this process super-simple and not impose much in
> way of technical knowledge. Do you think the accessibility browser
> are suitable for someone who might not know much about HTML?
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?
> 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
> 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
>> accessibility coding, it certainly takes us a step closer to its
>> implementation. I'd also add a comment about ensuring that link
>> 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-
>> 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.
>> 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
>>> 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)
>>> 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:
>>>> 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?
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work