W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2003

Re: Accessible Development Methodologies: Comments Requested

From: David Woolley <david@djwhome.demon.co.uk>
Date: Tue, 22 Jul 2003 09:27:09 +0100 (BST)
Message-Id: <200307220827.h6M8R9X01292@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> What? that's like trying to say that all web sites should be in one

That is unrealistic (although their structure can and should be in 
a single language).

> language - not in our lifetime.  Whether written in text, icons, both,
> hieroglyphics, or whatever it will never happen - why would we ever try to
> create a set of universal icons for Web sites?  I can barely understand the

To allow those who cannot read conventional languages, or can't read them
well to be able to use more than one site.

> difference between icons used in Austin, Texas and Boston Massachusetts -
> never mind the differences between the U.K. Tokyo, Baghdad, or Monrovia...

This seems to be an argument for the use of the abstractions involved in
conventional languages, which is OK for me, but the original requirement
was to assist people who are unable to cope with those abstractions.

As it happens, I use very very few of the icons on a typical computer
application, and those are mainly the ones that have become almost
universal (although they also involve abstractions that possibly defeat
their purpose in the current context, e.g. how many people use floppy disks
these days, so could guess the maining of a floppy disk icon).

If everyone invents their own icons, you will get even worse fragmentation
of the web than you do with conventional writing systems.

It may be that the red bus syndrome means that people with poor language
skills may be locked into small geographic regions, but those regions can
still be much larger than a single web site, which is what you will get
if everyone tries to design their own icon sets.

There is actually a fundamental conflict here in that by increasing the
accessibility to people with a very poor ability to handle abstractions,
you are reducing the accessibility to people in other parts of the world,
or even of the country, who could remember a standard icon, but cannot
generalise an extremely localised one (and I suspect that that extends
to the majority of users once you get off very concrete concepts).
In giving access to one group, you may be denying access to the other;
I'm assuming that simultaneously using localised low abstraction icons,
universal, high abstraction icons, and conventional orthographies is going
to be confusing (and unacceptable to the visual designers) in itself.

If you cannot have universal icons, you cannot have a world wide web for
those who can only understand visual language at that level.

The only way I can see of having a world wide web and highly localised
icons is by not transmitting the icons at all, but marking up the
text with enough information to allow the user agent to select an
appropriate icon.  With current HTML, that would mean the use of
agreed class names++, which should be abstractions, not "red-bus", but
"public-transport" (or whatever narrower classification was intended).
(Unfortunately the chances of getting the average commercial or amateur
author to do this are negligible, based on their inability to validly
structure the current language - the chances of getting them to include
images of standardised icons is marginally greater.)

(A composer intended for people who need icons for comprehension, might
present a user interface in terms of their localised icons, but output
the meaning as the class name;  someone will need to tell the tool 
how to map the icons to the standard language, but if they can't, you
don't really have a useful set of icons (except possibly for a 
very small group that have met directly and formed a concensus on their
meaning), but rather just decorations, as many "icons" on commercial 
sites really are.)

++ One could also use Universal Resource Names on images, but, in my 
view, that would be based on misusing HTML as a page description 
Received on Tuesday, 22 July 2003 08:01:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:25 UTC