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