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: 2006-10-19

Time: 1:00 PM CDT


1. Organizational stuff
2. One single guideline for all!
   * currently no guideline for Web 1.0
   * Members started working on assigned tasks
   * Wait until we find out what direction we are going?
3. Continued discussion on Web 2.0
   * Homework: Review W3C Accessible Rich Internet Applications (WAI-ARIA) Working Drafts:
     - Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) http://www.w3.org/TR/2006/WD-aria-roadmap-20060921
     - Roles for Accessible Rich Internet Applications (WAI-ARIA Roles) http://www.w3.org/TR/2006/WD-aria-role-20060921
   * Web 2.0 example (Jon):
     - http://cita.uiuc.edu/software/mozilla/test/dhtml/grid/grid-1.html
   * Today's AJAX and DHTML Best Practices (Ken):
     - http://www.access-matters.com
   * Web 2.0 Accessibility Features (Srinivas)
   * Examples on Telerak.com (Mike)

Teleconference info:
Date: Thursday October 19 2006
Date: 2:00 PM EDT; 1:00 PM CDT; 12:00 PM MDT; 11:00 AM PDT
Phone: 217 244-7532  

IRC Server and Channel Information
Server: irc.w3.org 
Port number: 6665 
Channel: #webmail  
WebMail Accessibility Home Page:


Webmail October 19, 2006 Notes:
By: Julio Chavarria

Hadi: I would like to welcome everyone and also all the members who join us for the first time. I would like [to ask] that if possible that you go ahead and re-introduce yourselves for those of us who do not know you. 

victor: OK. I will start I guess right? My name is Victor and I am from Yahoo. I have been kind of exchanging email with Hadi for ages. Probably a thousand years, but is my first time to join. I Lead the accessibility effort at yahoo, which is very easy to put in three or four words. Actually it is easy to put it in one word. Basically everything that deals with accessibility is under me. That's it. 

Hadi: Welcome to the meeting. I am very glad that you finally made the time to joins us. 

Sri: You can just call me Sri. It's supposedly easier. I am in the webmail thing. I am in the mountain view. We have started looking at accessibility issues recently. I work with Don and Victor.

Hadi: Welcome on board and thank you for joining us. Just to give you an idea who also is on the phone, let's all introduce ourselves. I am Hadi
Rangin, at UIUC. I work with Jon Gunderson in improvements of accessibility of web-based systems at UIUC and also with companies that work with universities.

Jon: I am Jon Gunderson with the University of Illinois at Urbana Champaign. I'm in charge of IT Accessibility on campus.

Hadi: Everybody knows Don. How about Julio and Ken.

Julio: Hi, I am Julio. I am from the Great Lakes ADA Center here at the University of Illinois at Chicago. I am the Network Analyst. 

Ken: Hi, I am Ken Petri. Director of Web Accessibility Center at Ohio State University.

Hadi: Based on the conversations I had in the past days with some of you, I thought maybe we should revisit our strategy regarding our team effort to develop a single guideline which would answer all questions for accessibility of Webmail applications. The question is where we do not have any guideline for webmail Web 1.0 is it really the right step to go ahead and work with Web 2.0? And then, I
also wanted to raise the question if one single guideline can answer all questions for Web 1.0 and 2.0.
I want to say that I have received all your comments and drafts. From Victor; from, I guess Ken; from Matt, from Julio. And also Jon and I worked on some tasks. I have received them but we got involved in the Web 2.0 discussion and put everything on hold and I would really like to know whether we really should continue our discussion of Web 2.0 and come up with a general, one single solution or should we develop our guideline for web 1.0 and once we are done we can address Web 2.0?

Jon: From previous discussions, most of the people on the call were developing Web 2.0 applications. From previous telecoms, I thought one of the things we where trying to do was What are the things from Web 1.0 that still work and what are the things from Web 2.0 that will work.

Don: Let me quickly, if you don't mind just a quick opinion. I think, obviously the industry is moving towards Web 2.0. There is no question about that. And by industry I mean portals like AOL, Yahoo and Google. There is definetly... there is no way back, and so the light there, to me is pretty clear where it is going. I think Web 1.0 will still stay in sectors which are bound to comply with section 508, like Government Agencies. I don't think they will be switching to Web 2.0 for a while because there is no presedent to make it compliant with section 508. If we wanted to go with these two routes, we will probably need to have separate guidelines for Web 1.0 and Web 2.0. Web 1.0 to me it seems like it is a bit easier because it is essentially a web guideline that already exists. Web 2.0 is a bit more difficult because some people on this call are participating in our efforts to try to even standardize Web 2.0 accessibility itself. So, I just feel that it will be a little bit difficult for us to standardize our webmail guidelines with regards to Web 2.0 if Web 2.0 Accessibility itself is still being standardized. That's kind of the way I feel about it. 

Victor: Yeah. In fact I tend to agree. I would even go as far as, Don, by saying that the interest level for my participation is strictly for Web 2.0. Web 1.0 applications tend to be more web-based like. Where Web 2.0 tend to be more actions and events. Transactions going on in the background. In fact I would say that Web 2.0 would deal with Web 1.0 accessibility issues such as keyboard shortcuts and font resizing, etc, etc. If we were to answer accessibility [issues] for Web 2.0 we would be answering the 1.0 as well, with it.

Don: Well, some of it. I don't think all of it because the semantic markup will probably be less relevant, I think, to web 2.0 than it is to web 1.0. Don't you think? 

Sri: Can you tell me what semantic markup is?

Victor: Well, I mean like using headings and proper lists and things like that. Once we move to 2.0 we are actually getting closer to software-like behaviour.

Jon: Right, but I don't think that precludes using structural markup. I don't think it's throwing out all of our Web 1.0 techniques. I think what we are doing here is trying to figure out what are the 1.0 techniques that still work. Where do we need a 2.0 technique and where is the overlap? What are the 1.0 and what are the 2.0 techniques for some of the task requirements? So, I don't see it as all 1.0 or all 2.0. I guess I want to try to find the intersection here between the two and where do the things then... I guess also, since these guidelines are still under development for 2.0 stuff, we want to make sure that whatever they come up with is going to work for us in webmail applictaions. That there is a good mapping and it is clear what should be used.

Hadi: But Jon, don't you think that if we have one; a guideline for 1.0 it will give us a better idea when... compare it wil all those features in web 2.0. That this time we don't have anything.

Jon: I think we have a lot of things from 1.0. There is a lot of text... best practices documents. Again, I think it does not matter whether you are going to talk Web about 1.0 or Web 2.0. You have to define tasks and then markup behaviours that you want with those tasks. You have to look at our current guidelines for web 1.0. Where they work? Where don't they work? We can unofficially say we are not going to only take one way or another on a particular phone call.

Don: I tend to agree with that. Certainly Web 2.0 presents the greatest problems for us. We have a webmail software out there; a webmail client that is web 2.0 and making it accessible is very difficult. But I thankfully really started drilling down on the baseline. When I see it; when I think about it, I think in terms of: OK we are going to need a navigation tool. So, you typically, on email, you have tree view thing over here. Now, we can make that Web 1.0 and it can be made all with anchor tags. You can tab through it and that is certainly accessible. Or we can go the web 2.0 route and we can begin to use the new Firefox classes and rolls and we can make that thing... we are going to have javascript, keyboard accessible handdlers do all kinds of neat things. I really thing there is a place for each of the individual pieces of webmail. They take branches and go different ways. 

Victor: I just want to sort of add to that. It seems that there are certain applications... I know the we were considering things like chat and calendaring. Maybe this if getting off to the side of the issue, but something like chat seems like it is going to have web 1.0 and web 2.0 elements to it, kind of inevitably. We really can't separate the two things out.

Hadi: Julio. What do you think about this.

Julio: I agree with Jon. I think that we need to consider both 1.0 and 2.0.

Hadi: First find intesection and then...

Julio: Right. I agree with that. No matter what, it is going to be difficult to implement because, basically the standards are a moving target. I think now is the time to consider it. 

Hadi: After so many years of having webmail on the web, or webmail programs, I personally do not know any single webmail program that would even come close to be called accessible. I don't know about you? What do you think Victor? 

Victor: What do you mean? What do you mean? Are you tryin to say that Yahoo mail is not inaccessible? ?

Jon: I think part of the [problem] too is I don't think very many development resources are going to approving Web 1.0 mail ?functionality?. Even if we came up with Web 1.0 only, there's probably not enough developer interest. Just from what I've heard on the call, "those would be nice, but let me know when you get back to Web 2.0 stuff and then I will start participating again.

Victor: I would agree with that. In fact I would like to add that even for me, being a developer who wants to convince a product manager or developer manager, it would hard for me to convince them to "take this, finished now, change it" into an older version of the product. It would be always easy to put in the changes in the next release. So going with that and where we stand in terms of the product technology being used, I would say that Web 2.0 would be an easy sell for anyone.

Hadi: Continuing our discussion with Web 2.0 and then about our homework (Read the  {Web 1.0 - 
} and {Web 2.0 - 
} guidelines). Hopefully everyone had time. Go to the documentation and got some idea about that. I read through them. Some of them are too abstract for me because I cannot see all those graphical representations of the new ideas. Even for those ideas presented in tables, I was not able to figure out how the different elements were connected. Does anybody want to give a five minute review on these [Web 1.0 and Web 2.0] documentation.

Victor: Yeah, I can give a quick summary. Essentially you would like to know more about this new DHTML stuff, right?

Hadi: Actually documentation about the roadmap...

Victor: Okay. To make it very simple, I think many of us use a software client, let's say like Outlook or any other mail application, whatever it is, on your desktop. The basic idea behind this proposal is to transform the same functionality to the web browser. So when your are looking at the web browser and you are using one of those new web mail applications which would be using this new concept, you will basically see it as if you are using a software client like Outlook. The idea actually is very simple because it came exactly the same route that web developers arrived at the idea of Web 2.0. They wanted people to have the same experience as they have on the desktop. But in order to achieve that, there needs to be a two-way communication. I will use a screen reader as an example because it's the most complex assistive technology tool. They can get some information from the browser, but there is no way for browsers to communicate something back. Generally, because a browser does not have a way of directly communicating with the assistive technology, what happens is that essentiall the screen reader doesn't know any thing. It doesn't know what happened. It knows that it is the active client and can ask for information from it, but it cannot receive information sent by the client if the assistive technology did not ask for it. The best way to put is that there is just a one-way communication. On the desktop however, if you do something basic like tabbing, it is automatically spoken by the screen reader. This happens because the Operating system has a way of communicating with the assistive technology via events. 

Hadi: Thank you for the explanation. The one thing I wanted to know is, in the road map, two Document Object Models (DOMs) have been compared, with each other. One using Javascript and one, I think, using standard HTML. 

Jon: I think the overall picture of what these documents want to do is that you have platform-specific accessibility Application Program Interfaces (APIs). People are creating widgets that are typically in Graphical User Interface applications. A lot of the goals in these documents is to allow people to map these HTML generated widgets with Javascript to these Accessibility APIs. So, what the documents are attempting to do is try to define the object types that people could use to map into these accessibility APIs. Another part of what the documents are trying to do is saying, "if we have these widgets, what accessibility APIs are they going to map into, depending on the platform, that browser is going to support"? 

Hadi: Thank you. Before we begin the discussion of Jon's example, Ken, can you talk about today's AJAX and DHTML Best Practices?

Ken discusses "Today's AJAX and DHTML Best Practices" article.
Referenced Articles: 
    Title:    Today's AJAX and DHTML Best Practices
    Author:    Bob Easton

    Title:    Making Ajax Work with Screen Readers
    Author: Gez Lemon and  Steve Faulkner

    Title:    AJAX and Screenreaders: When Can it Work?
    Author: James Edwards

    Title:    AJAX Accessibility Overview
    Author: Becky Gibson

Relevant Links:
    Title:    Dynamic Accessible Web Content Roadmap

    Title:    Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)

Interesting Links:
    Title:    Beginning JavaScript with DOM Scripting and Ajax

    Title:    WCAG and the Myth of Accessibility

Ken: It seems to me that they [refererring to the authors of the Referenced Articles, namely (Bob Easton, Gez Lemon and  Steve Faulkner, James Edwards, and Becky Gibson)] are not so much interested in what is going on at the WAI-ARIA initiative. They are more intested in what things can you do right now with current screen reader technology, their focus is really screen readers, to alert the screen reader that something in the browser has changed. There seems to be some sort of disagreement between the Gez Lemon article and the James Edwards article. The Gez Lemon article is a little bit more recent and he seems to say that if you can alert the browser that something has changed by using javascript to put the focus on an element that can take focus like a hyperlink, the screen reader will read the content of the hyperlink. There are a couple of experiments that James Edwards did along the same line and he sorts of disagrees. You can try using the focus. You can try using the link; the location tag, but the javascript notification of state change of the focus of the cursor do not work universally at least across the screen readers that they used for testing. That is sort of what their focus is. It seems to me like if you are going to talk about Web 2.0, your can either talk about Web 2.0 in terms of what is coming down the pike using WAI Roles and things like that and state notification, or you can, at least in the interim, use the techniques that are already out there that have already had a certain amount of success. Like trying to put the cursor in a location that can be read. So that when updated it, the screen reader can say, "the content has changed". My question would be, for people who are in the process of developing these things, is the focus in the industry right now, looking mostly towards the future and some of these new specifications that are coming down the pike or is it kind of a here now by others, efforts to use things like location or focus for notification? 

Don: I can talk a little bit about that. I think, from AOL's point of view, we certainly have a commitment to make things accessible now. My job is to look over AOL.com and everything linked to it, and try to make as accessible as I can. That means I really have to live in the world of here and now. At the same time I am involved in a lot of these ARIA and other things, and can see a day when things will get better. I am not exactly sure when that day will come, because most of the screen reader business don't do anything unless you pay them and I am not sure who is going to pay them. But to get back to some of your concerns, you are exactly right about the moving focus. One of the things we discovered was that, first of all you can move focus to any element you want to as long as you know how to do it. At least in IE and Firefox you can. 

Ken: The problem seems to be there. Though you can move the focus to anything, the screen reader may not know to read that newly populated element.

Don: That's correct. So one of the things we do is often assign the focus to a header. Just so JAWS, by pressing the H key, will move from one header to the next, will read it. So magically, if you move focus to a header, you can get JAWS to start speaking. We often times will also hide the headers off the visual field by moving them [via CSS] to -1000 to the left so they don't interrupt the visual elements of the screen. But, as an example, we have an RSS [feed] reader that has a tree view on the left with all the RSS feeds. You click on one to populate the content of the feed on the right with AJAX, and upon clicking on that link you then move focus to the header tag on the right, and then from there you can read the contents. That's a technique that has worked well for us, but in all honesty it is a hack. For one thing, I can tell you that the JAWS screen reader in version less than 8.0, and 8.0 is still in beta, they had a bug in the way they calculated the move of focus. They basically calculated it based on the character offset from the beginning of the file. So if you come along and insert a new node of DOM inserted content, suddenly their offset is not in the right place anymore and focus pops where it shouldn't. That has been fixed but will not be publicly available until the 8.0 version is out. [Refer to http://dojotoolkit.org/pipermail/dojo-accessibility/2006-August/000096.html ].

Victor: Many people come to thing that accessibility is this thing that is kind of set in stone. Can you make something accessible? No you never can make something accessible because they are a moving target. To me, as technology goes forward, accessibility will have to go forward too. Now, that means upgrading screen reader. That means a lot of little things that go with it, because, as unfortunate as it is, it is hard to satisfy JAWS 5.0, Window Eyes 3.0. When the technology that we are trying to server our users is not even capable to offer those hacks. And like Don said, the problem with hacks is that they are very difficult to explain to business people because they think, to implement this hack you spent this much time getting it to work. That means in two years you will probably have to retrofit and make the same work again. So, I agree with Don that we do try wherever possible, if doesn't always stretch resources, to try to make it work with screen readers, but I spend a little more energy in trying to make sure that we look forward to standards that are coming in the future as opposed to trying to create those hacks because sooner or later we want to have the same accessibility situation like we have in Windows XP. I wanted to stress the fact that if all of us people involved in this call, and people who can make this in their organiztion, were to stand behind a certain standard it would be, I think, is a way into the future. To me it makes more sense than trying to concentrate on suggesting people how to hack something. Because different hacks will be for different applications. If we stand behind certain standards, and say this is what we support and this is where we think we should be going, I think in the long run everybody will benefit from it. 

Hadi: Let's now go back to Jon. He has set up an example at 

Jon: Begins discussion of web 1.0 and web 2.0 features contained in page. It works only with firefox 1.5. [Refer to example link].

All: Agree for next meeting - Thurday oct 26, 13:00 PM CDT

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.