W3C home > Mailing lists > Public > public-pfwg@w3.org > March 2014

Re: Clarification sought regarding aria-setsize and aria-posinset

From: Joseph Scheuhammer <clown@alum.mit.edu>
Date: Mon, 10 Mar 2014 09:58:31 -0400
Message-ID: <531DC507.8070601@alum.mit.edu>
To: Joanmarie Diggs <jdiggs@igalia.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Hi Joanie,

> This example seems to suggest that web developers might not have to
> provide all child nodes. If that is indeed the case, then this mapping
> change might not work out after all. So.... Is there a use case where
> web developers know the set size and a subset of the children and the
> position of those children, but fail to know all of the children and
> their positions?

A use case is where the information is lazily loaded from a relatively 
large database.  In this case, it's a given that the information does 
not all fit at once on the web page, and will require scrolling to move 
among items.  It is undesirable to load all of the data at once since 
that increases the page load time, and generally uses up more browser 
resources, all the while not knowing which subset of the data the user 
will interact with.  Hence, the page is initialized with some reasonable 
amount of data and updates on demand as the user scrolls, throwing away 
items that have scrolled off the top.  Think of it as a window through 
which only part of the data is seen at any one time.

As such, the DOM only contains a subset of the data at any one time.  
But, the values of aria-posinset and aria-setsize still have to reflect 
the position/size in the larger, complete data set on the server.

> --joanie, who wants to not have to know/care if something is ARIA or not

Ideally, that's the way it should be.  <rhetorical>Are there no desktop 
applications that load subsets of data?  An example would be a very 
large spreadsheet.</rhetorical>

-- 
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -
Received on Monday, 10 March 2014 13:59:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:01 UTC