Re: Request for group input on ISSUE-83 (figure and details captions)

Jonas Sicking, Mon, 25 Jan 2010 17:01:58 -0800:
> On Mon, Jan 25, 2010 at 9:11 AM, Leif Halvard Silli
>> Shelley Powers, Sun, 24 Jan 2010 21:46:42 -0600:
>>> On Sun, Jan 24, 2010 at 9:30 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>> On Jan 24, 2010, at 7:14 PM, Leif Halvard Silli wrote:

>>>>> <details><summary>Help</summary> [.. explanation ..]</details>

>>>> Examples like this make me think <dlabel> (or similar) would be
>>>> better than <dsummary> or <summary>.

>>> I have no objection to <dlabel>.
>> 
>> There are _two_ conditions that *could* make <summary> work:
>> 
>> (1) It is used for both <figure> and <details>
>> (2) One solves the problem of the proposed <summary> element for
>>    <table> simultaneously.
> 
> Are the problems <summary> for <table> listed somewhere, such that
> someone can check if the new <summary> solves them.
> 
> Also wondering if aria-describedby already solves these problems. So
> that now that aria-describedby is part of HTML5 we no longer need
> <summary> for <table>

Not a direct answer: 

What if we (1) ignored <figure>, <details> *and* <table>, for a while. 
(2) And instead created a "generic" captioning element/function. (3) 
Then we could use/adapt this method both on <table>, <figure> and 
<details> (if we still finds wee needs them) as well. (Yes, on <table> 
too, if it has benefits.) 

I propose this as an alternative to discussing these issues in endless 
- but separate - circles ... I mean: Our trouble with <table>, <figure> 
and <details> are in great part related to their optional caption 
elements - and their connected features. (AKA summary). But we have not 
yet defined what we want from a perfect caption functionality! <table> 
captions should not work different from other captions. All captions 
should in fact work in similar ways. If an accessibility summary is 
needed for tables, then it might also be needed for figures!  (Ian, in 
the spec, seems caption of figure and table somewhat as an related 
issue - but only briefly.)

Such a broad caption feature should, I think:

1. Satisfy the need to be a caption in the pure sense
2. Satisfy the need for offering visible advisory text
3. Satisfy accessibility needs.
4. Discern between 1, 2 and 3 in a programmatic way
5. Be possible to use on void elements.
6. Work inline level and block level

I should perhaps not share any concrete ideas ... But perhaps we should 
look at reusing some form elements. Not a novel idea, but I am more 
open to rediscover (and perhaps stretching) this option from HTML4 now, 
myself ...

For example:

<label>Image text. <img src="image" alt="Txt" ></label>

I don't know the "accessibility story" on the above example, but I 
would rather like to use ARIA to make sure that it is treated as an 
image with a caption, rather than using @aria-describedby to point from 
the <img> to the <label> ...

As it is, I feel the debate on <table>,<figure>,<details> - and their 
caption features - has stalled ... And I feel that <figure> is an 
overkill for simple caption needs.
-- 
leif halvard silli

Received on Tuesday, 26 January 2010 02:46:06 UTC