W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2008

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

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 28 Aug 2008 14:27:12 -0400
Message-Id: <AB685C7D-5BAF-4563-89E3-F7BE7EAB2222@IEEE.org>
Cc: Ben Millard <cerbera@projectcerbera.com>, W3C WAI-XTECH <wai-xtech@w3.org>, Henri Sivonen <hsivonen@iki.fi>
To: Al Gilman <Alfred.S.Gilman@ieee.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:22 UTC