[html4all] Figure ideas (was: Article by Catherine: Feedback on accessibility concerns in HTML5)

Robert Burns rob at robburns.com
Fri Sep 21 20:18:10 PDT 2007


Hi Leif,

On Sep 21, 2007, at 7:26 PM, Leif Halvard Silli wrote:

> On 2007-09-22 01:39:21 +0200 rob at robburns.com wrote:
>>> On 2007-09-21 05:06:25 +0200 Robert Burns <rob at robburns.com> wrote:
>>>> On Sep 20, 2007, at 9:49 PM, zara wrote:
>>>
>>>> The figure element does raise the issue of embedded content that
>>>> is illustrative of the prose already included in a document. When
>>>> an image is included in a figure element with a caption, that
>>>> relationship is explicit
>>>
>>> And that is quite important. If the the automatic cross-reference
>>> system of HTML 5 is used, then one can create links links to/from a
>>> word/words in the caption text and to somewhere else in the  
>>> document.
>>> This could reduce the need for the @longdesc - I mean, not the need
>>> for it in the spec, but the need to use the @longdesc.
>>>
>>> Also - the caption text would become the natural place to place
>>> D-links, if/when they are needed.
>>
>> I'm not sure what automatic cross-reference system you're referring
>> to.
>
> [automatic cross-references]:
> <http://www.w3.org/html/wg/html5/#the-dfn>
>
> (3rd time I refer to the source in this thread.)

The problem with calling the cross-reference system and even adding a  
link to the spec is that the spec doesn't call it a cross-reference  
system (it also takes an inordinate amount of time to load the draft  
when all you have to say it that you're referring to the proposed DFN  
element referencing). There are many problems with the draft's  
proposed DFN element that I don't think we want to bring to the  
accessibility features. It doesn't provide for explicit linking. It  
doesn't reflect the way authors actually author documents and define  
terms, etc. There is another proposal on the wiki for a cross  
reference system and is actually called a cross reference.

>> Also, the issue of creating links does not really get at the purpose
>> of
>> longdesc. Though it uses a URI, a longdesc should be kept distinct
>> from a
>> hyperlink. We want them both to be possible for the same element and
>> we
>> want them clearly distinguished. In many ways a longdesc is closer to
>> an
>> embedding than it is to a link.
>
> The automatic cross-reference feature is, as much as I understand it,
> a special kind of linking - just as longdesc is another kind of
> special linking.

No, it's not linking. As I said before, longdesc is actually closer  
to embedding than it is to linking. UAs should be retrieving the  
longdesc text and readying it for presentation just as they do for  
the embedded image. A hyperlink, on the other hand, is meant to be  
handled as a linking mechanisms between to related two anchors. The  
relation of terms to their definition if done right might be more  
like longdesc than a link, but its still a separate mechanism with  
separate semantics.

> Are there any viewpoints on my proposal to either use SPAN (and/or
> other phrase elements) - or perhaps even DIV, instead of LABEL and
> LEGEND in FIGURE?

I assume you want to do that to provide better backwards  
compatibility. I'm sympathetic to that. However for the XML  
serialization that's not necessary and it is also not necessary for  
HTML5 UAs. I think, just like with XHTML2, we will see forward- 
looking authors using span and div elements to implement HTML5  
semantics, I'm not sure if we should make that a part of the  
language. Part of my motivation in the graceful degradation thought  
experiment page was to see if there are semantics that make sense to  
introduce with attributes and existing elements rather than new  
elements. The legend/caption element does not fit that criteria in my  
view. I also feel that caption (both for tables and for figures)  
should allow block content. So I'd rather see us introduce a  
blockcaption or bcpation or cptn element that supports block content  
for both tables and for figures.

Take care,
Rob




More information about the List_HTML4all.org mailing list