W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > August 1998

Evaluating a problem site and reporting a fault

From: Stella O'Brien <smo-brien@lioness.demon.co.uk>
Date: Tue, 18 Aug 1998 18:24:37 +0000
Message-Id: <l03130305b1ff55af2809@[]>
To: w3c-wai-er-ig@w3.org
I think that everybody is agreed upon the need for human intervention when
assessing whether or not a site is accessible. There have been recent
examples on webwatch-l and other mailing lists when people reported a
problem (such as missing alt texts), only for other people to check the
site and report that the alt texts were displayed.

Yesterday, a company contacted me because (amongst other problems) some of
its alt texts were not showing up on its website although it had included
them in the source. The html had passed an html validation check and Bobby.

The problem was that the background was black: although the author had
specified a link colour of "white", he had not thought to specify a colour
for other text, or for the vlinks - so the alt text was displayed in the
default colour and could not show up against that background. I think it is
understandable that Bobby did not catch this particular glitch (or the
others on that site). This proved to be quite a straightforward problem,
but it was tricky to find because of the presentation of the source code,
and because the webmaster thought that it would be a Javascript snarl up.
(Estimated time for finding and repair, 1 hour.)

A common problem is when graphics loading is turned off in a graphical
browser, but it is not possible to read an alt text because the height and
width attributes of the image placeholder have been specified (the alt text
it is clearly present in the source).

Both of these are valid criticisms; but it is easy to misinterpret them,
and to complain about the wrong thing, i.e., that there are no alt texts.
Running an automated tool would show that their perceived absence is not
the problem but it might be difficult to generate appropriate pointers as
to what the problems could be (particularly when both of the above examples
are only problematic for graphical browsers with their graphics loading
turned off - it can be more complicated than this, but the detail would not
be helpful here).

Harvey Bingham wrote on 10th August
>The subjective reactions by the reporter may indeed be technically wrong,
>even though there was a clear problem worthy of reporting. We'd need
>to evaluate them by a tool like Bobby. If we can see the reporter's point,
>we may learn to improve our tools.

Al Gilman wrote on 11th August,
> If the process is working, figure out how to staff
>the necessary manual review tasks.  We can tap advocacy organizations
>for the latter; they can be trained on the tools and guidelines and
>check for off-the-wall complaints.

This would be an excellent procedure for sorting and filtering. However,
there are times when somebody will need to check out some fairly tricky
source code before they can validate a complaint. Even for an experienced
evaluator this difficulty can be compounded when the use of the html is
less than optimal, and there are various 'kludges' to achieve a particular
effect. Nobody would expect a non-programmer to be able to debug a "C"
program successfully, equipped only with a compiler, and some guidelines.

Depending on the volume of complaints, and the intricacy of the 'offending'
websites, effective diagnosis and evaluation could involve a large number
of hours of work.

Stella O'Brien, KO2
email: smo-brien@lioness.demon.co.uk
Received on Tuesday, 18 August 1998 13:27:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:26 UTC