[edtorial correction] Re: Structured HTML Precludes aria-posinset and aria-setsize?

s/<ol>/<ul> in the example

On 28 Aug 2008, at 1:32 PM, Al Gilman wrote:

>
> [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 posterkid for this is the <ul> 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 18:33:21 UTC