OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Generalizing svg:title and svg:desc for titling and accessibility


Michael,

In researching Thorsten Zachmann's original problem, I noticed that svg:title and svg:desc already solve a part of the specific problem that Thorsten had identified some time ago. 

I also noticed that there was some hesitance around using the svg:title and svg:desc with anything but graphical objects, and that OpenDocument-v1.2-draft7-12.odt only has those elements associated with graphical objects (specifically, the dr3d: and draw: QNames).

It occured to me that there may be a simpler solution that deals with accessibility requirements more broadly (other than the grouping concerns that Richard Schwerdtfeger has noted).  I was not around when this was looked into and I apologize if I am revisiting questions that were already explored and ruled out.  I thought it worth checking out.

Here is a simple sketch of what I suggest be explored:

SKETCH

1. Derive two attributes from Dublin Core that can be understood as the title of the object an element represents and the accessibility-appropriate description for that object.  (Note, these are attributes, rather than elements, making it easier to have them be optionally ubiquitous on elements throughout the ODF schemas.) 

2. Because of specialization, these should probably be named something like office:title and office:desc, even if inherited from an appropriate Dublin Core element or attribute.

3. In the ODF Schema, make these two attributes optional on all elements under an ODF document root or otherwise.

4. The intention is to allow these attributes to be used on any element that corresponds to a document entity that has a distinct, perceivable object in presentation of the ODF document.  Depending on the situation, an user agent may provide this information when the object is to be referred to, and as alternative information to whatever the rendition of the object is.  It depends on user agents how such information is captured for particular elements and how it is used in assisting users for accessibility and other reasons.  Rather than attempt to foresee the specific elements for which that is involved, it seemed useful to allow implementations to work it out, depending on the functions that they support and the perceptual model for what users can describe for consultation by others.  The idea is to be tolerant of their optional occurrence everywhere..

 - Dennis


ADDITIONAL CONSIDERATIONS

I don't have answers about these, but they might bear exploration if the basic idea seems worth pursuing.

5. It strikes me that such attributes may also be of interest as subjects of the RDF metadata via URI references to their elements, although in this case, it might be more useful to use elements rather than attributes.  In writing this, I've become rather fond of the attribute approach, since it is harder to declare an element that can be a sub-element of any other element but itself.  This does make it more difficult to have internal markup (and attributes on internal elements) though.

6. If an option element were used, it might be useful have an office:title attribute required, the office:desc be an optional attribute, with no content in the element itself.  That might avoid any trickiness with the texts being presented under foreign-element content-processing conditions.  The other value of an element is the availability of its identification with an xml:id and crisper interpretation if identified in an RDF subject/object URI.  There are other variations on this idea that might be considered in satisfying the intended use cases.

7. I have not addressed whether and how the office:title and office:desc can be propagated into elements under other schemas that are appealed to by reference (math, svg, etc.).  That's not a new problem though.

8. I have not addressed whether and how office:title and office:desc might appear comingled where <svg:title> and <svg:desc> are already supported.  I see that <svg:title> and <svg:desc> are appropriated from the SVG specification in ODF 1.1, as well as ODF 1.2.  The svg:title and svg:desc elements were not incorporated for ODF 1.0 even though that specification makes use-by-reference from the same SVG 1.1 specification.  The ODF 1.1 and proposed 1.2 definitions seem to contradict or pre-empt what SVG 1.1 section 5.4 provides for those elements, which have attributes and can have internal markup.  I don't know if one would want to deprecate the svg:title and svg:desc, from ODF 1.1, or simply let it stand.  

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/office/200812/msg00102.html
Sent: Thursday, December 11, 2008 23:23
To: ODF TC List
Cc: 'Thorsten Zachmann'; 'David Faure'
Subject: [office] Custom Slide Shows: presentation:page-ids is unnecessary

[ ... ]

Secondly, the problem of allowing titles and their accessible descriptions has been resolved for ODF 1.2.  The solution is to use the <svg:title> and <svg:desc> elements under <draw:page>.  This seems to resolve the original problem, since there is no uniqueness requirement for the content of these elements and arbitrary (unformatted) text is allowed.

[ ... ]
 
2.4 This Problem Is Already Solved

In the existing draft of ODF 1.2, there are two new ways to allow arbitrary names to be given to presentation pages: <svg:title> and <svg:desc>, and this arrangement also satisfies accessibility requirements.

[ ... ]

2007-11-22: Michael Brauer explains extension of the discussion to table:names
http://lists.oasis-open.org/archives/office/200711/msg00036.html

2007-11-22: David Faure is confused about discussion not being so much about page names
http://lists.oasis-open.org/archives/office/200711/msg00034.html

2007-11-22: Michael Brauer on Drawing page names (re 2006-02-13 minutes)
reports an inconsistency when integrating the proposal into the specification
and apparently this stopped <svg:title> and <svg:desc> getting in right away,
at least for tables.
http://lists.oasis-open.org/archives/office/200711/msg00035.html

2007-11-12: Rob Weir draft minutes of 2007-11-12 coordination call, where 
the addition of <svg:title> and <svg:desc> under <draw:page> was approved.
http://lists.oasis-open.org/archives/office/200711/msg00023.html

2007-10-26: Malte Timmermann on Accessible Names are usable elsewhere
http://lists.oasis-open.org/archives/office/200710/msg00065.html
** This was approved with regard to addition of <svg:title> and <svg:description>

2007-10-26: Michael Brauer on introducing a draw:display-name attribute separate
from the draw:name attribute, and consideration of piggy-backing on xml:id
http://lists.oasis-open.org/archives/office/200710/msg00064.html

2007-10-19: Michael Brauer acknowledges reminder from David Faure and concurring
with Christian Lippka's recommendation to deprecate draw:ID and use xml:id since metadata
(RDF) needs it as a fragment ID that is readily identified and also introduced.
http://lists.oasis-open.org/archives/office/200710/msg00042.html

[ ... ]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]