MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office-accessibility] Re: [office] Accessibility SC Proposalfor alternative text
Peter,
Peter Korn wrote:
> Hi Patrick,
>
> To echo Nathaniel - the accessibility SC proposed specific solutions
> (like this one, and more to come out of our face-to-face meeting later
> this month) with the idea that it's always easier to criticize and
> improve upon a straw-man proposal than it is to come up with a
> solution from scratch.
>
Understood and the work of the SC is deeply appreciated!
> In general we aren't wedded to any particular solution for any
> particular problem. But we are proposing solutions that are (a) in
> keeping with our understanding of the existing ODF/XML model, and (b)
> which we believe are sufficient to solve the problem(s) we discover.
> By all means, please suggest alternative solutions to the ones we
> suggest. You guys are the ODF experts!
>
I did not mean it so much as an alternative but more of a genuine
question about how the SC felt about the proposed solution. I haven't
really had time to really digest the proposal but am deeply appreciative
of the attention to detail that it shows.
Hope you are having a great day!
Patrick
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>>
>> 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
>>
>>
>
>
>
>
--
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!
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]