Re: Structured HTML Precludes aria-posinset and aria-setsize?

[moving to wai-xtech@w3.org>.  public-pfwg-comments is good for bean- 
counting but
not well set up for discussion.]

On 27 Aug 2008, at 5:59 PM, Ben Millard wrote:

> (Sorry for the severely delayed follow-up to this.)
>
> Henri Sivonen wrote:
>> 1) Paged views (e.g. showing 20 messages of a mailbox containing  
>> thousands of messages and having only the 20 items in the DOM)
>
> If knowing the current range and total size of the set is useful, I  
> imagine it will be useful to everyone.

Not based on current practice.

The posterkid for this is the <ol> in HTML where
the sighted user just gets the same bullet icon
on each entry, and the screen reader still tells
the non-visual user "three out of seven."

The speech-only user generally needs the industrial-strength
orientation, as reflected in this common practice across screen
readers.

The visual user cares little enough for this information so
that the visual presentation doesn't usually give it.  It's not in
the content in this case because it's computable, and the AT
that knows their user needs it computes it, not the browser
that codes for everyone.

<quote
cite="http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0125.html">
The eye flits around the screen and the user gets a 40,000-foot idea of
what is there.  The ear can't. ...
</quote>

Verbosity belongs in the 'personalizable' space.
There is no one-profile-fits-all verbosity level.  And
speech-presentation users on the whole need less verbosity,
even as they need some of the formal structure surfaced
in the speech stream.

The @aria-posinset and @aria-setsize metadata attributes in WAI-ARIA  
are,
as Henri pointed out, only intended to be used when the answer can't be
computed from the DOM.

> As such, the range of items currently displayed should be noted in  
> element content where it can be found by everyone.

Putting it in attributes doesn't mean you can't lift the value
to put in the presentation.

Putting it in element content is most likely to lose the model  
knowledge that
comes from the definition of the attribute.
This is not just text that can be displayed or spoken, it is a  
representation
of two numbers with a significant relationship.

This enables, for example, a 'progressbar'-like presentation for  
those with
learning disabilities.

> Using your example, I'd expect to see "Message 100 to 120 out of  
> 1,200" or similar in a heading element preceeding the the messages.  
> Putting this information in one place, available and accessible to  
> all, seems to preclude repeating the values in specialist  
> attributes throughout the set.

This could in theory be done by supplying enough metadata semantics  
in the table or list.  So
far as I understand, the Forms Joint Task Force is stalled.  So yes,  
there are
approaches along those lines that could be made to work.

But @aria-posinset is on all the leaves precisely because the root  
node for the
collection may not be in the DOM.  The application on the server  
knows this stuff.
Saves burden on the script that did the AJAX get of the new data  
slice to find and
maintain the data on the container for the present slice.

>> 2) Tree grids implemented as <table>s where some rows should not  
>> participate in the top level item count.
>> In case #2, rows in <thead> and <tfoot> should be ignored for the  
>> count as well as rows flagged as subrows.
>
> I agree that more sophisticated counting may be necessary in more  
> sophisticated structures. Specifying how UAs should count within  
> these structures would preclude repeating the values in attributes  
> throughout the set, as far as I can tell.

s/would preclude/could obviate

Functions implemented over the DOM in the browser that maintain this  
stuff
could reduce the need for doing it longhand in data in many cases, as  
with
the cell/header associations.

Al

> -- 
> Ben 'Cerbera' Millard
> <http://projectcerbera.com/web/study/>
>

Received on Thursday, 28 August 2008 17:32:54 UTC