Time: 1:00 PM CST
I have scheduled all our future teleconferences to make sure that we get the same number and we can schedule it in our calendar ahead of time. here's the list of the teleconferences. The phone number for all of them is: 217 265-9888.
- Organizational stuff
- Future teleconferences and members' Availibility
- Address book example by Mike
- Description of the problems with Grid and Tree View examples by John/Don
- Best Practices by hadi; draft is available at: http://cita.uiuc.edu/collaborate/webmail/
I am pleased to announce that Becky Gipson from IBM will be joining us today as well.
Notes for Webmail Teleconference on December 14, 2006 By: Julio Chavarria Attendees Becky Gibson Julio Srinivas Ken Petri Mike Scott Jon Hadi Next Meeting Scribe: Ken Petri Date: January 4th Agenda: Address Book (Mike); Any other Best Practices Items Introductions Becky Gibson - Web Accessibility Architect, IBM; Member of WCAG; Working to implement widgets in DOJO and make them accessible with the ARIA techniques Jon Gunderson - Director of IT Accessibility Services, Disability Resources and Education Services, UIUC HadiBargi Rangin - Web Design and Accessibility Specialist, Division of Disability Resources and Educational Services, UIUC Ken Petrie - Director of Web Accessibility Center, OSU Julio Chavarria - Network Analyst, Great Lakes ADA & IT Center - A Disability and Business Technical Assistance Center Mike Scott - Accessibility Consultant based in Springfield IL Srinivas - Accessibility Engineer, Google Discussion Hadi: December 21 meeting was cancelled due to low attendance. Jon has been working on his example. Jon, can you talk a little bit about the status of that? How far you got? I know you and Becky had a very technical discussion yesterday. I would like either of you to talk about it. Jon: Yeah, I talked to Becky. I learned a lot of things about what work and don't work. One of the things being that you cannot put a tabindex On a trow element. It is sort of like this concept of having an item of a row being selected. Giving that row focus is not going to work; at least not on any current version of IE or Firefox Mike: Can you put it on the children of that row? Or the cells contained in that row? It that the next closest thing we can do? Jon: The only thing that the "selected" attribute does is really when you move focus to it, it will tell you that it got selected. Mike: OK. Jon: That might still be useful. It could still be something we do or recommend. It's basically an "advisory thing" that is basically saying that this "thing" that got focus is also selected. It is probably valuable to do that. The bigger issue for me is that it kind of complicates... one of those things that we were hoping for is that if I was just using the up and down navigation with the whole row selected, the order of the columns would indicate reading all of that information. Hadi: Even they are in different cells, they can be selected all at once. Correct? Jon: Right. Hadi: You cannot localize your selection to that specific cell. Jon: You can, but like if you were just reading down the email and you wanted to use column order to read stuff. You know, you hit down arrow to go to the next item. I am not sure if that will worlk. With [an HTML] code interface you do it with a table and just go from cell to cell and it will read to you only what is in that particular cell. Becky: I see what you are saying. You want it to read everything as you arrow down. Hadi: Not necessarily, Becky. Jon: On our face to face meeting, we talked about people being able to configure which columns in the email grid they wanted and the order of those columns. The purpose behind ordering is that if your are navigating just the rows themselves, it would the first columns, the second column, and so on automatically. That way people would have as much or little of the row items that they wanted spoken. And then if they wanted to read an individual unit like who is it from or what the subject is, then they could use the left and right arrow key to get that information, but it is not clear to me that we can do that now. The other thing that Becky pointed out was that I was using the group role to kind of group on the "tr" element to say that "all this stuff is together as a group". With her guidance, it really probably should be the region element. Region is more for when you have a list of items, and you wanted to count how many things are in that group, or "n" items of "m" or second item in a group of eight items. So, you could provide other attributes that would allow people to number different items. So group didn't really do what we needed. Hadi: Jon or Becky, Could you illustrate where "group" would be used versus "region"? Becky: One of the things that I currently use group for; actually I think it is changing because, I think there will be a tree group added, bur for today what I use group for is to put tree items together. I put a group around all of the items at the same level on the tree. When I expand that, those get visible and they are in a group. Firefox will actually count the items in the group. So when you open that item, Firefox will say "five items" or "one of five" because it sees that this item is part of a group and it knows that there are five items in the group. Hadi: Jon, with the discussion or the hints that Becky gave you, do you think that the [grid] example is in a state that we could use to provide as an example of how future great applications should look like. Jon: There are a few things that I still have questions on. The next step for this prototype is to take it to the PF working group and ask them about some of these issues. In terms of using the "tr" as a tabindex and this issue of what would be the appriate markup to use to say that these group of cells could be read as a group as opposed to individually. It seems that if cannot read it as a group then being able to at least re-order columns does not seem to be a requirement that we want to say because it is not only going to benefit the user that can pick and choose which columns they want, but they will never be able to hear all the columns at the same time. Becky: Yes, this might be an example. I was thinking that maybe you could put the reading on, when you went down the select column and you could put the labeledby. Potentially there could use more than one id to labeledby so it would concatenate that information. That would be a change to what they specified labeledby as. That might be one proposal. So that you really have one column be the trigger and can read all the others. Mike: Becky, has there been some consideration on that with the labeledby? That's something that might be come up in some other scenarios. BeckY: I am not sure. I did submit comments to the PF group, but I am not sure I put that one in there or not. I have seen in other places where they ask "can I have it be more than one?" to concatenate it. That means you have to put an id on everything. Jon: It is an idea and everything. I mean, to my little example. Right now what I have on the select box is that there is an actual hidden label on the checkbox. I used a real checkbox, although on a real web application they might not have a real checkbox. I do have a label. The label say, "select message x, for message number, with subject blah, blah, blah From blah, blah, blah". Becky: Okay. So maybe that is what I saw when I was looking at the code. Jon: So, it is in there but is is hardwired into the stylesheet. I mean, I guess what was on that label could be configurable. But that would be a different congiguration option. Becky: You are saying that when you are generating you would just pick the order of their columns and use that and give it an id. Jon: But there I am adding additional words like "Select message x". If you go further you will find "with subject of" but there is no "with the subject of" anywhere on the page to try to make it more human readable. Ken: I noticed. I tried it out Jon. It works really nice. I liked the fact that I could be in any column and if I arrow down the rows I would hear the labels being read. Doesn't matter where I was in the series of columns, using JAWS. But it seems like it was also moving through the rows in the table by using the tab key. I know that if you use it without JAWS on, the tab key would still work. Jon: I modified the example a little bit. I was playing around with the tabindex. Becky told me another little secret yesterterday. If you dynamically generate the tabindex, the "I" must be capitalized for IE to recogize it. Does anybody know if you dynamically generate "style" for IE using the setAttribute DOM function. Does IE need it to be a special [format], like capital "c" [if you want to dynamically create a class attribute] or capital "s" [if you want to dynamically create a 'style" attribute on an element]? Because IE doesn't seem to like it when I try to dynamically creat a "class" attribute. Mike: I think it is "className", with capital "N". I think the word class is reserved. Becky: I think className works for both of them. Ken: Are you talking about setting a property Jon? Jon: Okay. Right now I am using just "class". Mike: That's reserved, but "className" will do it for you. But it is capital "n" in "className". Jon: Okay. Let me try that. Hadi: While Jon works on the modifications to his example I would like to report on other action items that I would consider best practices. I started with it and I added to the website at http://cita.uiuc.edu/collaborate/webmail/bestpractices.php. I have never drafted a "Best Practices" document for an entire document so if any of you have time to look over it, could you please give me some feedback regarding how it should look like. Becky: This is the document that is part of your working group page right? Hadi: Yeah! Ken: Is the right property "labelby" or "labeledby". Hadi: I heard yesterday that Jon and Becky were discussing this, I think I heard Becky say it was "labelledby" with two "l"s. Becky: Right. Two "l"s. The only thing you might want to put under [Treeview] Keyboard Navigation is something like what we did, which was "left" will move you up to the parent. But first it would collapse [its children] and then move up to the parent. Ken: Will it always be the "Enter" key that toggles between expand and contract? Maybe I am remembering incorrectly, but wasn't space also assigned to expand and contract? Hadi: I think you are right. Pressing space would move "selection" to the "focus" and if you then press "Enter", it would trigger the grid view for that specific mailbox. Ken: That is the way it is working on Don's example. Up and down arrows to move between. You can collapse or expand using right or left. And using the "Enter" key also toggle collapse and expand. Hadi: That might be very confusing for a screen reader. Mike: I think we talked about that based on kind of mimicing the existing functionality on some of the examples we were looking at. I think if we do find some of the redundant behaviour too difficult; if it becomes confusing, we might consider scaling back on some of them. Hadi: If I am not mistaken, Ken, that "Enter" key opens or closes the folder, but I cannot be easily determined what the state is. Ken: I don't think that is something we talked about in very much detail, but visually it has a folder icon in front of those nodes and it is going to have two states, corresponding to open or closed. I think in past approaches you would think of having an alt or title text on that icon that would tell you the state, so that the screen reader user would know. But I don't think we did not discuss that specifically when walking through our example. Becky: In my examples, where I have trees, I have no "alt" text because when you put focus on the actual title, it would say that. Ken: Really, whether it is implemented with "alt" text or some other way, the bottom line is there really needs to be some way to communicate the state of that. Becky, is there an ARIA state that would correspond to open or closed condition or state on a tree. Becky: On a tree you can have expanded true or false. Ken: Okay, there you go, expanded. So, as long as the screen reader can get that information it should be able to identify the state. Becky: Actually, we do put the "alt" text in, am sorry, but I marked that as presentational because if the images are turned off, then they will know why that blank space is there. And then if you mark it with a role of "presentation" it will not be spoken by the screen reader. Hadi: I have observed that sometimes screen readers try to be too smart or get the user in trouble because they convey information that you did not want or they tell you information that sometimes is not correct. One thing that I would personally would like to see in future webmail applications is that we have at least one clear way, not multiple ways, to perform the same job. For instance, in this specific example that we just talked about, if the enter key can toggle that, between expand and collapse, and we have assigned to left arrow key the functionality to collapse and expand, then adding the enter key to do the same thing will make the user more dependent on the screen usage a screen guesses. Ken: Some future screen reader would definitely know what is currently selected. It wouldn't have to be guessing. Becky: Generally, that is what happens right now. When I have a tree, and I tab into the tree, you are on the first element and will read it. When it gets focus, it reads it and it will tell you the state because I have put the state in. I know when I am first there if it is expanded or collapsed. And if I hit enter it will tell me again, "Antartica, expanded" and then after "expanded", it will tell me how many items it has. Ken: Becky, out curiosity, what combination of screen reader-browser do that. Becky: Firefox 1.5 or later; Window Eyes 5.5 or later; and JAWS 7.1p. JAWS eight does more with the roles and states than earlier basic ones. So, you would hear when you press "Enter" in which state it was. Whether it was expanded or collapsed. The same thing with the left or right arrows. It would be spoken. Hadi: When you use a screen reader every day for all sorts of tasks..., I just wanted to avoid potential guesses. That it doesn't have to read again. That when I press right arrow key, I know it will expand that. When I press left arrow key I know it will close. I do not need to rely more on the information that the screen reader will tell me. Becky: Okay, I see. So, that is why you might not like it have the left arrow key move up to the parent. First it will have to collapse it, and then it will move up to the parent. So you will have to press it twice to... Hadi: Correct, to change it back. I don't have a problem with that, but the fact that when you hit enter the screen reader will tell you that you are on "tree view and you are three levels down" and gives me five other information that you do not need at the time. You only need to know if it is expanded or collapsed. Mike: A screen reader could always choose to use a left or right arrow key exclusively if that is most clear and easiest. I think we only talked about having an "Enter" key because that is the default behaviour we saw existing [on the various email clients we looked at]. We might not decide to use both, but even if we did, having an "Enter" key that enables you to toggle, that does not prevent you from using left or right arrow key exclusively to expand or collapse. Hadi: On the face to face meeting that we had, I didn't know that space bar does not trigger a link. I thought it was the default behaviour of the browser, but I found out it is not. These kind of issues become a problem when communicating. Becky, do you see the four major components that I listed there: Grid View, Tree View, Address Book, and Controller/Wrapper? Can you think of any other major components appropriate for a webmail application. Becky: Maybe a "Preview Pane". I am not sure if that is not necessarily a separate component, but you will need some navigation to move between that and grid. Because your address book might be on a separate task pane. It might have different tabs. Like reading mail in one, your address book is in another, your calendar is in another. You might not think of that as mail though. So including calendaring and scheduling might be going a bit too far. Hadi: Let me ask Sre. Google is becoming one of the most popular web clients. What other stuff do you think will be included in future webmail. Sri: I think we talked about access keys in the past. The basic HTML interface doesn't work very well, but it more user friendly than the regular interface. The regular interface is quite complex and is hard for you to navigate through it using a screen reader. Some of the fixes will potentially be added in the basic HTML interface. Right now I have an issue at hand. How do we solve this problem? Do we go an put all the fixes on the basic HTML interface, where your choices are limited? Or do you go fix the regular interface and there you can do many things but there you are adding a lot of wait to every using that is using the gmail pages. Hadi: Yeah, but in terms of the components I talked about, Address Book, Tree View, wrapper that connects all these things together, in a web environment for example, how do you envision that. For example if you add a calendar component to that, should it come as an individual widget? Becky: Yeah. I am thinking ahead. It should be a separate thing. Take for instance Calendar. Calendar for me is a separate task, so Calendar should be a separate application that you show on the same page. Hadi: Okay. Jon, are you still working on your example? Jon: I was using the setAttribute DOM function to add .style.className with capital "N" but... Becky: Oh, it's... Mike: No .style. Becky: Right! It's either object.className or object.style.element of the class. Mike: Right class is a property of the [element] object not of the style object. Ken: Hadi, since I wasn't at the face to face meeting, can you tell me what is the wrapper/controller envisioned to be? Hadi: Consider you are in tree view and selected a specific folder, and then if you want to move to the grid displaying the list of emails in that folder. Some widget needs to take you from the present state of tree view to grid view. By wrapper/controller, I meant this. We really did not discuss this in detailed. We just mentioned that we needed some individual widgets to connect these things together. Jon: It works on IE! Thanks Mike and Becky. I guess you have to know the secret code! (http://www.cita.uiuc.edu/software/mozilla/test/dhtml/grid/grid-1.html) Becky: Space is doing something weird. Jon: Yeah. when you hit the space bar it moves to the bottom of the page. Hadi: To summarize our actions for our next meeting, Jon you and Don wanted to write down you questions pass it to the ARIA group and the PF working group. I don't know to which one you wanted to send it. Do you think by next meeting you will have some responses from them? So that we can put on the meeting agenda or not? Jon: I doubt it. Hadi: For Next Meeting we will have Mike talk about the address book. I would very much would like to have your input on the Best Practices. As a kind of homework, if you come across anything that you think is useful for the Best Practices send it to me.
- Please contact Hadi Bargi Rangin (e-mail: firstname.lastname@example.org) to be added to or deleted from the discussion list
- Discussion list archives
IRC Server and Channel Information
This will provide a means to share information during a teleconference and see the minutes in real time.
- Server: irc.w3.org
- Port number: 6665
- Channel: #webmail