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-01-04

Time: 1:00 PM CST


  1. Organizational stuff
    • Future teleconferences; see please http://cita.uiuc.edu/collaborate/webmail/
    • Format of the notes; maybe HTML?
  2. Questions for PF and AREA working Group (Jon and Don)
  3. Feedback on Best Practices (Hadi)
  4. AddressBook widget (Mike)

If you would like to add any particular item in the agenda, please feel free send it to the list or to me.


Minutes January 4, 2007, Webmail Accessibility Interest Group


Next Meeting

Scribe for the next meeting, Thursday, January 11, 1 PM EST: Don Evans.

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.

Possible Agenda


Mike Scott was on the agenda to discuss an implementation of the address book widget but could not make the teleconference. Conversation centered on questions for the ARIA Working Group and updates for the Best Practices document.

Early on in discussion there was a question about the formatting of the minutes. Currently they are in HTML form, put up by Hadi, and a version goes out on the listserv, as well. Jon suggested making the minutes links on the collaboration site point to posts within the listserv archive. Jon suggested that there could be a link to the agenda, which would remain HTML, and the link to the minutes could just point to the listserv archive entry. Archives of the listserv are public. Nothing was decided on this issue.

An edited transcription of main discussions of the meeting follows.

Questions for PF and ARIA Working Groups

Hadi: Jon and Don could you talk about the specific format that they would like for the questions? How does it usually work?

Jon: On this Monday, the ARIA group met to discuss some of the issues.... I guess some of my questions.... I've been testing this (the grid view) with JAWS and Window Eyes. I guess some of the questions I have right now refer to the proper use of the grid. I guess the major question has to do with the use of the region role, which we discussed last time we met. I was using group before to say that a row was a connected message. And I think the issue here is that as you move the highlight up and down each row the behavior you'd like to see in a screen reader is that it reads that row. I was putting a region on the TR element, but I'm not seeing the screen reader read that element and handle it together. One of the things we talked about in the best practices is that users should be able to configure which columns they want and the order of the columns. So if there was a way for the screen reader to read all of the rows in that column. So so that choosing the row and column the user can configure the program to read what they want and the order that they want for the messages. That's one of the central questions I have for the aria group. Is the aria specs going to define the behavior of a region. What's going to happen when a region gets the focus. There is also an issue here of selection. The issue is you can't give focus to a table row. Which is the whole purpose of tab index. When you assign tab index you want to be able to give that element to focus. And at least in Firefox 2.0 you can't give a table row focus. You can't tab stop there. So right now I think I have tab index zero on all of the grid cells. So that when you tab through the document you go to each grid cell, which defeats the purpose of having a hierarchy of rows.

Hadi: I noticed when tested with Window Eyes 6.0 and JAWS 8, IE does not recognize....

Jon: You have to remember that IE doesn't support any of this ARIA stuff.

Hadi: But then the problem is that Firefox doesn't have as good support in JAWS as IE does.

Becky: Well, it's getting better.

Hadi: Yes. It is getting better. But for example left and right JAWS says it is set but it does not read the contents of the cell. Is this a problem with lack of support in the screen reader or is it a problem with with the grid.

Jon: Right now, IE would just ignore the ARIA information and try to read aloud what ever other informtation it had access to.

Hadi: One of the things you notice is that the way Jaws renders in IE and Firefox is very different. I use one browser and I get certain controls and I use another browser and I don't get those controls anymore.

Jon: Right. So one of the questions I have is is there going to be a way to set selection on a row within the ARIA specification? What's going to be the behavior when I use the region element to define the role for that row? So in that region gets focused shouldn't read all the contents within that region? Should that be the specification? And if TR cannot be used for region then what is the alternative? So right now, as it goes through, I guess I'm not sure what I'm doing with grid cells but I know that when you go into these left and right arrow keys you're setting the selection property to be selected. And if the whole row is highlighted all the cells are individually selected so I don't know if that's the model they envisioned for that. I also want to ask if that's the sort of keyboard navigation model they intended. Also how do they imagine use of the labeledby attribute in conjunction with this. Should the labeledby attribute be used to signal what the state of an element is? So, I guess those would be my main questions for the ARIA group.

Hadi: Jon have they suggested what keyboard commands are to be used? Or do we recommend these to them because it would be in line with the typical web mail application?

Jon: I want to say the them, "yes, that what an ARIA applicaition is going to have to do. You will have to provide that keyboard control." We what to make sure that in their documentation they talk abou that because I don't think that is going to be intuitively obvious to most developers, that they have to provide this type of keyboard control.

No one else had any specific things to add to the questions to ARIA.

Jon: Becky, are these questions that we already have the answer to?

Becky: Well, no. But I don't think we will ever get focus on a row....

Jon: Okay. That may be fine. But then what do we do?

Becky: Right. Then maybe we would have a describedby on every cell, so that a user could go down, cell by cell.

Jon: well, that is sort of what I have right now I have labeledby attached to the checkbox on the row so if you go down that row. Or actually I just put a regular HTML label on that checkbox but it's a hidden label. But if you disable the styles you can see that hidden label. But that's not really programmable it's something I hardwired a in.

Becky: That could be generated programmatically for each row. It could be gathered from information in the other cells or whatever. Again you have the problem with hiding it.

Jon: I just use CSS positioning and put it way off the visible area of the screen.

Hadi: Srini or Matt do you have anything to add?

Matt: We are working out implementations and I know that from a user perspective selection of a row is critical for a grid.

Best Practices

Hadi: I wanted best practices to be useful. Not too long to be boring and not too short. What order do we want for items. I was thinking for general layout, an introduction, they who is writing what stuff, and then what is appropriate for Web 2.0, and they we introduce the major components of web mail, and I have listed here tree view, and then grid view, and then address book. We don't want to deal with calendar at this point. No strong interest within the group to cover that at this time. For the subsections for each widget we want web 1.0 section and a ARIA section and a keyboard commands section. Do we want a general table of contents.

Jon: We probably need to separate off some of the things into a general or globally applicable section. For example, "tree view for mailboxes" would be a good title and "grid view for email summaries" would be another. I think we need in the best practices a sort of "general web applications accessibility" section. So for example, right now under the grid view section, it talks about using headings to separate off the sections of the web application and that's really not specific to the grid view that's more something related to the overall application, in an area for "general application." I know that for me, now at least, it's very important to see a section that indicates what are the web 1.0 techiques and what are the ARIA techniques and have those things separated. I think this is a good start.

Hadi: I wanted to get a general pattern for outline.

Jon: I know one of the things I have seen with working on other best practices is that developers want to know, "well, why is that important?" So that something that most developers would not think of, such as using left and right arrows to navigate grid cells. Web mail developers would never come up with that feature if they were just doing it on their own. So, we need some statement of "why is that feature important for disability access." Maybe some indication that such functionality is standard to the way desktop applications work now, that that is what Outlook is doing, would be important, since everybody seems to want to copy the behaviors in Outlook. Also, if we deviate from the keyboard support that is in Outlook or other major email clients or applications, we need to have some rationale or indication of why we are doing this.

Hadi: So I will keep updating these best practices with the information people send.... So I have not heard back from Mike, but I have not heard back from him.

Jon: Well, maybe we can work a bit on the best practices?

Hadi: Okay, then, can we all look at the best practices on the web site? I think we would like to discuss the tree view section of that.

Jon: So when we click left on any node that is already collapsed it doesn't do anything, right?

Becky: Left will go up to the parent, after it closes, or if it isn't a expanable node. First click will close and next goes to parent.

Don: And if you are on a child node, the left arrow goes immediately to the parent.

Hadi: Do you think such detail should be discussed in the best practices?

People answer "definitely."

Becky: I've been working with the group has been working to create this style guide information. You are saying tree view for mailboxes but were also working to define what the default behavior for a tab panel should do. The intent of this document is to be completely public but their are licensing issues involve right now and so people have been reluctant to make the wiki public. This is the "DHTML style guide" and the intent of it is to be public.

Don: Well, a I have a set of those recommendations that I'm feeding to Tom. Can I make them public?

Becky: Yes, that's fine. Everyone involved knows that it will be made public. It's part of the licensing agreement. It's just a matter of letting the lawyers work it out. Right now, as far as we've gotten is tab panel and we haven't gotten very far with tab panel because there are a lot of issues with how you trap certain key strokes. You can only trap them at the document layer, not at the widget layer. The browser takes it over and changes the tab. The key combination doesn't get given to me, the browser takes it.

Don: This is the tree view that you presented on Web Alley. Is this tree view doing everything you want it to?

Becky: Yes.

Hadi: Let me see if I understand the default behavior. If you are on a node that has children and you press enter, focus will stay in the same place and the node will be toggled open and close?

Becky: Yes that's right. I will say that Windows does not implement this. If you press enter on a node it does not toggle it open and close.

Hadi: Screen reader users don't like toggle keys. It is difficult to find what is the state of that node.

Jon: So is there a way in ARIA to notify of the state of a collapsed or expanded node?

Becky: Yes. As long as you as a programmer are providing the state, the screen reader will tell you that state when you put focus on the node.

Jon: So we need to add that to the ARIA techniques.

Don: One thing that should happen is when you enter the widget it has to announce that you are in a tree view.

Jon: Could Becky or Don fill in what are ARIA and Web 1.0 techniques for the tree view like we have done for the grid view?

Becky: Yes I can do this.

Discussion of Next Week's Agenda

Hadi: What are the new agenda items for next week? If I hear from Mike Scott, we will try to get him to talk about the address book widget. Jon and Don will share feedback from the ARIA group. Next week meeting time works for most of us, except Becky. Are there any other items?

Jon: I think we want to talk about how these controls interact.

Hadi: Right, I had called this a controller or wrapper widget. What would you guys have this called?

Becky: I think this is good. Maybe you can call it mail view controller if its going to be specific to web mail.

Hadi: Matt and Srini. If you have time could you think a little bit about this mail view controller? If we have this write up then we will have all of the specific components for the web mail application.

Jon: There are some other things to consider. Some email programs automatically update your mail. So if you get new mail, does it automatically populate the grid view with the new email information? Is this a different area of the ARIA specification? I think we would call this a live region. When you have an asynchronous event, how do you notify of updated content on the page? So I think these are some future issues we need to keep looking at.

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.