Re: Why I don't attend the weekly teleconference (Was: Input on the agenda)

Murray Maloney wrote:
> At 12:50 AM 7/1/2009 +0200, Lachlan Hunt wrote:
>> While the hidden metadata problem certainly isn't restricted to
>> accessibility related attributes, that doesn't mean we can untie it
>> from the discussion and ignore it. For any attribute to which the
>> problem applies, the negative effects of the problem need to be
>> evaluated and weighed up together with all of the other issues.
>
> Are you suggesting that we perform a thorough review of all HTML
> attributes to determine which ones are prone to misuse because their
> visible effect is not readily apparent in various classes of HTML
> applications...

No, certainly not.  Such a review related to this one specific issue 
would be very time consuming.  I'm just saying that this is one of the 
many issues for consideration when each attribute either will be or was 
previously discussed, and so unless there are cases where it was 
blatantly ignored and isn't clearly outweighed by other considerations, 
we don't need to do such a thorough review of it.

>> Where possible, it seems reasonable to find a way to avoid the
>> problem, or at least limit its negative impact, which is exactly what
>> the attempts at using more visible alternatives are trying to do.
>
> I agree that it would be great of tools performed all of the QA
> functions that one might need to assure correct creation, processing,
> display and/or other form of presentation.

This sounds like a tools-will-save-us argument, which isn't very 
effective.  Rather than relying on as yet non-existent authoring tools 
to address the problem of hidden metadata in this case, it seems better 
to fix it in the language itself, such that the replacement doesn't 
suffer from the problem.

> I have not seen widespread support for the visible alternatives. In
> fact, I have seen and myself expressed strong disagreement with
> conflating caption. Please feel free to explain the visible
> alternatives to me so that I might be swayed...

The visibile alternatives I was referring to include, among others, 
simply including the summary in the surrounding prose, possibly linking 
to it using aria-describedby; using figure around the table and writing 
a summary in the legend; or incorporating the summary into the caption, 
possibly using <details> to allow it to be shown by the user on request.

Personally, I'm don't agree with idea of conflating caption and summary 
since they are very different concepts that contain vastly different 
content.  While it does address the problem of programmatically 
associating the summary with the table, it blatantly ignores editorial 
style considerations.  However, simply including the summary as part of 
the surrounding prose doesn't suffer from this problem.

e.g.

<p>The following table shows the average rainfall per month for the 
North Shore region, with columns representing the months and rows 
representing the suburbs.

<table><caption>Average rainfall for the North Shore region</caption>
<thead><tr><th>Suburb     <th>Jan  <th>Feb  <th>...
<tbody><tr><th>Crows Nest <td>25mm <td>40mm <td>...
...
</table>

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Wednesday, 1 July 2009 07:25:36 UTC