archive: News gateway is another option

This just in on WebWatch from T.V. Raman.  Since it echoes things Janina Sajka
has said as well at other times, it is worth mentioning.

-- quote resumes

Re: [webwatch] Web-Based E-mail and Message Check Boxes

Well said.
the accesskey and navindex in HTML4 are some of the most
underused features.

And basically, dealing with email --especially complex mail
threads using today's WWW browsers is sub-optimal for
everyone --especially the blind user--
the W3C's own list archives being no exception (remember me
asking them for NNTP access at the Boston townhall?)--

You may want to have some of the emacspeak users describe
the mail reading and news reading user experience in vm and
gnus under emacspeak--
(sorry for putting you on the spot Jason--)
I'll copy Jason and see if he has the time to summarize the

We're putting in accesskey and navindex prominently into
XForms --whether people will use it is another question.

One thing is clear however, --if blind users make the
compromise today of having "labels" put in a manner suited
for the screenreaders of the late 80's, you wont make much
progress --
>>>>> "Al" == Al Gilman <> writes:

    Al> At 07:51 AM 2001-08-24 , Kelly Ford wrote:
    >> Hi All,
    >> The typical web-based e-mail found at places like
    >> Hotmail, Yahoo, and such usually includes a check box
    >> for each message.  The check box is used for
    >> selecting the message for things like deleting or
    >> moving to folders.
    >> I would be interested in people's thoughts/opinions
    >> on what you'd like to experience as the label for
    >> check boxes in such situations.  [snip, full
    Al> message below]

    Al> [Al, here]

    Al> Can we broaden the question a bit?  I could use a
    Al> reference point in "if I ran the Zoo" terms for how
    Al> these functions might work.

    Al> What was your all-time favorite email interface?  Is
    Al> it NetTamer?  Pine?  What is it?  Forget the Web,
    Al> forget what you have learned about using
    Al> contemporary operating systems.

    Al> What would you _really_ like your mail tool to work
    Al> like?

    Al> I say this because my kneejerk reaction to "how do
    Al> we label the checkbox" is that this is the wrong
    Al> question, that eyes-free users shouldn't have to
    Al> bother with the checkbox, that's a graphical
    Al> metaphor for something more fundamental.  Can we get
    Al> at the more fundamental something?  If there were
    Al> other stuff in the speech access mode so that you
    Al> basically don't know or care that there is a
    Al> checkbox, what would that be?

    Al> The dream is that you just read and manage your
    Al> mail.  The checkbox is a medium-adaptive feature for
    Al> the visual interface, not the definition of the
    Al> interface.  The definition of the interface is "this
    Al> message is marked for deletion."  That is a piece of
    Al> the state of the message in your session buffer.
    Al> The key at this point is that it is the state of the
    Al> message, not the state of the checkbox, that you
    Al> want to manipulate.

    Al> And you probably want a "delete this message"
    Al> keystroke command and not a "delete this message"
    Al> checkbox to make the interface work well in keyboard
    Al> plus speech.  Navigating to the checkbox is just a
    Al> detour you don't need.  What message you are talking
    Al> about can be obvious.  Make the system deliver this
    Al> service.

    Al> Managing your email, that is being processed by a
    Al> web service like hotmail, is the prototyping lab of
    Al> many many web services to come.

    Al> For eyes free access, do you want to focus more on
    Al> the current message and do with it what you are
    Al> going to do with it?  What I would expect you are
    Al> not going to do is review the list of messages, with
    Al> its marks on those to be deleted, as a list, the way
    Al> the visual user would naturally do with the standard
    Al> GUI design of this service.

    Al> So let's make the delete that you do while you have
    Al> the message selected more sure, put in enough
    Al> confirmation at this point, so that review later is
    Al> not required.  And get it over with while you have
    Al> the message to be deleted in mind.  After all, when
    Al> the information gets to the server, deletion or
    Al> filing will be done on a message by message basis.
    Al> That is the level of the object that you are
    Al> manipulating.

    Al> Pages of folder contents listings are the medium of
    Al> the exchange in the dialog only because that is
    Al> natural when visually reading a half-page-sized
    Al> screen.  It's not the natural shape of the dialog in
    Al> keyboard plus speech.  So let's get the ideal answer
    Al> on the table first and see how much of that we can
    Al> get rolled into the standard definition of the Web,
    Al> before we start compromising.  There may be a better
    Al> deal in this somewhere.

    Al> OK, now let me backpedal a bit.  It's fine for the
    Al> checkbox to show the "marked for deletion" status of
    Al> the mail item.  And be there for the visual user to
    Al> change this status bit with.  But the medium in
    Al> which we interface to the web service has to have
    Al> multilevel scoping in how it handles verbs, multiple
    Al> verb options in any context, so that the system
    Al> knows that 'delete' is at the message level and it
    Al> can have a current selection more locally on the
    Al> author, the subject, etc. but if you emit the
    Al> 'delete' hotkey or shortcut, it knows to handle this
    Al> at the message level and marks it in the 'delete'
    Al> checkbox without you having to move to the checkbox
    Al> to do it.

    Al> Everybody, please do give your feedback.

    Al> There is a feature in HTML 4 called ACCESSKEY that
    Al> we may wish to re-engineer slightly in XHTML 2.0.
    Al> Maybe it can be made to do what you really want.
    Al> Tell us what that is.  The web mail scenario is high
    Al> on the list of those where we will learn what it is
    Al> we need to be doing.

    Al> Al

    Al> At 07:51 AM 2001-08-24 , Kelly Ford wrote:
    >> Hi All,
    >> The typical web-based e-mail found at places like
    >> Hotmail, Yahoo, and such usually includes a check box
    >> for each message.  The check box is used for
    >> selecting the message for things like deleting or
    >> moving to folders.
    >> I would be interested in people's thoughts/opinions
    >> on what you'd like to experience as the label for
    >> check boxes in such situations.  At present most
    >> screen readers default to reading the linked item for
    >> each message i.e. the name of the message sender
    >> because that's what is acted on to open the message.
    >> For people using programs like HPR, Window-Eyes and
    >> JAWS, the full header information is available as
    >> they cursor through the buffered view of the web
    >> page.  By buffered I mean the HPR item view,
    >> Window-Eyes MSAA mode and JAWS Virtual PC.
    >> If you'd like to experience something different from
    >> the actionable text for each message, how would you
    >> feel about having text duplicated.  To give an
    >> example based on how such might read in the
    >> decolumnized view of the page with the different
    >> programs.  In this example *C indicates where a
    >> screen reader would say check box and *L link.  I'm
    >> also assuming here that tables are used and should
    >> the user want, appropriate column header information
    >> is available with columns being status, checked
    >> status (not a visible label), from, subject, date and
    >> size.
    >> Existing design
    >> New *C *L Kelly Ford Testing Some E-mail 8/24/2001 3K
    >> When the user tabs to the check box, or activates it,
    >> he or she would hear Kelly Ford, unchecked or
    >> something similar.
    >> It is possible to adjust the text of the check box as
    >> the following illustrations show.
    >> Example 1
    >> New *C Select or Deselect Message *L Kelly Ford
    >> Testing Some E-mail 8/24/2001 3K
    >> One tradeoff of this example is that the user no
    >> longer gets the message sender name when moving to
    >> the check box with tab or pressing enter to activate
    >> it from a screen reader's buffered view of the page.
    >> It is also possible to include text from the message
    >> header.
    >> Example 2
    >> New *C Kelly Ford, Testing Some E-mail *L Kelly Ford
    >> Testing Some E-mail 8/24/2001 3K
    >> But in this case, it is likely the user is going to
    >> experience the text duplication in reading through
    >> the web page as I've illustrated.
    >> The ideal might be to use header commands or
    >> something similar to only have message header text
    >> spoken when the check box is activated.  In such an
    >> example there wouldn't be any text after the check
    >> box in the buffered view of the page.  However I
    >> don't believe that this kind of design is supported
    >> by the assistive technology at present.
    >> Although I'm asking my question about e-mail, the
    >> same question could be asked about a number of web
    >> pages.  For example you might have a table listing
    >> products from a shopping site and check boxes to
    >> indicate which products you want to add to your
    >> cart.  In such an example, the check boxes would
    >> typically again only speak the actionable item from
    >> each product, although it would be a bit more
    >> descriptive because of the nature of the
    Al> page.
    >>  Anyway, I'd be interested in people's
    >> thoughts/opinions.
    >> Thanks,
    >> Kelly
    >> To Post a message, send it to:
    >> To Unsubscribe, send a blank message to:
    >> Your use of Yahoo! Groups is subject to

Best Regards,

IBM Research: Human Language Technologies
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Friday, 24 August 2001 13:48:19 UTC