[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