notes re RC for IG

Hello

I have been lurking on this list and thinking about how we can move from
comments to constructive action.  I am sure most of you are also often
engaged in such process issues.  In what follows, I try to summarise some
of the issues which I think have arisen recently on this interest group
list, with respect to matters which we hope will be dealt with in more
detail within the "Ratings and Certification Interest Group" activities
over the next few months.

Let me start by saying that one of the problems for this RC group is
definition of its purpose.

Initially and simply, it was started as a working group which hopefully
could identify and use a set of criteria for alerting potential browsing
users of websites, of the accessibility problems they might encounter with
the site they are entering.

For such a set of criteria to be developed, it was necessary first to
discover what makes sites inaccessible.  This is not an absolute
definition, and could never be one, but it was believed that by developing
further and integrating the many sets of guidelines for web authors, we
would end up with an emergent list of inaccessibility features which would
make up the list of criteria.  So the guidelines were to come first.  Of
course, they do not, and we believe cannot, define every user's
accessibility limitations.  At best, the guidelines can, and now do, show a
number of significantly inaccessible features (and point the way to help
web authors avoid them).

Having identified what should be avoided, as best we can and knowing that
this will be an on-going process, we are working on improving the
development of accessible websites on many fronts: technically by trying to
make sure that web editors and browsers are designed to support
accessibility, and trying to influence the development of HTML, XML, CSS,
etc to make it as easy and likely as possible that web content developers
will make accessible sites.  BUT we know that technical solutions only go
so far.

The discussion which raged some time ago about censorship of the web by
positive or 'lazy' action is one in which we should always be engaged.
Policies which threaten people's lives, which render technologies other
than 'convivial' (as Illich trmed it), are not technologies many of us want
and I am sure, from personal experience, not the goal of those who give
their personal time to help with the WAI and othr W3C activities.  But
powerful technologies can always be used for good and bad purposes.  The
point is not what does the software do but how is it used, what policies
are in place to ensure it is used for the benefit of people and society.
And here is where the trouble arises: individual people and societies do
not share common purposes all the time.  So those who wrote to the list
were working on what we must always have at the back of our minds, and as
part of our deliberations: 'Are we working in ways which make the
technology, and here specifically the web, more convivial?'

In recognition of the social and personal dimensions of the WAI activities,
there is an Education and Outreach Activity.  Perhaps there is room for
more 'technology and society' activities.  Such discussion seems to me to
belong on this wide interest group list.  The difference between working to
serve some minority group who are apparently 'begging for access' and what
some of us believe to be all of us, 'those who have a right to a world in
which they can equally participate, no matter what their individual
particular financial, social or physical difefrences might be', is a
political difference.  It is an important issue but it will probably gain
maximum leverage if it is undertaken as a focussed activity, related to how
outreach, eg, is undertaken.  It is part of the wider context in which all
of our work is being done.

I want to suggest that the RC interest group list should not be so much
about the social and political aspects of accessibility as working WITHIN
THAT WIDER CONTEXT on the pragmatic issues of making sites more accessible
when all else has failed (ie when the site has been published but is not
accessible).

The discussion which has taken place on this list, and which I think should
start to move to a more narrow RC interest group list, has been about the
possibility of technical intervention when sites are not designed to offer
maximum accessibility.

The first step has always been assumed to be the mechanical evaluation of a
website by the author.  This assumes that the author has tried, and is
aware of the problem, and is interested.  Technical assistance, such as is
provided by on-line checking process wizards, etc, seem to be one part of
this.  Human evaluation and feedback to the author would be another.  The
RC group has assumed this is one of its briefs and it should try to
discover who offers such tools and services, what features they have which
have proved useful, and what standards might be developed to assist those
offering such services ensure they are as good as possible.  We will be
actively researching this issue in the next few months, trying to make
contact with the relevant communities out there working on these items,
including both the service providers and those who use them or use what is
published by those who use them.

Just as we know there could never be perfect guidelines, we know that there
will never be a perfect technical or human accessibility testing service.
But there will be more and less useful ones according to circumstances.  At
least knowing what is possible, and what is from experience effective,
should help authors who want to make accessible websites.

There is a question which relates to this: is the process of author testing
best associated with the work of the guidelines working group, the user
interface (esp editors) working group, or the RC activity?  The answer
seems to be that it is not an isolated process and it may turn out to be
the same process as the one the user (or a third party) will engage in when
trying to alert others to the accessibility (or otherwise) of a site, or
make a site more accessible than it is already.  So perhaps this process
can stay within the RC area.

But RC activities should also work when the author either has failed to
worry about accessible design or has tried but nevertheless failed to
achieve adequate accessibility.  This is where PICS enters the WAI scene as
a technical solution: it is a platform for conveying information about a
site which does not originate at the site.  Specifically, it conveys
numerical data.  PICS then, can be used to convey information such as that
no images on a site have alt tags.  This is done by sending a number such
as 4 which will be interpreted by the user's browser, after reference to a
third party site which provides the scale, for reference and, in some
cases, the number 4.  The user's browser gets access to this information,
in addition to the data from the particular site, by running PICS, which
sends two messages and handles them according to the preferences on the
user's browser.  These preferences can be set by the user, in the usual
way, and can be used to filter out sites which do not, for instance, have
information in the alt tags.  (Note, the quality of the information might
not be suitable or helpful, even if it is there.)

I believe that PICS will prove to be very useful for offering immediate,
useful information to users, and there will be benefit from us trying to
determine a minimal set of criteria which can be recorded numerically and
encoded for transmission using PICS.  So perhaps there is room for
discussion about what ratings would and could make a difference.  I
anticipate something like this:

An agent is developed by XYZ organisation.  This agent crawls over sites,
discovering how images are handled on the site.  It determines if there is
information about links from those images, if there is information about
the content of the image, and perhaps if there is a description of the
image using GFH descriptors.

XYZ develops an index of this information, associating urls with a rating
such as 6 where there is lots of good stuff and 0 where there is none.  XYZ
offers ratings on about 10 different aspects of the sites it visits.  Users
point their PICS preferences, within their browser, to XYZ and set their
preferences for what they do not want to work with, eg sites with a rating
of less then 2 on the image criteria.

PQR is another PICS service provider.  PQR is interested in making sure
that information about physical access to locations is available on the
web.  PQR's members visit buildings and other locations, check their
physical access, and maintain an index of information about the real-world
locations.  Members post information to a central database which accepts
such information after verifying the sender according to pre-determined
criteria.  PQR offer a PICS server which will help web users identify
real-world locations which are accessible to them.

As above, PQR users will visit the Smithsonian on the web, but get an
additional bit of information to accompany that website's publications.
The additional information will cause a sound to be heard, an icon to be
displayed, or something else to happen, which will alert the user to the
extent of accessibility to that location they can expect if they choose to
visit it.  The information being conveyed by the PICS server here is not
used to filter anything: it is machine readable data which causes an agent
on the user's computer to augment the information they receive from the
website, based in this case, on personal evaluations of the real-world
location being referred to in the web material.

The point is that PICS can do a lot of different things and until we
ascertain what we want to do, we cannot decide if we need PICS or not.  The
trick associated with this is that if we do not know of the capabilities of
things like PICS, we are probably not going to be able to have neat ideas
about how to use it.  (Technology and people cannot be separated!)

PICS does not handle structured, repeated, string data, but its big brother
RDF does.  Rich metadata sets can be conveyed using RDF: machine readable
data that might be able to do a whole lot for the user when the website is,
at its origin, very iaccessible.  A simple example is the possibility that
DDD company has web crawlers which generate structured sitemaps of third
parties' websites.  DDD offers a service which accompanies browsing by
providing users with sitemaps that extend beyond the webpage being
accessed.  Such a navigation aid might make it possible for a user who is
sight disabled to navigate effectively around that website despite the
website's author having made a complete mess of the navigation provision.
Now we are talking about site augmentation.

CCC company might use RDF to distribute information about how to navigate
around a particular website which has been found to be really interesting
even though it is technically inaccessible.  As has been pointed out many
times, as humans we most often take the advice of those we know, or who are
known by those we know.  We might, as users, want to visit sites that other
people we respect and trust have visited and recommended to us.  We might
like to associate with the artefacts that people like us find attractive.
Qualitative information of this kind may not be something we want to impose
on others but it is very likely we would like to give as many communities
as possible the opportunity to share their interests and experiences.

We can go further and have programs running on computers which offer a kind
of augmentation proxy service - on the fly augmentation of webpages based
either on human or machine data.  And so on.

I think that what emerges from all this is that there is going to be more
than enough for the RC interest group to talk about in focussed
discussions, without having to worry about peripheral (but important)
issues like censorship.  I am hoping that from my comments, some threads
can be developed which will lead us to areas of particular interest to
people.  From there, I am hoping that after some discussion we will find
people choosing to work on particular aspects of the RC's activities.

I am not worried about the name we chose for the working group - 'rating
and certification', it seems, is not what we want to do - pure and simple.
In fact, in some ways it is what we do not want to do.  My feeling is that
we should try to focus on what we do want to do, and can do, and not worry
too much about the name - think of RC as a random identifier!  What we want
is to achieve our goals, and that will involve enough gathering and
evaluating of information, creative development, and rich interpretation to
keep us busy.

Your comments are invited ...

Liddy Nevile.

Received on Monday, 26 January 1998 17:09:46 UTC