Re: Table with AJAX Issues

>Hi;
>
>Pointers appreciated if there's a better alias to ask this question on.

Good enough place to ask, IMHO.

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

The approach we have taken in the WAI-ARIA specs is as follows:

Ref: http://www.w3.org/TR/aria-state/#posinset

The 'posinset' attribute gives the position of an item in a
collection. In your table case this is the logical position of the row in the
master table on the server. The 'setsize' attribute is the size
(number of rows) of that master table.

(the design works with 'level' as well so as to support similar
slicing [get a sub-range] of sub-collections in a hierarchical
collection.)

This means that the chunking could be adaptive based on network
performance or UI preferences, and the AT will have sufficient data
to brief the user on where the current row and slice are in the
meaningful collection.

I'm not up to date on how much of this is demonstrable yet with
running code, but it is a problem that our participants identified
as a common problem and this is the approach that we have taken
to address this use case.

Al

>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 Sunday, 1 April 2007 12:29:43 UTC