June 18th WAI Audio call minutes

Are online at 
  http://www.w3.org/WAI/group/970618call.html

and attached in ASCII.


=============================

Date: Wednesday June 18th 1997 
Time: 11:00am to 12:40, Boston EST time 
Phone number: 617 258 7910 
Subject: Timeliness and scope of our work 
Participants (order of apparition):

  Daniel Dardailler - danield@w3.org
  Harvey Bingham - hbingham@ACM.org
  Jim Fructerman - jim@arkenstone.org
  Jon Gunderson - jongund@staff.uiuc.edu, 
  Dave Raggett - dsr@w3.org
  Al Gilman - asgilman@access.digex.net
  Gregg Vanderheiden - po@trace.wisc.edu


* We started the discussion on the topic of naming but quickly went onto
trying to come up with a taxonomy for the different kinds of
accessible user-agent.

Daniel (re)presented his simple cut Markup aware/unaware.

Jim came up with a different model where the number of interface
presented is the criteria: a two interfaces application is usually one
where an add-on is providing the accessibility service, but the
original interface is still there, whereas a one interface is one
where the accessibility is builtin the product.

Later in the call, Gregg mentioned the view (coming from Java Access
study) where applications can be in one of three groups: 
 Type 1:  Standard applications with built-in accessibility / usability for
people with disabilities
 Type 2:  Standard applications that are compatible with (cooperate with)
technologies/devices used for access by people with disabilities
 Type 3:  Standard applications that are unaware of and don't cooperate with
access software attempting to work with them


pwWebSpeak is the closest thing to a Type 1 application, but it really 
isn't standard mainstream software that's accessible, but rather is a 
browser accessible to people with visual impairments.  It's the best 
example we have right now, thought.
Microsoft Internet Explorer (on Windows platforms only) would be an example 
of a Type 2 application.
Almost all other applications are Type 3.


The names Screen Reader vs. Self Voicing applications was not deemed
good enough because other non-Voice output like Braille or
Enlarge/Zooming exist.

Al gave a description of the accessible features of a Lynx/vt100
system (image link, information page, link list). Here I think we have
a "participating" application (lynx) with a add-on (vt level screen
reader), but this is not at the level of DOM (full markup structural
access). Unsure this could be categorized as a markup-aware accessible
system, although it's the beginning of it.

Al also mentioned proxy based system like the PDF one as a new model
where the user-agent gets some help from the pipe, so it's even more
complex that that, as there are strategies for working around dumb
interfaces between the markup-aware agent and the audio-aware agent.

Overall, [on an editorial note] I think we are still talking about a
Markup aware/unaware dichotomy, even though dichotomy maybe too strong
and we should be exploring is incremental improvements in the
intelligence of this interface that would not move it into the
"smart" camp, but would remove the worst of the problem.  For
example, introducing matching Termcap entries to instruct Lynx
and "punctuation pronunciation dictionary" entries to instruct
the screen reader.  This would just be an incremental change in
the interface, but would probably work the acute problems.

Anyway: we haven't decided on any short names!




* Daniel made his concern clearer: he doesn't want the markup
guidelines that WAI will produce to become an algorithm ala: if the
user-agent considered is markup unaware, then you should do that, if
it is markup aware, then do that, if you think HTML 3.2 is
supported, then that, etc.

A too complex document will confused the readers (authoring tool
vendors and content providers) and not have the desired effect.

At that point, Al said that what is confusing varies with the
audience.  For the desktop-publishing content creator, a concise set
of rules supported by examples may be the clearest thing we can do.
For toolsmiths, the easiest message to deal with may be a long message
in low-level formal language (schemas, class dictionaries, APIs,
etc.).

Ideally, we would be at time 0: we design HTML + the
browser(accessible or not), + the pages at the same time.

But we're not, we have different HTML version out there, and more
coming out, we have different browser features, and a tons a pages.

Doing a big reset and declaring a time 0 again (i.e. only design
things based on new HTML version, upcoming browsing tools and future
pages) is possible, but risky and probably not was people are asking
for.

We discussed several examples.

The CSS Positioning functionality is a solution to the
TABLE-used-for-layout-nighmare. 

OK, but positioning is not at a level of support in the field that
would allow a content provider to build on it without losing
functionality (e.g. netscape 3 or less user will not get the layout
desired by the author, netscape 4 and ie 4 will do something
different). Unlikely that authors will switch to positioning before
there is a minimum guarantee of access of their page by the mass
market.

So how should we talk about positioning in the guidelines ? Use it
*if* it works ? Doesn't make much sense.

Another example.

Some guidelines say "put your link on separate lines", so that the
screen reader (i.e. markup unaware agent) presentation is better.

If I am a content provider, my answer might be: fix the screen reader!
a link is a link, and you have access to my HTML.

But the majority of screen reader users still use markup-unaware tools
and sometimes have no way of changing them (financial, organizational,
etc).

Anyway, the conclusion seems to be that the Guidelines document will
have to be a *living* document that reflect the state of the
market/internet and evolve with it. We will probably have some if-else
in it, fine, but they will have to be updated continuously. 

Al opined that if one got a prioritized bitch list from speech users,
and split them along the lines of the initially-discussed dichotomy,
that there would be "better than 85% agreement" between what the two 
groups were most concerned about.

Daniel responded, "You mean gross things like missing ALT,
navigability and logical flow that are visible in all HTML versions
from 0.9 and up," and Al agreed.
Gregg added that the technique currently used in the Trace Unified
Guidelines is to list the different solution strategies for each issue
(tables, images, etc.), and note those that work today with the tools
people have.  Following this is a comment as to how things should look
in the future.

A suggested approach for the WAI guidelines would be similar:  to list what 
would work today, as well as making suggestions to browser and screen 
reader designers as to ways they could improve the situation, and then list 
what the implications would be for future web page design.


This may well ring the bell of a priority ordering in the guidelines.



* We also briefly talked about validation tools like Bobby
(http://www.cast.org/bobby) or Lynx-it (Al send a bunch of urls). 

Al also said that he's thinking in his ACSS action item about the
possibility of a show-me-what-it-would-look-like-in-1D style.

Received on Friday, 20 June 1997 16:11:46 UTC