- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 24 Aug 2001 14:08:07 -0400
- To: wai-xtech@w3.org
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 UI. 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 <asgilman@iamdigex.net> 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: webwatch@eGroups.com >> To Unsubscribe, send a blank message to: >> webwatch-unsubscribe@eGroups.com >> >> Your use of Yahoo! Groups is subject to Al> <<http://docs.yahoo.com/info/terms/>http://docs.yahoo.com/info/terms/><http: //docs.yahoo.com/info/terms/>http://docs.yahoo.com/info/terms/ >> -- Best Regards, --raman ------------------------------------------------------------ IBM Research: Human Language Technologies Phone: 1 (408) 927 2608 Fax: 1 (408) 927 3012 Email: tvraman@us.ibm.com WWW: <http://www.cs.cornell.edu/home/raman>http://www.cs.cornell.edu/home/raman PGP: <http://emacspeak.sf.net/raman.asc>http://emacspeak.sf.net/raman.asc Snail: IBM Almaden Research Center, 650 Harry Road San Jose 95120
Received on Friday, 24 August 2001 13:48:19 UTC