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