Re: notes re RC for IG

Having finally read through this mail, I note the following:

1. Naming the group is not critical (except to standard W3C WG policies).
Therefore, leave it as is and move forward
2. Identify the specific mission of the group (since that has not been
done, only suggested)
3. Start data collection to begin building a requirements document using PICS
4. If the requirements document matches the mission, you've got the basis
for an interface design and can move to the development phase
5. If the requirements documents does not match, then do an affinity
diagram exercise to determine what it is you're really trying to create
and go back to #4.

I believe that PICS can be very useful in certain areas. I would
particularly be interested in a server-based service. But I don't think
it's a complete answer -- I think we need to look more seriously at real
knowledge tools that can be easily implemented by site administrators.

- Mike





At 04:17 PM 1/25/98 +1100, Liddy Nevile wrote:
>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 Wednesday, 28 January 1998 01:33:21 UTC