Re: function and impacts (was: @scope and @headers reform)

On 6 Oct 2008, at 3:10 AM, Henri Sivonen wrote:
[re-ordered for short answers first]

I'd go with something simpler: Cells that the author wants reported  
when the user queries another cell for its headers should be marked  
up as <th>.

[nit: 'simpler' is debatable]

That's a feasible alternative in terms of markup.  It should be on
the table, too.

None of the markup alternatives can be evaluated or chosen among without
considering the role of automation in the author's User Experience.

>
> On Oct 4, 2008, at 20:12, Al Gilman wrote:
>
>> Because, in terms of ground truth, it's not the same thing.  Only  
>> in the appearances created by the literal reading of the markup  
>> terms as mnemonic.
>>
>> http://lists.w3.org/Archives/Public/public-html/2008Aug/0574.html
>
>
> The distinction described in that email is probably too subtle for  
> casual authors to get right.

Yes, but that's not the nature of the problem.  Casual authors are not
generally building large and complex tables writing markup in WordPad.
Nor should they be.  And the format should not be limited in its  
expressive
capabilities to what casual authors can rapidly grok and get right.   
What
is easy should be easy (ergo more assertive inference of relationships
from layout) but what is hard should be possible (correct content at the
markup-graph level despite casual and clumsy layout of the table).

On subtlety:  No, the casual author won't cope with subtleties.  But  
the framers of the format spec must wrestle with subtleties so that  
the author and the consumer experience can both feel simple, without  
creating mis-communication.

Consumers and authors both come ahead of spec-authors in terms of whose
version of simplicity is to be valued, and the consumer and author  
versions
are different.  The format framers thus face the opportunity to  
bridge that gap better or worse.  Too simple will be worse.  Too  
complex will be worse.  Finding a middle-road sweet spot is a  
challenge, but not wasted effort.

The consumers have to be willing to accept help from algorithms in their
software to ease the author's burden in populating the fields in the  
markup.  Likewise the authors and their defenders need to admit that
authors stand to produce data of superior quality -- in a way that will
benefit consumers -- if they are aided by appropriate drafting and
coaching from their authoring tools.

> Do existing AT implementations make the distinction? How is the  
> distinction conveyed to the user?

Not every distinction is needed in every view.  See "on subtlety" above.

My impression is as follows.  This is rough memory, not direct
experience, and it probably is but one example of a variety of
approaches.

The <th> distinction is used in routine orientation during cell-to-cell
navigation in the table.  Moving in the same row, the column headers
are announced for the new cell.  Moving down the column, the new row
headers are announced.  The full information context as captured  
including
@headers is only announced interactively, when the user uses an  
'inspect'
or 'hunh?' gesture.

So the distinction is conveyed to the user experience in the difference
between push and pull verbosity.

> I'd go with something simpler: Cells that the author wants reported  
> when the user queries another cell for its headers should be marked  
> up as <th>. Is it common that the author wouldn't want these cells  
> to be styled distinctly in the visual presentation? And if it is  
> common, is it better to solve the mismatch by overriding  
> associations or by overriding visual style?

'common' has to be traded off against 'critical' before deciding how
much subtlety or complexity is appropriate.

Al

> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>

Received on Monday, 6 October 2008 16:49:13 UTC