Re: Comments on gl Abstract

Hi,

Thanks for the follow up. Sorry for not getting back to you earlier -- got lost
in the shuffle.

You asked what I thought would scare novice readers. I decided to run a small
experiment.

Assumption: if reactions to the opening section are negative, people are less
likely to read the body of the document and come to a full understanding of what
is being requested.

I sent the beginning of the new Section A (from "A. Transform Gracefully" through
"Guidelines A.1 - A.12 address these issues.") to three 'naive' readers I know
from various places. All of them are senior enough in their organizations to
influence or decide approaches taken when new web sites are built. I asked them
to look it over quickly and give me their gut reactions, including what they
thought the impact on costs would be. None of their reactions were encouraging.
This is what they said:

(Person A)   "It would triple the cost of development. Maybe more than triple."

(Person B)   "You'd have to build a whole separate auditory interface, and have a
whole additional set of controls that you could access without a mouse. You'd
have to simplify the interface a lot, you couldn't do anything complicated or use
any plug-ins. And it would more than double the cost. Just adding the auditory
interface would double the cost."

And from the most knowledgable of the three:
(Person C)   "This is naive. It is too expensive to implement. Especially number
three. It isn't possible to create a single page that satisfies number three.
Every page would need to be generated on the fly and would need to be different
for each specific browser. Testing would take forever. Maintenance and updates
would be a nightmare. If someone was given the mandate to do all this they would
just ignore it."

(FYI: 'A' & 'B' were pulling numbers from the air, but 'C' has experience to back
him up: he has implemented robust e-commerce sites that needed to run properly
with Netscape, Internet Explorer, and AOL, and says that just getting all three
of those browsers to work properly was neither cheap nor easy. As far as he's
concerned, *any* additional browser or device that needs to verifiably supported
will add significant time and cost, and since point #3 is open-ended the added
cost is basically infinite.)

Thoughts:

Points 1 and 3 sound expensive and difficult to someone who doesn't know, for
instance, that HTML text is accessible via auditory means / voice output by using
audio browsers or screen readers, or that even some standard browsers allow you
to navigate most web pages with just the TAB and ENTER keys. It was for that
reason that I had included easy-to-understand examples and/or additional
explanitory text with the first set of comments I sent in. The
examples/explainations were intended to make the wording easier to grab a hold
of, so that the problems seem less vast and more approachable.

Point 2 is difficult to understand if the context isn't already understood. The
alternative wording I asked about (in the format of 'is this what you mean?') was
intended to show one potential way to clarify the issue to new readers. I admit
that the wording was very bulky but, to me at least, it seemed more
understandable.

If lengthening the section with examples or additional explaination is too
objectionable, the wording could still be made less threatening in one simple
way.

Current wording:
   "To create documents that transform gracefully, authors should:"
This wording puts the onus entirely on the author, which makes the broad
directives in points 1-3 seem all the more scary.

If the wording was changed to:
   "Guidelines A.1 to A.12 address methods for creating documents that transform
gracefully, showing authors how they can:"
The onus is now on the document first and the author second, and therefore less
threatening.

-----------------------------------

The text of your original response follows:

Wendy A Chisholm wrote:

> hello,
>
> >One concern: the early part of the abstract is so brief it may be
> >difficult to understand, and may frustrate or scare novice readers from
> >wanting to read further.
> >
> any suggestions?  what ideas in particular need to be expanded?
>
> >Section A:
> >
> >#1, Current >>>>>>>>
> >   1.Ensure that all the information on the page may be perceived
> >entirely visually or entirely through auditory means, or that all
> >information is also represented textually.
> ><<<<<<<<<<<<<<<<<
> >   Makes it sound ok if a page can be perceived ONLY visually (and not
> >audibly), or ONLY audibly (and not visually), and that textual
> >alternatives are only needed if the visual and audio are mixed one one
> >page.
> >
> >Possible alternate wording:
> >    "Ensure that all information on the page is either represented
> >textually, or that users can perceive the information entirely through
> >visual means and entirely through auditory means. For instance, provide
> >either textual or audio descriptions of photographs to facilitate
> >non-visual browsing."
> >
> >Or if that's not what was meant, alternative two [caps indicate changed
> >language]:
> >    "Ensure that all the information on the page may be perceived
> >entirely visually or entirely through auditory means, AND that all
> >information is also represented textually."
> >
> we changed both of them to ANDs.
>
> >[I'm not sure what an audio alternative to a photo does for deaf-blind
> >individuals, for whom text is still an alternative.]
> >[Is it worth explaining that bitmaps of text are not textual information
> >in point #1? You explain what ‘content’ etc are in #3.]
> >
> we have included the following definition of "screen reader" in the
> appendix, and will link to it from throughout the guidelines:
> Screen reader
> A software program that reads the contents of the screen aloud to a user.
>     Used primarily by individuals who are blind, screen readers can only read
>     text that is printed, not painted, to the screen.
>
> >
> >#3, Current >>>>>>>>>>>>>
> >   3.Always separate the content on your site (what you say), and the
> >way you choose to structure that content (how you organize it), from the
> >way the content and structure are presented (how you want people to
> >"see" it).
> ><<<<<<<<<<<<
> >    I’m having trouble understanding what that means.
> >
> >Does it mean:
> >
> >    “Use HTML4.0 elements and stylesheets for their intended purposes.
> >For instance, giving text the attribute <BIG> or using a header
> >attribute like <H1> may both increase the visual size of text on the
> >screen. But <H1> should be used to indicate the start of a new document
> >section (not just to display larger text), and <BIG> should only be used
> >to display bigger text (not to indicate the start of a new section).
> >Following the standards will ensure that your content, information
> >structure, and presentation directives (what you say, how you organize
> >it, and how you want it to appear) can all transform gracefully when
> >accessed with alternative browsing methods.”
> >
> yes, this is exactly what it means.
>
> >
> >#2, Current >>>>>>>>
> >    2.Ensure that pages will be operable on various types of hardware
> >including devices without mice, with small, low resolution, or black and
> >white screens, with only voice or text output, without screens, etc.
> ><<<<<<<<<<<<<<<<<
> >    This sounds impossibly complicated to people who have no experience
> >with alternative access methods. I spent months trying to convince
> >people via phone and email that these ‘impossible’ things can be done,
> >and they were only convinced when the saw a screen-reader and tried it
> >out.
> >
> >May I suggest moving #2 down to #3, and reword to something like:
> >    “Ensure that pages allow the flexibility to be operable on various
> >types of hardware including devices without mice, with small, low
> >resolution, or black and white screens, with only voice or text output,
> >without screens, etc. Following the principles suggested above will go a
> >long way toward achieving this goal.”
> >
> we have moved 2 to 3, and added the phrase "Guidelines A.1 - A.12 address
> these issues." after the list of 3.
>
> thanks for your comments!
> --the editors



--
  -- Paul Adelson
------
* The views expressed are those of the
* author and do not necessarily reflect the
* position of Citibank or its affiliates.

Received on Friday, 16 October 1998 14:07:22 UTC