W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

ISSUE-2114 (title-desc-accessibility): 'title' and 'desc' elements in SVG 1.2T [SVG Core 2.0]

From: SVG Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Sat, 11 Oct 2008 18:18:56 +0000 (GMT)
To: public-svg-wg@w3.org
Message-Id: <20081011181856.6D0EA5F74D@stu.w3.org>

ISSUE-2114 (title-desc-accessibility): 'title' and 'desc' elements in SVG 1.2T [SVG Core 2.0]


Raised by: Doug Schepers
On product: SVG Core 2.0

Al Gilman

This is the Editor's draft, it has absorbed a number of changes

** summary

I think there are things we would want to change in the specification
provisions for these features in SVG 1.2T.  On the other hand, I don't
think that this release is the time to make the changes.

** details

* defects in the present treatment

SVG provides a <title> element and a <desc> (for description) element
for documenting documents and document fragments in SVG.

SVG 1.2T narrows the content model of these elements to plain text.

It describes the <title> text as


  The 'title' element must contain a short title for the container or  
graphics element containing it. This short title must provide  
information supplementary to the rendering of the element, but will  
normally not be sufficient to replace it.


It describes the <desc> text as


  The 'desc' element contains a longer, more detailed description for  
the container or graphics element containing it. This description  
must be usable as replacement content for cases when the user cannot  
see the rendering of the SVG element for some reason.


This, to me, feels like we have analogous features for  
and for html4:img.longdesc but nothing that fills the role of  
html4:img.alt: a terse replacement text.

The user needs a terse replacement that identifies what this object or
container is so they can decide to move on to the next or learn more
about this one.  That browse-ability or 'interactive verbosity control'
is part of the look-and-feel adaptation capability required.

In my ontology of textual information about something, "a short title"
and "supplementary to the rendering of the element" are conflicting
descriptions.  "A short title" should be sufficient to identify the
graphic object or container in the absence of that object or collection.
In this case, 'supplementary' is misleading.

My discussion of how tooltip behavior stole @title away from being a  
proper title is at


Likewise for the longer version, in practice a replacement and a  
description are not the same thing.  So I feel that this discussion  
sounds more prescriptive, but fails to be a clear and successful set  
of instructions.

* ambiguity in the "right answer"

We are still wrestling with HTML WG as regards how to meet the  
various needs for text information about a graphic object.


I think it's fairly clear we want markup back in these elements.
Internationalization and accessibility are not adequately addressed by
a <switch> on systemLanguage when what is needed is <ruby> for a  
Japanese proper name or ssml:say-as information.

Allowing markup inside a description would make it easy to mark the
content for tapered presentation with a header element that suffices
for quick-look and the rest of the <desc> to support those who want
to drill down.

That said, it's not clear what foreign markup vocabularies the SVG
processors should all be required to support.

At least there are required-capability metadata features defined  
such as requiredFonts and requiredFormats.

The point here is that the author wants to do right and put a  
foreignObject in to fill the role of the <desc> they have to add ARIA  
markup with @role='description' and an explicit @describedby on the  
enclosing element that is being described.

But this does not add up to a design.

One plan for a consistent schema of media object properties is  
discussed at

.. but PFWG has not reviewed this or come to a consensus behind it.

None of the above constitutes a substitute design; and I doubt we could
come up with a substitute design with the required implementation  
experience to get 1.2T to advance in a timely fashion.

** so what to do?

If someone can go over this and propose alternate language for SVG 1.2T
that more clearly implements WCAG2 SC 1.1.1, and do it by the comment
deadline Monday, that would be great.  Especially great if it doesn't
have any Implementation Report consequences.

Failing that, I think that we should let 1.2T go with a heads-up that  
this is an area we should revisit on the way to SVG 1.2 Core + modules.
Received on Saturday, 11 October 2008 18:19:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC