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: Re: [office] Accessibility SC Proposal for alternative text



Thanks, Patrick.  The topic of a new attribute versus overloading an old one was discussed at some length.  The accessibility SC didn't really have much of a preference, but the opinions expressed on the TC list have mostly favored a new attribute, so that's why the current proposal is the way it is.  I think it's safe to say that it's really up to the TC, the SC will be happy either way.  -- Nathaniel



Patrick Durusau <patrick@durusau.net>

05/04/2006 07:04 PM
Please respond to
patrick@durusau.net

To
Nathaniel S Borenstein/Concord/IBM@IBMUS
cc
office@lists.oasis-open.org, office-accessibility@lists.oasis-open.org
Subject
Re: [office] Accessibility SC Proposal for alternative text





Nathaniel,

I am not on the accessibility list so if you could forward I would
appreciate it.

Just scanning it quickly I noticed the proposal of a new attribute.

Be aware that one of the comments on ODF outside of ISO has been that it
has too many attributes. While I suppose my default reaction is like
that of many otheres, let's just add an attribute, I think it would be
useful to consider adding a new element in some cases. I don't think
that would affect backwards compatibility since whatever is not
recognized is simply preserved.

Kudos to the SC on isolating so many problem areas so quickly! Curious
if there is a strong preference for a solution based upon a new
attribute or element, so long as all the problem areas are addressed?

Hope you are having a great day!

Patrick

Nathaniel S Borenstein wrote:

>
> What follows is the latest version of the accessibility subcommittee's
> proposal for extending alternative text support.  We think this is
> pretty much our final word on this subject, but will discuss it one
> final time at our face to face meeting May 20-21.  Meanwhile, however,
> we wanted the whole TC to see what we're proposing.
>
> Note in particular that in section 3.0 there is an explicit reference
> to what Microsoft Office does.  The TC should decide if it wants that
> language in the standard.
>
> Please send any comments to office-accessibility@lists.oasis-open.org.
>  Thanks.  -- Nathaniel
>
> ======================================
>
> Executive Summary of proposed changes addressing alternative text for non-
> text elements and hypertext links:
>
> An accessibility gap in the ODF specification is alternative text support
> for non-text objects. Additionally, the specification does not allow for
> "hint" text for hypertext links. These are also a key accessbility
> requirement in the W3C Web Content Accessibility Guidelines. In order to
> address this, the subteam has decided we need provisioning for alternative
> text and long descriptions for these types of ODF elements. We had
> considered the use of draw:name and office:name (hyperlink) properties for
> alternative text however feedback from some TC members indicated that this
> already had "legitimate uses and its reuse was inappropriate."
>
> Subsequently, the subteam recommends the use of the <svg:title> element,
> from SVG, for alternative text and
> the <svg:desc> element, from SVG for the long description. We have also
> decided that ODF captions do not follow standard XML in that the
> captioning <text:p>
> does not show a normative relationship, in the specification, to the
> drawing object being captioned. As a result we will be introducing a new
> draw:describedBy attribute to apply to objects being captioned.
>
> Furthermore, we will be asking that the appropriate text be added to the
> ODF specification to indicate how this accessibility meta data is mapped
> by the authoring tool to platform accessibility API as well as their
> accessibility applicability in the specification.
>
> Requirements:
>
> 1.0 image-map elements
> The <svg:title> element must be provided as an optional element to the
> following:
>
> draw:area-rectangle
> draw:area-circle
> draw:area-polygon
>
> Text should be added to these elements as follows:
>
> <svg:title> is used as a short accessible name. When transcoding from
> another document format to ODF the short names, like HTML's alt text on
> the <img> tags shall shall be mapped to the <svg:title> element.
> Alternative in Microsoft Office is considered a short name and should be
> mapped accordingly.
>
> <svg:desc> Is used for the long description in support of accessibility.
>
> 2.0 Drawing layer
>
> The <svg:desc> element must be provided as an optional element to the
> <draw:layer>
> . This element must apply to all ODF document formats for which <draw:
> layer> is used.
>
> Text should be added as follows:
>
> <svg:title> is used as a short accessible name. When transcoding from
> another document format to ODF the short names, like HTML's alt text on
> the <img> tags shall shall be mapped to the <svg:title> element.
> Alternative in Microsoft Office is considered a short name and should be
> mapped accordingly.
>
> <svg:desc> Is used for the long description in support of accessibility.
>
> 3.0 Drawing shapes (line 5926 of spec.)
>
> The <svg:title> and <svg:desc> elements must be provided as an optional
> element to all drawing shape elements defined below for all ODF document
> formats for which these drawing shapes are used.
>
> The following are the drawing shape elements:
>
> <draw-rect>
> <draw:line>
> <draw:polyline>
> <draw:polygon>
> <draw:regular-polygon>
> <draw:path>
> <draw:circle>
> <draw:ellipse>
> <draw:g>
> <draw:page-thumbnail>
> <draw:frame>
> <draw:measure>
> <draw:caption>
> <draw:connector>
> <draw:control>
> <dr3d:scene>
> <draw-custom-shape>
>
> Text should be added to these elements as follows:
>
> <svg:title> is used as a short accessible name. When transcoding from
> another document format to ODF the short names, like HTML's alt text on
> the <img> tags shall shall be mapped to the <svg:title> element.
> Alternative in Microsoft Office is considered a short name and should be
> mapped accordingly.
>
> <svg:desc> Is used for the long description in support of accessibility.
>
> User agents supporting platform accessibility APIs should follow the
> following conventions for supporting the accessible name, accessible
> description (accessible help on Windows systems), and describedBy
> relationships:
> If an <svg:title> element is provided it should map to the accessible
> name. If not, the name should use the text referenced the text element
> identified by the draw:describedby attribute. <svg:desc> must be used to
> support the accessible description. User agents shall not manufacture
> names for the
> <svg:title> element, such as using the drawing object followed by a
> cardinal number in a string as it is used for accessibility. Name
> assignments such as these provide no semantic meaning to the user.
>
> Guidance for authors:
> Authors should not assign names to objects having no semantic value. If no
> name is assigned the caption text will be used in its place. <svg:title>
> shall take precedence over the caption text for accessible name assignment
> by the user agent.
>
> Assignment of the long description should only be necessary when a drawing
> object is significantly complex and the user needs more information to
> describe it. Long descriptions would be more applicable to drawing
> groupings than basic drawing shapes.
>
> Authoring tool responsibility for presenting and prompting for the
> <svg:title> and
> <svg:desc>:
>
> Authoring tools should provide an option from an objects context menu to
> allow the user to enter the text for either of these elements as a
> minimum. More proactive authoring tools should have a facility for
> prompting the author for this text. Since <svg:desc> is a long
> escription, a text area vs. a text field should be used to prompt the
> user accordingly in GUI-based authoring tools like Workplace and Open
> Office.
>
> Navigation tools, such as in Workplace and Open Office, used to list the
> objects in the view should provide
> the type of object followed by the contents of <svg:title>. The title must
> have been entered by the author.
>
> For <draw:g> elements the drawing objects who are members of the group
> should visible only when the group is expanded.
>
>
>
> 4.0 Establish clear relationship between a drawing objects and its caption
> by including a new optional draw:describedby attribute to the following
> drawing objects:
>
> <draw-rect>
> <draw:line>
> <draw:polyline>
> <draw:polygon>
> <draw:regular-polygon>
> <draw:path>
> <draw:circle>
> <draw:ellipse>
> <draw:g>
> <draw:page-thumbnail>
> <draw:measure>
> <draw:caption>
> <draw:connector>
> <draw:control>
> <dr3d:scene>
> <draw-custom-shape>
> <dr3d:scene>
> <draw:frame>
>
> draw:describedby shall take a value of IDREF. The value for describedBy
> attribute shall be the target id assigned to the <text:p> used to
> represent the corresponding caption. As text:p is an XML element it may
> have an ID assigned by default. The following attribute list should be
> included as optional to the above drawing objects:
>
> <define name="common-draw-describedby-attlist" combine="interleave">
> <attribute name="draw:desribedby">
> <ref name="IDREF"/>
> </attribute>
> </define>
>
> When a caption is assigned by a user agent, an id must be assigned to the
> element containing the text used to caption a drawing element. The drawing
> element being captioned must then be assigned the draw:describedby
> attribute with an IDEF equivalent to the id of the captioning text thus
> establishing a relationship between the captioned text and the object
> captioned as needed for accessibility. Removing the caption should result
> in removing the describedBy attribute of the object that was being
> captioned.
>
> If the user agent supports a platform which provides a describedby
> relationship in its accessibility API, this relationship for captions
> should be used to fulfill the relationship.
>
> 5.0 Establish text hints for hypertext links
>
> The <svg:title> element must be provided as an optional element to
> <text:a>
>
> <svg:title> is used as a short accessible description for hint text. When
> transcoding from another document format to ODF the alt text, shall be
> mapped to the <svg:title> element. When exporting ODF documents to HTML,
> the contents of title text should be mapped to title attribute text on
> HTML anchor tags. As a minimum, authoring tools should provide a mechanism
> to provide the hint text.
>
> The title text should be made accessible to the assistive technology and
> user. The user agent should allow for programmatic access through standard
> accessibility APIs such as the accessible description. User should
> experience visible access to the hint text via the keyboard or mouse.
>
> Appendix:  Proposed schema for svg-title
>
>
> <define name="svg-title">
>      <element name="svg:title">
>          <text/>
>      </element>
> </define>
>
> ======================================
>

--
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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