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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility message

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


Subject: RE: [office-accessibility] Statement of the issue & proposal for name/description/etc. in ODF drawings


Thanks Peter. Well described with detail. I'm going to reserve my
recommendation after reviewing discussion among the members.

- Mike 


Mike Paciello
TPG
+1 603.882.4122 ext 103

-----Original Message-----
From: Peter Korn [mailto:Peter.Korn@Sun.COM] 
Sent: Thursday, March 30, 2006 8:34 PM
To: office-accessibility@lists.oasis-open.org
Subject: [office-accessibility] Statement of the issue & proposal for
name/description/etc. in ODF drawings

Greetings,

Here is the promised write-up of the issue of names, descriptions, captions,
titles, etc. in drawing objects...

Requirements:
------------
 1. Every drawing object should have a short name, persisted in XML,
    that can be presented to users.  This short 'name field' should only
    be filled out by authors (and not automatically filled in, e.g.
    "line 1", "line 2").
 2. Every "meaningful" drawing object should have a 'description field',
    persisted in XML, that can be presented to users.
 3. Authors should be able to link text captions with the graphic
    object(s) they are associated with (e.g. the text "Tiger from the
    Amazon River Basin" that might be sitting underneath an image of a
    tiger).

Questions we need to resolve:
----------------------------
 1. How is the existing 'name attribute' in ODF drawing elements used
    in ODF, ODF apps?  Is it used by macros, etc., such that we can't
    have it be null by default, and only have contents when explicitly
    assigned by users?
 2. Do we need a 'description field' on every drawing primitive (e.g.
    line, rectangle, oval) that makes up a more complex drawing (e.g.
    a tiger's paw, or the entire tiger), or just on groups of drawing
    primitives?
 3. If we have a text caption, should it automatically be used as
    either the 'name field' or 'description field' as persisted in
    the XML ODF file, or should the job of presenting that caption
    be left to the policy of the assistive technology?

Group proposal (and the assumed answers to the unresolved questions this
proposal is assuming):
---------------------
 1. [assuming the existing 'name attribute' in ODF *is* used & needed
    for other things] we introduce svg:title on *all* drawing objects
    & drawing groups, and map that to ATK_NAME and MSAA short name.
    [assuming the existing 'name attribute' is *not* used for anything
    else] that we re-purpose 'name', advise ODF apps to leave it blank
    by default, and map that to ATK_NAME and MSAA short name.  [A third
    alternative: instead of introducing svg:title, we re-purpose 'name',
    and then have ODF apps use the default XML 'id' attribute for
    referencing drawing objects & groupings]  2. we introduce svg:desc, and
[assuming that we agree we don't need it
    on primitives] define it as applying to drawing groups only  3. we
introduce a "described by" relation in the XML markup, which
    links caption text objects to the drawing group that they caption
    (do we allow captions also on drawing primitives?)


Peter's opinion/suggestion:
--------------------------
 1. Go with the third alternative: re-purpose 'name' for a user 'name
    field', and have ODF apps use the XML 'id' attribute for references.
    We'd use this for the "described by" relation anyway.  Visual user
    presentation of un-named objects would programatically generate a
    user-presentation of an unnamed drawing object by concatenating the
    object type with the id (e.g. "line 3").
 2. Put svg:desc only on groupings, not on individual drawing primitives
 3. Allow the AT to decide how to present "described by"
    relations/captions; don't formally replace the XML 'name field' or
    'svg:desc' field with their contents.


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.






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