RE: Action-1293 Proposal

If I could interject here, I think I do have a valid use case for this type of situation.

This might occur if you had a treegrid that perhaps returned 1000 initial rows, however only 10 rows were displayed at one time.

To save processing time, the expandable rows may already be included in the DOM, but hidden via CSS so that each row could be expanded.

If implicit counts are used, without an ARIA mechanism such as aria-hidden from preventing these extra rows from automatically being included in the calculation, then it may calculate 20+ rows present within the construct where only 10 are currently displayed and navigable.

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Thursday, March 19, 2015 9:00 AM
To: Joanmarie Diggs
Cc: Joseph Scheuhammer; PF; Alexander Surkov
Subject: Re: Action-1293 Proposal

On 2015-03-19 11:09 AM, Joanmarie Diggs wrote:
>> So, before proceeding, I think we need to decide if ARIA is going to
>> >support non-contiguous data sets.  IMHO, this adds a layer of 
>> >complexity that will make authors lives more difficult, and likely 
>> >make for badly marked up tables and grids.
> Fair enough regarding proceeding. But how do we handle things like 
> hidden rows and columns? A real-world use case is the Google Docs 
> spreadsheet.

AFAIK, that hasn't been a problem with tree views, where not all items are displayed because a given treeitem is collapsed.  The difference is the hidden items *are* in the DOM.  They are not missing; they are hidden via CSS.

The problem solved by rowcount, etc. is to provide accurate counts and indices of items when not all of them are present in the DOM. Are the hidden rows and columns in a Google doc spreadsheet due to CSS or are they actually missing from the DOM?

--
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Thursday, 19 March 2015 16:33:40 UTC