- From: Earl Johnson <Earl.Johnson@Sun.COM>
- Date: Sat, 31 Mar 2007 13:01:48 -0800
- To: wai-xtech@w3.org
- Cc: Yuta Yoshida <Yutaka.Yoshida@Sun.COM>, Dan Labrecque <Dan.Labrecque@Sun.COM>
Hi; Pointers appreciated if there's a better alias to ask this question on. We have an Ajaxified HTML table that only downloads a sub-set of the total number of possible data sets [rows] the table could call into the DOM. The Ajax component is a function in a prototype table that gets triggered only when the user scrolls thru the table. The movement of the scrollbar triggers he function to downloads 5 more rows to one end of the table and tosses 5 rows from the opposite end at the same time. The end result is there is always only 10 rows downloaded into the DOM at one time regardless of whether the table actually "contains" 10, 20, 200, or 2,000,000. People who are sighted keyboard only or mouse users have no problem interacting wuth the table and its HTML content, or knowing what row they're on and how big the table atually is [a table header bar provides both these items, it says, for example, "1 to 5 of 20 showing"]. This isn't the case for users who are not sighted; here are the two issues we've identified in the current design: 1. The user never knows for sure the total number of rows contained in it, they only know about the rows contained in the Browser's DOM [1]. 2. Screen Readers tested don't interact with, or don't consistently interact with the table's scrollbar. In our case, they don't interact at all with the scrollbars so new rows never get posted because the scrollbar never moves. These problems might be overcome if more rows were downloaded - JAWS scrolled a table with 45 rows downloaded for example - but this may only address the problem JAWS' has while not addressing the same issue in WindowEyes. The user can also always refer to the header mentioned above to see how big the table is - but the result of a general table info request of a screen reader will always say a different total number of table rows then the number givven in the header row. Basically, the above possible solutions are hacks that don't fully address the problems. Which leads to my 2 question to the alias: 1. Has any of you dealt with this type of situation? 2. If so, what was your solution? Earl [1] - JAWS happens to retain all rows visited in its DOM. whose function is to download a sub-set of
Received on Saturday, 31 March 2007 20:02:07 UTC