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-22

Time: 1:00 PM CST

Agenda

Minutes

Minutes WebMail Accessibility Interest Group 02/22/2007

Attendees

Next Meeting

Reference Documents

Discussion

Hadi: ...how many of them we want to support. What is your take on that matter? Julio, earlier I was talking about unknown features of webmail. Features that are not known to me. Based on my conversations to the group, I always get description of those nice features that you are using or will be using. Thus, I end up modifying keystrokes [referring to our Best Practices documentation] frequently, and still I think there are features we are not covering. What I wanted to suggest is that we go over the [Best practices] document and revise at least the stuff we have covered and which we want to support. If it needs some modification, we can add to it or modify it as we go.

Jon: I agree. I think that is what we should be doing. We should go over the Best Practices document and make sure we have concensus in that the document reflects the working group ideas. Right now we have a document, so we should start going through it.

Hadi: If you could please open the Best Practices file on the we and go to the Grid View Section. I would like us to go through all of those commands and talk about them. My undestanding about some of the features we use are a little different. I thought they would be supported but Jon tells me they are not supported. For example, I was thinking to use the application key on a column of a grid to apply applicable functions. But Jon tested a few web applications and it seems none of them are supporting that. I guess I was completely off on that point.

Matt: Could you be more clear on what features you are talking about?

Hadi: Could you go to the best practices document?

Jon: I want to talk about the Best Practices document. I would like us to start going through it, as opposed to going back and forth on terminology. Maybe that way we can move ahead if we start defining the terms as we go and identifying them. I think the main thing is that we have a document and we can start going through it and see if people agree that [it describes] the functionality that we have been talking about.

Hadi: I also agree on the terminology point. Sometimes I make up some terminology here that I am really not correct. On the Grid View Section of the Best Practices document, the first key strokes I cover are the "tab/shift tab". Since the functionalify of these key strokes are essentially the same I tried to merge them together.

Jon: The headings are indicating key strokes. The first one is "Tab/Shift Tab". So this is basically moving into and out of the grid control itself. Then we have the behavior:

Then there is a bunch of remarks. One issue here is with the Grid behavior [as explained] in the remarks section: "some email programs move you to the first unread email when you come into the grid." The other issue is, I think this is another definition thing we have here, the first cell. In the current model of the grid we have the concept of a row and the concept of columns in a row. I think we need to define in terms of an ARIA application. How that works is that with the current grid controls we now, we have focusable tab index on the TR element. So, do want to move focus to the TR element to highlight the whole row, or do we want to move focus to the first cell in that row. The typical behavior, like in outlook, is to go by the entire row. Or if we do want to go to the first cell, what is the purpose of going to the first cell? Do I make sense to anybody?

Hadi: It makes sense to me because we have been discussing that. We wanted to preserve or support the feature to be able to move left and right on the cells of a row.

Jon: Right. Right now what the grid control does is if you type the right arrow key it does move focus to the grid cell in the first column, and then it goes across. And then if you type right or left arrow, it continues to move focus to each of those grid cells.

Hadi: Jon, I always had the idea that [the email listing/grid view on] a webmail application should have that checkbox associated with [the first cell]. But Mike explained last time that does not have to be that way.

Jon: Probably a lot of webmail applications will not use the form input control. They will just use some styling technique to indicate that it is selected or not selected.

Hadi: Okay, but we enter a grid; when we go to a row, we know that a row [is being] selected. How do we know which column of that row we are in?

Jon: You are not in any column. Your are just in a row, and the whole row is selected. And then if you want to go to individual columns, if you type left arrow, it moves focus to the first column, and [ if you keep typing left arrow it will go to] the secod, third, fourth, etc. And then you can go back and forth. And then if you want to re-select the entire row you type "control+space bar". I guess the way that works operationally for me on the ARIA specification is that if you say the whole row is selected, then it[screen reader] read the whole row. If you say a cell is selected, then it just read the information related to that cell. That seems to be the fundamental feature of the ARIA specs. That whatever you give focus to, the entire contents of it are initially read. I do not know it that is too general or not, but at least maybe on a grid setting, where as if you just move the focus to a specific cell, just the contents of that cell will be read.

Hadi: Okay, then what will happen if we leave the cell and come back? Consider that I am currently in a subject cell or subject column of a specific row.

Jon: It should restore it to whatever state it was in before [you left the cell].

Hadi: When I come back, I am now exactly on the subject column of that row?

Jon: If you moved focus off and then you move focus back, if a row is selected that is the same row of the specific cell, then that specific cell is still selected.

Hadi: One thing that I see as being inconsistent is that when we enter for the first time, if I understoond you correctly, you said that the focus is not on a particular cell. It is just on the entire row. I have to press right arrow key at least once to land in the first column.

Jon: Or if you want to read the first column. Otherwise, if you put focus on the entire row, then it just reads the row's contents in document order from left to right.

Hadi: Yes, but my problem is, why for the first time the cursor [meaning focus] goes to an entire row without being on a particular cell while in the second case when you are in subject cell or subject column of a row, when you leave the cell and come back, you land right there?

Jon: It depends on when you left. When you tab out of the grid, what was the last thing selected or containing the focus? When you come back, it will still be the row that has focus. If you did navigate to a particular cell, that cell will have the focus. It depends on what state the grid was in when you left it.

Hadi: Do you see any problems if for example we say that [initially] by default [the focus] should land on the first cell and still [interrupted]...

Jon: But then you are saying that you are going to read that cell. By putting focus on that cell you are saying "I just want to read that cell", and you will not get the rest of the row. Unless you are going to write a bunch of special rules.

Hadi: You are looking at it from the perspective of implementation, while I am looking at it from the perspective of a screen reader user. Okay, is everybody clear on that point? When we enter the grid for the first time the cursor does not focus on a particular cell; just the selected row. You can use the left and right arrow keys to navigate to a particular cell and leave the grid. Then when you come back you will land back on the same cell as you were before you left the grid.

Don: That sounds good to me.

Jon: Or row, if the individual had a row selected. Most people will only use row selection with up and down arrow keys.

Hadi: Just to clarify, I am on the subject cell or column and leave the grid and come back.

Jon: Yeah, then [the focus will be] restored to the subject column on whatever cell you were last at. Or if [the focus was on an entire] row, then [when you come back, the focus would be in] whatever row your were in. I think the fundamental issue here is whether or not that is something we want in the ARIA behaviour. Should the contents of whichever element has focus should automatically be read by the screen reader? Is that the behaviour we want in general?

Hadi: I would say yes.

Don: Yes.

Hadi: As most of you know, screen readers usually have a verbosity mode. Based on the verbosity mode of the application that you are in, you can configure a lot of stuff. I was wondering if we should leave it up to the screen reader to determine how much information to deliver as you navigate a row or column? For example, a cell only, when you are navigating from cell to cell, or the cell and then repeated by row or reverse order or whatever? All these stuff are usually configurable.

Jon: I think that in terms of verbosity level, what it would be doing is provide supplemental information. So at the highest verbosity level, when it went from cell to cell, I assume it would read the column header. For example: "Sender blah blah blah. Subject blah blah blah". With a lower verbosity mode, it would just tell you the name.

Hadi: Yes. In advanced mode it just reads you the contents. Any question or comments on that matter please feel free to speak up, or we can go to the next keystroke item.

Jon: So, are we going to specify in there that if the verbosity level is high, then if you select content and there are "describedby"s or table markup that indicates headers for that content, in highest verbosity mode, should all the content be preceded by the descriptor?

Hadi: Based on my work with the JAWS Beta tester group, usually the tester defines what should be read and what not. We can define that [on our document], but I am not sure it is something that [others] would follow. I think we can suggest to them as a possible behaviour, but it is up to them to follow that.

Jon: Is that something that other people would like this group to define as part of our best practices?

Don: I am not a screen reader expert, so I could not answer that with any authority.

Jon: I think it is important from a developer stand point, so they undestand that if they use a certain type of markup, how it will impact on the user. SO that if someone used the describedby on two paragraphs they would know that someone using high verbosity mode would have to listen to two paragraphs worth of stuff just to find out what is on this thing. I think including it provides everybody more information on how to design for accessibility. I think right now what I see too much of is "What does JAWS do?" or "Let's tweak or code to see if we make it work with JAWS better." Where as if we have a specification, that says, "OK. This is what a screen reader is supposed to do in this situation...", then things become more predictible and we get interoperability. Otherwise we just get "Well that screen does that, and that other one does that. Since most people use that screen reader, let's just design for that one and we can just forget about the other one."

Don: So, do you think there should be special notes for AT(Accessible Technology) vendors?

Jon: Yeah. If we do not tell them, then they will do whatever they want to do. Maybe they still will do what they feel like doing, but at least we are telling them what we want.

Hadi: Yes but now, Jon, what is the difference between the information that goes in a describedby and a caption? What do we want to suggest to them? How do we want to address that? What information should go in describedby?

Jon: We also have another issue. What happens when we have redundant information? In our grid we could use table header markup. We could use ids and the headers attribute to describe the purpose of a specific grid cell. But what happens now if I also have the describedby attribute? Who wins? Does the describedby always override other mark up?

Hadi: I cannot comment specifically on the describedby attribute, but other ones like ALT ant TITLE, screen readers usually allow you to configure which one should be read, or both, or the longer one of the two, and you can combine it with verbosity mode and you find yourself in a very complex area.

Jon: So, that is life for someone who knows a lot of screen reader and markup, but what about John average screen reader user who does not even know how to change any of those settings or what they would mean?

Hadi: As long as technology [improves], my persnonal view is that people should get more educated about the Assistive Technology that they are using. It is the user's responsibility to advance his/her knowledge and understanding of their Assistive Technology.

Jon: What do other people think? Where do you guys think we should go with these Best Practices [document]? Do you think we should be specifying behaviour that we want for screen readers? At least, default behaviours?

Matt: I think it is a perfectly reasonable thing to do. And then also with the verbosity issue and things like that, if we could, without making very specific recommendations; just examples of desired behaviour that are possible. That would be good. But I think the default are a good idea to describe. For example, if you land on a row, do you read all the header information of the cells within the row? Those behaviours are good to describe. I am like Don. I am not an experienced screen reader user myself, so I am a little bit shy about answering some of these questions.

Jon: I think it is great when people understand. But I guess I am always concerned about like, when I work with students on this campus, a lot of our screen reader users could never do it. It is one thing to say "well, that is your problem". So what they do is basically they accommodate themselves on the technology. So I am also very sensitive to issues to "how do we make this technology easier to use?" because it is nice to say, "you should get better" but a lot of them will not. And basically then, their opportunities are going to be limited.

Mike: I would whole-heartedly agree. Probably, as with any software, you see the majority of users are using only a fraction of the most default behaviours. Issues like what a screen reader can do may be relevant if the user typically does not undestand how to do it.

Jon: I think the biggest problem we have with accessible design all the time is that nobody understands how any of this stuff is supposed to work together. I think that is an imporant part of what this group, or at least what I wanted to get out of the group, is that we get some sense of how all this works together to make the web much more predictible.

Mike: I agree with that one too. Just this week we practically had to reverse engineer a screen reader to figure out how it was handling certain dynamic behaviour and it was very frustrating not to have something predictible. If we can help the screen reader manufacturers to at least have a recommended set of standard behaviour, that would be a big help from a development standpoint.

Jon: At least standards compliant mode. I know screen readers have to be a very strange things because a lot of people do not pay any attention to accessibility. But just like Hadi has different modes, if people see that there is different ARIA markup in the document, then they can do something different than if there is no ARIA markup. I think that is up to the screen reader developers, but at least we want to have some standards-compliant mode. I guess people could configure their screen readers to not follow "standard-compliant" mode on this page because whoever was putting together the accessibility markup on this page did not know what he/she was doing. So, give me your best "repair" or whatever. Which it probably would have had to do any way if there is no ARIA markup.

Hadi: So, we want to give some general recommendations for default settings. I personally believe that we cannot prescribe that "under this condition, do exactly that." But we can recommend some default behaviour.

Matt: Yeah, I think that with the grid; with a specific control it makes sense.

Jon: I think we have two level of things. I think we have some general ARIA stuff. There seems to be some concensus today that when an element gets focus, a screen reader should read all the contents that is contained within that element. Probably another pre-cursor is that when a new element get focus, it stops speaking whatever it was speaking and starts to read the new content of whatever got the focus. I think the other basic principle that is not specific to the grid, is if you have conflicting markup. For example, with this grid control, if you have table headers information and a describedby, what should be give priority to the screen reader to use, at least initially to read out? The describedby, because it is above and beyond the HTML markup. Based on our previous conversations with the PF group, you should only use ARIA stuff when there is not equivalent HTML markup. So, by putting in the describedby or labeledby, you are basically saying "I have a problem with the current markup here. It is not going to do what I wanted to say, so use this label instead.

Hadi: Can we for example say "use describedby if you are not using tables for layout?"

Jon: No. It more like if someone is using table layout and for some reason they have header and id information. Based upon what I want read by the screen reader, I do not want it to look up the table information. I have this particular label that I think would be better for people to read; to have read at least with the default mode. Does that make sense?

Don: Yes. It does make sense to me.

Matt: Yes, it makes sense to me too. Althoght, the part about using the ARIA only when there is not equivalent HTML markup is news to me.

Jon: Again, we are trying to develop Best Practices that help make things more predictible for developers and give developers options. One option is you can tell the developer not to put any table header information, but maybe they have a code-base that they are just modifying. That is a big part of the ARIA specifications. They are supposed to be able to be used when there is an existing code base. So, if someone has a lot of libraries, instead of having to take stuff out and add stuff to them like table header stuff, or fix table header information, you can just put ARIA stuff which is supposed to be just "additive" as opposed to "changing" to make things better, or to make things more accessible.

Matt: From a development point of view that makes sense. It makes it easier for the engineering side. The way I hear it is this is the way to augment your code. To make a lot of changes.

Jon: Well, that is one of the uses of the ARIA specs. Since there is a lot of code out there, we expect it to be used that way for a long time. We do not expect people to re-write it if they can just add stuff to make it more accessible, which may be a much more doable task.

Matt: To me the Best Practices has to aspects. One is the user experience when they use the system with the grid and stuff. The other aspect is the implementation recommendation for how to do this stuff.

Hadi: Okay, moving on to the next element, "Up Arrow" key. If there is any row above the current row, the current row will be deselected and the new row will be selected. When we reach to top-most row, you stop there and the screen reader will tell you "no more roww" or whatever, depending on the verbosity it will give you some instructions on how to get out of the situation.

Jon: So if you are in a column though, it just move you up to the cell of the previous column.

Hadi: Correct. And depending on the verbosity, it would read either the content of the cell or a combination. The entire row until you are at that cell.

Hadi: But the main thing is that on a real email program, you cannot fix your display area. I came up with the term "display area". What term should we use to say for example, "display ten emails at a time". Is there a terminology for that feature?

Matt: At Mirapoint we talk about the number of items per page. We talk about page view, but it is confusing because a refresh of the page will bring the next set of messages. So we refer to is as paging.

Hadi: What about you Don?

Don: We also use paging.

Jon: Yes, but Arrowing up has nothing to do with paging.

Hadi: Correct. I just wanted to say that this is like regular email for an application like Eudora, as opposed to a web-based client, where you can view an email when you arrow up. If there is an email [above the current row or cell], it would show it to you.

Matt: Actually that is a good discussion to have because we [at Mirapoint] are trying to shift from having a paging model into, I would argue, into the future model for web 2.0 type of experience to have. Basically get rid of these page views and have a continuous scroll. If you get to the top of the current view or page, it would actually go to the next item that it is out of. Which is how Outlook and a lot of other clients do it.

Jon: Do you think that is going to be the general trend? To move away from this pageviews?

Matt: They did at yahoo. Gmail - I am not sure what they do, but I think they will. Because of some usability studies, I know that it is more difficult for screen reader users to have to deal with page views.

Hadi: It makes sense, since [with page views] you have to redraw the entire screen.

Matt: When you are trying to find something that is in the current view, but it is scrolled off the page. The question is how many rows to display vs. less than a page view and then have to scroll down to get to the next item, even though it is in the current page view.

Don: From our point of view, we are just trying to launch a low-bandwidth product to be launched in India. The dial-up situation there is such that we have to be careful how much content we deliver at a time. So, we are going to use a paging scheme that allows a user to set up preferences as to how many [items] they might see on a page.

Hadi: For those of you who are familiar with Emacs in the UNIX environment, if I am not mistaken, sometimes when you arrow up you do not just view the most immediate row of the entire page. If for example your webmail displays messages 11-20, and you are currently at message 11 , which if your first message on your paging area. When you arrow up, do you then [move up just one message and] show messages 10 through 19, or do you show the previous 10 emails, 1-10?

Don: I think that is a good question. I cannot speak for Emacs. My guess is that our normal webmail product probably is not Keyboard accessible at all.

Hadi: Matt, how does your company want to approach that? Do you want to just show the previous email or the previous ten?

Matt: We are not currently doing what you are asking. We use the page model. It would just jump to the previous page. It would not fire a page at all. It would not overlap. If I was to do what I call "Continuous Scroll Model" - scrolling across page views - then I would probably want to keep the previous item which you currently just scrolled off from visible, but you want to go to the next set of items. So I would actually fill 11 at the bottom, but 10 is the new item with the focus.

Jon: So it is like a select box. Where you always see a certain number of the items in the select box?

Matt: Yeah. You would have a limited number of items on a page view at a time.

Hadi: Do you think it is an accessible feature? Is it possible to make it accessible some how? Or should we require that a webmail application offer that paging model?

Jon: I do not think it is impossible to make it accessible. Basically it is just going to be a matter of moving focus to the new item. That will indicate to the screen reader to read the new item. I do not think accessibility is going to be an imposibility. It is just that there are going to be a lot of things changing on the page. I do not think that making recommendations like "do not have that kind of behaviour" are going to go anywhere. The new ARIA specifications have to handle these features.

Hadi: It is not only the email that changes, but some other relevant information like which email range is being displayed, say emails 10-19.

Jon: That is why we need the markup to specify what things are labeled by. So we have markup that indicate the new information. Maybe we need to mark that up on our current grid control or that kind of behaviour. We should look at what is available in the current ARIA specification. Especially if you are saying that this is the direction that webmail applications are going.

Matt: I just wanted to add that it is possible that in the future we will support both models. Especially for low bandwidth. I do not think one [model] necessarily precludes the other if you want to have that feature in webmail. It is kind of an implementation or design choice by the designers of the webmail on how they want to handle that.

Jon: I think that kind of situation is going to come up in a lot of other places too. I think this scrolling listbox type of information is not just going to happen in webmail. It is going to be in a lot of other places too. It is like a multi-column select box that people are going to throw at us in HTML.

Hadi: Moving on to the next item, "Down Arrow". I think it would just have the reverse functionality, so I do not think we need to spend too much time on that. So, let us move to "Left Arrow". We said that when we enter the grid, the focus will go to a row based on the configuration. Jon, you were suggesting that when you arrow right, the focus goes to the first set.

Jon: This is something that I felt the group did not have much concensus on. Are you saying that you do? Since web applications that are higlighting a row at a time, basically that is the only thing the current tools allow keyboard support with. Mike, I think you were talking about the web-based version of Outlook. That it supports the keyboard to allow people to move focus between rows?

Mike: With the arrow key you go up and down between mail items.

Jon: But there is no functionality to move right or left to move between columns.

Mike: No.

Jon: What I got from the PF group is that they did not see that as something that developers should have to do. If are going to say this, then are we saying that we want more for accessibility than the current thinking, at least from the current people doing the ARIA stuff. It we think it is important, I think it comes back to the usability issue because we do not want people to have to learn keyboard commands to be able to read column information. I think that is the primary argument. So, what is the feeling on this left and right arrow keys? The current grid control example supports that, but I do not think the group has ever said "Yeah, this is something we would want to see in the Best Practices."

Hadi: I think it is a very useful feature to have.

Mike: From my experience, working with some older client-server applications with a grid-type construct, the ability to read the cells individually is virtually essential for all but the simplest of lists. I think the question is "What should be providing that? Should it be the application or the screen reader?" If screen readers did, then maybe we would not be even having this discussion whether or not it is necessary. But then again, maybe it is that Holy Grail between Forms mode and Virtual mode.

Hadi: And you know that once you go into virtual mode, then navigation becomes really difficult. When we are working on a grid view [type of page and your screen reader is currently] in a forms mode, we can move row by row. But if you try to do so with a different [screen reader] mode, then we will not be able to utilize that feature.

Jon: Say that again Hadi.

Hadi: At this time, when we want to use the grid we have to be in PC mode. You cannot use the virtual mode when using JAWS. And I guess that with Windows Eyes is similar.

Jon: Since ARIA is still being implemented, both, by web developers/browsers and by assistive technology people, I do not think we should dictate necessarily what we think JAWS would do in a situation based on what it does now. I think we can document what JAWS does now based upon what we think are Best Practices and what we would want changed. I do not think we should try to design what we are doing for what JAWS does now.

Hadi: Based on the current features that I see, the future webmail is such that, for example, if clicking on a subject triggers a function, which is different from clicking on sender or date, then if different functionalities are associated with different column sets, then we should provide the appropriate navigation mechanism that would be supported by a screen reader. Virtual mode is not the right way to go with. So, my suggestion is that we recomment the current implementation that we have. The ability to be able to navigate from one cell to the other so that one would then be able to press some application key and trigger a function from the cell.

Jon: I have to leave for a meeting.

Hadi: I do not undestand all those features that you are seeing on various webmail applications. If someone could help me, maybe I can call you offline and maybe do some testing together. For example, Jon was telling me that on Google mail JAWS was speaking the subject line, something happened, and he clicked on the sender and it hid the sender information. These are different functions from traditional email applications.

Don: Hadi, is there any help in that Google mail that tells you what all that does?

Hadi: No. I cannot even use those features. I talked to Sri about it. I cannot even change my preferences when you are in basic HTML mode, much less in standard mode which is not accessible.

Matt: I was playing with it Hadi, just a little bit, and I found that there is a setting in the preferences page to turn keyboard shortcuts on. By default it is off.

Hadi: Even if I want to go to preferences, I have to use standard mode, which is not accessible. When I am in standard mode, I cannot click on any of that stuff.

Don: Guys, I have to run to a meeting. This has been good. I suggest next week we pick up where we left off.

Hadi: Okay. Thank you everybody.

Resulting Questions

  1. Based on the fact that ARIA specs should be used only when no HTML markup is present, for those who might choose to represent a grid as a table, is a grid defined as a "perfect" m by n matrix? In other words, are Rowspans and/or colspans disallowed?
  2. Otherwise, what would be the behaviour of arrow keys on spanned rows/cols?
  3. The "Up Arrow" section states that "The focus moves to the immediate row above and selects it. The previous row is deselected." Is this specifically referring to implementations where no checkboxes are used (as in Outlook)? Otherwise, does this mean that if a checkbox for the current row is checked (and consequently, the current row is selected), arrowing up "unchecks" the box and deselects the row? I doubt this is what you meant, but the terminology might mislead some users into thinking that "deselection" is the same as "unchecking".

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.