RE: The two models of accessibility

If it is just waffle then we are both in trouble as I agree with most (if not 
all) of what you are saying. <grin>

I came across this article 
www.macromedia.com/macromedia/accessibility/pub/acc_sites_chap01.pdf  yesterday 
from Shawn Lawton Henry, referenced from here 
http://lists.w3.org/Archives/Public/w3c-wai-eo/2003JanMar/0032.html (please 
note the comments at the end about the pdf thing).

It seems to be talking about the same issue(s) again from a slightly different 
perspective.

I got the link to the BBCi accessibility study from the newsletter from the 
RNIB that I find really good.

Cheers
Graham


On Thursday, April 03, 2003 10:00 PM, Isofarro 
[SMTP:w3evangelism@faqportal.uklinux.net] wrote:
> Graham,
>
> (Firstly, thanks for the links to the BBCi accessibility study - they will
> come in handy for me trying to write a web development guide)
>
>
> > If I can try to restate to gain clarification you are saying that
> accessibility
> > is basically a 2 step process.
>
> There are two "actions" involved, but I'm not sure whether there is a worthy
> checkpoint at the end of the first "step" (the automated check). Is a
> website accessible if it passes a AccessValet/Bobby/CynthiaSays test? I
> don't think we can meaningfully separate the two actions and provide a
> halfway point. I would rather suggest doing both steps simultaneously, since
> there's nothing to be gained by separating them out.
>
> Lets take an often seen example (HTML 4):
> <img src="image15.gif" height="100" width="75" alt="image15.gif">
>
> This would pass an automated check since there is an alt attribute and it
> contains alternative text. Is it accessible though? I would say no, purely
> because the alt text does not provide an alternative textual representation
> of the image (unless the graphic that displays the words image15.gif).
>
> > 1. Check with the automated tools.
> > 2. Check (by an accessibility expert) those things that can't be checked
> with
> > the automated tools.
>
> May I make a suggestion (sorry to nit-pick) - that we replace the term
> "accessibility expert" (in this context) with the term "human being" or "web
> author" or "web designer". I'm no accessibility expert, although there are
> many people on this mailing list that can claim this, yet following a WCAG
> checklist and understanding the guidelines does not require an accessibility
> expert.
>
> This does not mean that there is no place for an accessibility expert, since
> they provide a very useful and important role - they build on the WCAG both
> by pointing out its deficiencies, and offering alternative solutions. I see
> the WCAG as an understanding of accessibility issues and best practice so
> far. I fully expect it to be a living document that grows along with our
> understanding of accessibility issues. As new ideas are generated,
> challenged and proven, they are added to the WCAG. That's the vital role for
> accessibility experts - to see beyond the WCAG, address its weaknesses.
>
> > then usability is built upon that base.
>
> Usability can be built on any base - accessible or inaccessible. I'd like to
> believe that accessibility makes usability changes easier.
>
> > I guess that we are back to definitions again.
> >
> > I would class 1 and 2 together to mean 'Technically Accessible' although I
> > understand that I would probably be in a minority here. Most people would
> > probably class those as 'Accessible'
>
> I would classify the above as being "Generally Accessible according to
> WCAG", with the relevant A, AA, or AAA conformance. It may not be fully
> accessible, this is where an accessibility expert certainly helps - when you
> need accessibility above and beyond WCAG.
>
> You have a valuable point that is important to make, and needs to be made as
> often and as loudly as possible. Passing an automated accessibility checker
> does not guarantee that a website is accessible. The automation is there to
> reduce the human effort required to check accessibility issues against WCAG.
> Its a complements human effort, but does not fully replace.
>
> Usability builds onto a website, whether it is accessible or not (as Lois
> Wakeman's analogy neatly captures).
>
> I guess the quirk we face is the "embrace and extend" of usability experts
> in leveraging accessibility for their intended purposes - this is beneficial
> for visitors with disabilities, since they are looking at devices in use by
> people with disabilities (for example Nielsen's "Beyond ALT Text"). I fully
> believe in catering for all audiences with accessible content, but not just
> the disabled. I'd like to think that "structure- and semantic-aware client
> tools" are part of the group benefitting from accessibility - that can
> automate many of the dull repetitive web tasks we seem to manually labour
> through each and every day (catch up on daily reads such as news/blogs,
> check a web-based mail service, evaluate the results of a search).
>
> With usability, then, we need to make sure that it doesn't come at the cost
> of accessibility, but as a complement of accessibility. I'm not sure that
> there's a consistent logical progression from accessibility to usability. At
> some stage we'll probably hit a trade-off decision - usability or
> accessibility. Which factor takes preference is probably largely dependant
> on the situation.
>
> (I'm in two minds in sending this, if it is just waffle like one part of my
> brain tells me, my apologies).
> Mike
>

Received on Thursday, 3 April 2003 16:40:00 UTC