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

On Mar 10, 2014, at 7:19 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> On 03/10/2014 09:58 AM, Joseph Scheuhammer wrote:
> 
>> 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>
> 
> For your "amusement": https://bugzilla.gnome.org/show_bug.cgi?id=485063
> 
> Ok, perhaps we need some new API for this in ATK. It would solve both
> the original problem I raised here and things like the above.

Yes, we had to create new AX API properties for this. Native NSTableViews have this functionality, but also provide table view delegate methods so that an AT (other any other client) can request more information than is currently rendered in the view. For example, VO can ask the table delegate for the contents of row 16, even if it’s not rendered, or can tell the table to update it’s selection to the next row. We don’t have a standard way to do that in ARIA or HTML yet, so the ARIA posinset/setsize pattern is a hybrid that indicates the semantics of the displayed views, but does not imply support for the rest of the delegate methods than web applications have no way of delivering yet.

FWIW, I’m surprised that element dataset providers didn’t make the cut in HTML 5. Every web framework on the planet handles this in different ways, and all current implementations prevent hardware accelerated scrolling from working. I know SAP and Oracle have supported this in web views for at least 10 years, yet we still don’t have a web standard solution. Table data providers are on the list for ARIA 2.0, but it will not be an ARIA-only solution. It needs to happen in close coordination with the HTML or WebApps WGs.

James

Received on Monday, 10 March 2014 20:46:54 UTC