Re: Table with AJAX Issues

Al: Thanks for the feedback and pointer to a next step.

There's 2 ways to find out about posinset and setsize - trial and 
error, or hearing about other's success using these.
1. Hopefully someone has already done the latter; has anyone had 
any experience and success using the posinset and setsize 
attributed in their code?

2. If successfull, which AT was used to verify things weere 
working correctly?

Earl


Al Gilman wrote:

> 
>> 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 Monday, 2 April 2007 18:29:55 UTC