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] 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]