E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Terence de Giere
Date: Thu, Sep 11 2003 12:46PM
Subject: Re: Finding WCAG approved sites
No previous message | No next message

I did some searching for WAI icons using filenames on various search
engines, and it did not turn up much. Searching for text brought up more
results, but it sure does not seem a very efficient way to find
anything. CAST used to have site with a database of Bobby Approved
sites, but when you checked those sites with Bobby, most of them failed.

Jukka Korpela has a lot of good points. Accessibility seems like a work
in progress. Besides making a site accessible, maintaining that
accessibility on the site can be challenge, especially if others are
updating the site. My wife has a site. In the beginning all guidelines
that Bobby could check were passed, so for the automated part of the
test the site had a WCAG Triple-A pass. Then manual checking was done to
the Double-A level, including separate tests for HTML validation etc.
The site was given a Level Double-A rating. My wife however is not that
much into accessibility, although she has at least one blind user she
knows who comes to the site. Over time however as the site has been
updated, sometimes with links pasted in from other sites. There is a
deterioration of accessibility I have observed over time. Further if
one checks the site with some other tools, it fails to pass any
accessibility test, at least if one goes solely with automated results.
So at best I find the site, on average, would comply with Level-A.
Further, the design of the site could use a big overhaul, to improve
accessibility and usability. As sites age, the patches to the navigation
system and general organization of the site to add new sections or
features tend to erode the initial plan, and the site gets more incoherent.

In every project involving accessibility I have worked on , involving
designers, programmers usability specialists, I have observed a
deterioration in the quality of the accessibility as defined in the site
specifications versus the actual site that went online. With so many
working on the site, and having different levels of skill and
accessibility knowledge, this seems inevitable. Tools certainly help,
but it seems like a losing battle to meet every guideline on every page,
unless really intense manual focus can be applied for every item on
every page when it is designed, and whenever it is updated.

I have put accessibility icons on pages, but after reviewing my own
work, Jukka's comments, and seeing a certain hopelessness in reviewing
sites that are supposed to be accessible, I now think that the icons, if
used, perhaps should only go on an 'about this site' page, as an
indication of the intent of the site to be accessible. The W3C text for
their accessibility icons is technospeak. I tired this for alternate
text for one of their icons: "Accessible web site icon: Claim of
conformance to W3C Level Triple-A accessibility guidelines." After all
the W3C does not verify the claim, different tools will pass or fail the
same pages, and there is some disagreement on some guidelines as what
constitutes a pass. If one wants to prove a page is compliant, there is
no fully agreed upon consistent method to prove it. And it would take a
lot longer to approve a page by committee than for a competent tester to
work over the page to make it basically accessible.

Jukka's notes point out a number of failings. When I got Bobby 5.0, it
failed pages that passed with Bobby 4.0, but a manual check of the
problem did not find any errors. Rather Bobby 5.0 was fooled by some
structures in the page that prevented it from parsing the code properly
and it reported errors where there were none - it was a bug. Other
checkers on the same page found other problems not found by Bobby. Tools
have very definite limitations. At best they can help maintain a certain
level of accessibility, but that level of accessibility is lower than
the tools seem to determine. At this point it seems inevitable that not
all accessibility problems can be eliminated by the use of tools.

A Jukka pointed out, lack of support for accessibility coding in
browsers is a factor in the problem. From a standards point of view, I
suppose we could say a non compliant user agent that does not interpret
the guidelines properly is the user's own problem. Certainly we cannot
compensate for every browser deficiency, but there are some that are
pervasive, such as Internet Explorer's lack of support for 'Q' for
inline quotations will affect most users on the Internet. IE 6.0 can
format 'Q' somewhat using CSS but does not put in the quotation marks as
required by the HTML specification, and it does not support appending
text via CSS either.

So one needs to make a choice whether to use a more backward
construction, just putting in quotation marks and not marking up the
quotation, or go with the standards and confuse Internet Explorer users,
and almost anyone with an older browser. If you go with the former, the
page is more usable for most users, and for older technology generally,
but will fail a W3C Double-A compliance, while the latter will benefit a
fewer number of users although it is technically 'more accessible' if
compliant user agents are used. It is generally not a good idea to
pander to individual browsers when making accessible pages. But because
browsers, just like HTML specifications evolve over time, each and every
component of the accessibility equation - authoring software, browser
software, testing software, and the developer's knowledge are not all on
the same level, so a conservative approach to coding is needed if we
want to make the most generally accessible pages.

If we put in a large number of metatag navigation links in the head of
the page, these will be fine for recent Opera and recent Mozilla
browsers, but be invisible in IE, and in Lynx, they may fill the fisrt
screen completely, without being visually organized. In an older audio
browser they will be spoken out rapidly without any identifying
information as to what they are for. So following guidelines can lead to
accessibility problems for some normal and special access technology.
Just as including cutting edge technology in web pages leaves many users
without the means to read all the content in a page, cutting edge
accessibility coding sometimes also results in similar problems. The
hope is these older versions of software will die soon, and be replaced
by more compliant versions, at which time, a fuller implementation of
accessibility coding can be more productive. The W3C accessibility
guidelines are a set of three: for content, for authoring tools, and for
user agents, and they need to work together to get the desired result.
Right now graphical authoring tools and user agents are a bit behind the
ability of a skilled developer using text based editors to implement the
content guidelines.

I have toyed with the ida of creating a simple icon that says
'Accessible Web Page' but does not specify any particular measurable
level of accessibility. It would be a link that goes to the 'about this
site' page that then explains in more detail about the accessibility of
the site, but maybe that is a pointless idea. An accessibility
conformance icon is not like getting an Academy Award for a job well
done, it's not like peer review, it is a claim we make, but not a proof
of that claim. If you want to find accessible sites, look first to those
that belong to accessibility specialists, then look at government sites
in the US, Britain, Australia and Canada and see what you can find.
Because Canada aims for Level Double-A or close to that, it might be the
best government site as far as accessibility. As for commerical sites,
there seem to be very few that would be compliant.

I just came across the following link on another forum - some useful
tabulation of support for various accessibility coding constructs
comparing Window-Eyes, JAWS, and IBM HPR:
http://www.camo.qc.ca/ntic/csun2002en.htm

Terence de Giere
= EMAIL ADDRESS REMOVED =




----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/