WebMail Accessibility Interest Group

Campus Information Technologies and Educational Services (CITES) and Disability Resources and Educational Services (DRES)

University of Illinois at Urbana/Champaign

All Teleconferences

Teleconference Details

Date: 2007-02-01

Time: 1:00 PM CST

Agenda

Minutes

Minutes

Minutes February 1, 2007, Webmail Accessibility Interest Group

Attendees
  • Hadi Rangin (UIUC)
  • Don Evans (AOL)
  • Julio Chavarria (Great Lakes Center)
  • Hank Rozycki (Mirapoint)
  • Jon Gunderson (UIUC)
  • Mike Scott (MSFW)
  • Victor Tsaran (Yahoo)
  • Becky Gibson (IBM)
Regrets
  • Matt Anderson
Next Meeting
  • Date/time:Thursday, February 8, 1 PM CST
  • Scribe: : Mike Scott
  • Note to future scribes:Currently, minutes are delivered via text email and put on the web as HTML. Scribes should format HTML so that headings start at H4 and get smaller as appropriate.

Mike: Assignment was to look at address book functionality. Reviewed different apps: outlook, outlook web, Group Wise, Yahoo Mail beta. Review is here: www.dhs.state.il.us/webstandards/webmail.There is more variability in address book functionality between apps than inbox functionality. Group needs to decide what we want to include in address book functionality. All address books had 3 functions that are common

  1. address book function accessible while composing a message generally avail via a button.
  2. a contacts view
  3. add/edit contacts

A contacts view is not essential as long as there is a way to get at contacts and add or edit them. First screen shot is of Outlook Web Access address selection with a compose window in the background. Clicking a button in the to: field brings up a dialog on top of the compose window. This dialog works as a search dialog. It returns matched entries in a grid type format (although much simpler than inbox grid). Is is composed mostly of web 1.0 techniques with the addition of the search results grid.

The third screen shot is the equivalent functionality of selecting a name from the address book in the Yahoo mail beta. This popup is much simpler - it is just a select type element that lists the contacts. This is purely Web 1.0 approach - just a simple select, pick one and select ok or cancel.

The second screen shot is the edit contacts screen from Outlook Web Access. From the contacts view select properties to open up tabbed dialog of the contact details. Still Web 1.0 except for tab panel and there is no save and close button - have to use the save and close link in the toolbar of this window.

The fourth screen shot is Yahoo mail beta contact list. It has a tree view in the left pane, pick contacts from the tree view and the email list grid (currently in the right pane) is replaced with two panes . The first contains contact names. When you pick one of the names the pane on the right contains a Web 1.0 list of edit boxes to edit/add the contact details. Thus screen ends up with three vertical panes for information - tree view of folders, contact list and contact details.

So, seems that address book will generally be Web 1.0 functionality with addition of the grid? Do folks agree?

Hadi: doesn't sound like new features

Mike: There is the issue of a dialog that may or may not be modal. That is kind of a Web 2.0 issue. Is the user aware that a new window is opening rather than a new page being loaded? Need to make sure to provide adequate info to the user that new window is opening. Common construct is having a button precedeing the recipient field - button is acting as a label. Is this a tab order / flow issue? User doesn't have to click on the button if tab over the button will end up with focus in the To/recipient field. After opening up dialog and selecting recipient, where does focus go when dialog closes? Probably into the recipient field for which the button was pressed and the recipient address was added.

Becky: What about typeahead in the recipient field - is that a compose or an address book issue?

Mike: Not sure if that is address book functionality or not but we may want to tackle compose soon.

Hadi: Seeking volunteers to research the compose widget.

Mike: Given what we are seeing in the address book what more does the group think we need to do?

Hadi: In answering questions from ARIA group it seems like we should use Web 1.0 wherever possible and use ARIA and Web 2.0 when can't solve with 1.0. Mike's examples talked about the grid - is it really necessary?

Mike; So do we really need a grid? We could probably create an address book using purely 1.0 but I think vendors want to make it fancier.

Victor: Yahoo group doesn't want to restrict users. We should come up with recommendations for both Web 1.0 and Web 2.0 implementations. Want to encourage folks to use the suggestions this group creates thus we don't want to be too limiting. Screen readers have different techniques for dealing with Web 1.0 and ARIA techniques - this can be very confusing.

Mike: With the techniques in use now, when the outlook address picker comes up as a new window a screen reader will notice and start interacting with it as a form and entering data. Then when the user clicks find to search for a name the grid area gets populated (via Web 2.0) should focus go there? Is there issues with forms mode on and off?

Victor: Yes want it to be transparent to the user.

Mike: When navigating in grid what mode to we want in JAWS?

Victor: Want forms mode on (even though forms mode is really for form elements but it is needed in order to have the arrows and other keys work within the web 2.0 apps rather than being used for scrolling thru the virtual buffer.

Hadi: and want virtual buffer off

Mike: When have components that combine web 1.0 and web 2.0 we need to be aware of changing modes in the screen reader.

Jon: JAWS does speak information in current grid, although it does need to be in virtual off mode in order to navigate the grid via the arrow keys

Becky: How to toggle forms mode on and off?

Hadi: insert-z toggles vitural mode on and off in JAWS. although forms and virtual buffer are not necessarily related.

Victor: Not a terribly big problem to have mixed modes as long as the user gets the information about the control

Hadi: user will have to toggle back and forth bwteeen virual mode on and off.

Victor: I think this is ok - allows skipping the entire control. I like the way Voice Over on Mac has implemented interaction with the browser. Worth looking at and think about when we are talking about Web 2.0. With many objects coming into the user it is good to provide the ability for user to decide which ones they care about.

Mike: I actually do training for state staff who are blind/JAWS users. In training 30-40 people it seems that few are comfortable switching in and out of forms mode. These are non-technical users. I teach them to scan page in vitrual mode until need to interact with an element then go into forms mode and stay there. Thus, have asked developers to add tabindex to more elements so users can stay in forms mode and continue navigating the page.

Victor: agree, once in forms mode we should do what we can so users can stay in that mode.

Becky: What about inbox with inbox on the left and a split pane to the right containing the inbox list and preview for the selected message below. Do you have to switch modes to get the contents of the preview pane read?

Victor: Put preview pane in the tab order

Becky: so as long as preview is in tab order (like a div with tabindex=0) jaws will stay in forms mode and content will be spoken without leaving forms mode?

Mike: could also be a text area rather than a div

Hadi: next item in agend is Jon's improvements in the grid. Some of the improvements depends upon the behaviors we are expecting. Third item in agenda is desired behavior of screen reader in a grid Hadi's ssent an mail to the list. What needs to be done to grid to make it keyboard accessible?

Jon: what is expected behavior of the screen reader after I execute some of the commands - what do we expect to be part of screen reader functionaly and what depends upon what hints the develeper has added? How to deal with focus via tabindex=0 or scripting elements with tabindex=-1 and role of select. What does developer need to know about those things? For example the PF group has said that as far as navigating the rows in our grid the screen reader should provide that arrow key navigation

Becky is surprised that PF group would say that. The original example she wrote which is up on Mozilla site included arrow key navigation for each cell via tabindex=-1 on each cell.

Jon: Our grid example only navigates by row - we will focus the row and also set the select attribute. If someone is navigating all cells in a grid then developer has to provide cell to cell navigation and set focus and select.

Mike; I think this comes down to virtual mode on and off issue again. Because we are including interactivity we have to be in virual mode off. Ideally screen reader should be providing the mechanism to move by arrow keys in the table rather than requiring developer to implement that behavior. Screen reader table reading commands already do this but I can only use that in virtual mode on and we need it in vitual mode off.

Jon: What is the ideal behavior we want when people execute a particular command? What should screen reader say when I do that command? What does the application developer need to do with markup to get that particular behavior (that we want)? For example, When I navigate to the next row what do I want the screen reader to say? Need to define the behavior we want and what is application developer's responsibility to achiieve that behavior and what is the screen reader responsibility? That is an important part of ARIA spec that hasn't been developed yet.

Victor: In my view ARIA group is proposing the spec for the markup and what screen readers will do is an aspect of each vendor.

Jon: I think this is an opportunity to influence the behavior of the screen readers

Mike: When we move the focus to an element the screen reader should announce the element.

Jon: What about in a row - should the entire be row spoken? Group should decide what behavior we want for particular keystrokes from a screen reader then move on to define desired behavior of other assitive technologies.

Action Items
  • Hank to send email to Hadi then Hadi to add Hank the the mailing list.
  • Group: What behaviors do you want on the keystrokes that Hadi defined in his mail?

Edit teleconference

Discussion List

IRC Server and Channel Information

This will provide a means to share information during a teleconference and see the minutes in real time.