[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-accessibility] proposal
Chieko & Rich:
Attached please find a revised version of the proposal document. Following
is a list of edits:
Original Text: In general, alternative texts are defined as "short"
description for non text elements.
Changed Text: "description" to "descriptions"
Original Text: "However, it is required to provide additional detailed
descriptions for complicated charts, graphics and embedded objects."
Changed text: "However, complicated charts, graphics and embedded objects
require additional, detailed descriptions."
Original Text: ODF does not have an element, which corresponds to then
longdesc.
Changed text: "corresponds to longdesc."
Original Text: Difference between the Original SVG and the SVG Namespace of
ODF
Changed text: "Difference" to "Differences"
Original Text: The <title> is defined
Changed text: "The <title> element is defined..."
Original Text: ...the <desc> is defined for adding longer description. (
Changed text: "the <desc> element is used for defining long descriptions"
Original Text: Usage of these two element is described in the document,
Changed text: "Use of these two elements is described in the document..."
Original Text: Add <svg:title> to ODF as alternative texts
Changed text: "text" to "texts"
Original Text: "Provide alternative text for non text element by using
<svg:title>.
Changed text: "non text elements"
Original Text: And for providing a longer more complete description, use the
element <svg:desc>
Change text: "And for providing a longer, more complete description, use the
elment..."
Mike Paciello
TPG
+1 603.882.4122 ext 103
-----Original Message-----
From: Chieko Asakawa [mailto:CHIE@jp.ibm.com]
Sent: Wednesday, March 15, 2006 9:49 PM
To: mpaciello@paciellogroup.com
Cc: 'Dave Pawson'; 'Janina Sajka';
office-accessibility@lists.oasis-open.org; 'Richard Schwerdtfeger'
Subject: RE: [office-accessibility] proposal
Mike and Rich,
Thank you very much for your correction.
Mike,
Could you edit the file?
Could you send us the both files, the list of correction and the updated
document?
If you have any problem in editing the ODT file, please let me know.
Best Regards,
Hiro
---------
Chieko Asakawa, Ph.D.
Accessibility Research
Tokyo Research Laboratory, IBM Research
E-mail: chie@jp.ibm.com
Tel: +81-46(215)4633 Fax: +81-46(274)4282
"mike paciello"
<mpaciello@paciel
logroup.com> To
"'Richard Schwerdtfeger'"
2006/03/16 11:32 <schwer@us.ibm.com>
cc
Chieko Asakawa/Japan/IBM@IBMJP,
Please respond to "'Dave Pawson'"
mpaciello <dave.pawson@gmail.com>, "'Janina
Sajka'" <janina@freestandards.org>,
<office-accessibility@lists.oasis-o
pen.org>
Subject
RE: [office-accessibility] proposal
No problem. Do you want me to just edit the document or do you want me to
send you the corrections in a list. I've done the latter. It would take me
30 minutes or less to edit in the changes and send you an updated document.
- Mike
Mike Paciello
TPG
+1 603.882.4122 ext 103
(Embedded image moved to file: pic18555.jpg)
From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Wednesday, March 15, 2006 9:31 PM
To: mpaciello@paciellogroup.com
Cc: 'Chieko Asakawa'; 'Dave Pawson'; 'Janina Sajka';
office-accessibility@lists.oasis-open.org
Subject: RE: [office-accessibility] proposal
Terrific! I wish you were in other working groups I am involved with.
I probably won't look at these until tomorrow AM - been a long day. This one
fills a lot of holes.
Cheers,
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist Chair, IBM
Accessibility Architecture Review Board
blog: http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441
"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost
(Embedded image moved to file: pic17544.gif)Inactive hide details for "mike
paciello" <mpaciello@paciellogroup.com>"mike paciello"
<mpaciello@paciellogroup.com>
"mike
paciello"
<mpaciello
@paciellog (Embedded image moved to file:
roup.com> pic01582.gif)
To
(Embedded image moved to
03/15/2006 file: pic09830.gif)
08:23 PM Richard
Schwerdtfeger/Austin/IBM@IBMU
S, "'Janina Sajka'"
Please respond to <janina@freestandards.org>
mpaciello (Embedded image moved to file:
pic00124.gif)
cc
(Embedded image moved to
file: pic29536.gif)
"'Chieko Asakawa'"
<CHIE@jp.ibm.com>, "'Dave
Pawson'"
<dave.pawson@gmail.com>,
<office-accessibility@lists.o
asis-open.org>
(Embedded image moved to file:
pic07130.gif)
Subject
(Embedded image moved to
file: pic09408.gif)
RE: [office-accessibility]
proposal
(Embedded image moved to file:
pic23702.gif)
(Embedded image moved to file:
pic06925.gif)
I'm going to send you my edits in a few minutes Rich.
-Mike
Mike Paciello
TPG
+1 603.882.4122 ext 103
(Embedded image moved to file: pic14364.jpg)
From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Wednesday, March 15, 2006 9:22 PM
To: Janina Sajka
Cc: 'Chieko Asakawa'; 'Dave Pawson'; mike paciello;
office-accessibility@lists.oasis-open.org
Subject: Re: [office-accessibility] proposal
While we are on Chieko's proposal, the defaullt accessibleName for drawing
objects should be the actual name ODF assigns should the author forget.
<svg:title> would override this. <svg:description> is if course the
longdesc.
I am following up on Matt King's use cases and investigating having either a
draw:connectedBy attribute (we could also use the name draw:flowsTo per ATK.
The problem is that if you are on an object you what to know what associated
connectors you have. Currently, you get the glue information from the
connector itself. Logically, I would believe we would want to know what
object we were on and then assess the list of connectors glued to it and
follow a path. I have a person in my team looking at model-based authoring
tools for accessibility and I will discuss this with him.
We will also need a keyboard navigation override scheme. Currently, Open
Office and Workplace follow a last object added scheme and tabbing starts
from the first node added to the next subsequent node added and so on. This
is like PowerPoint.
We have some options here: 1:
- we can use tabindex but they are difficult to maintain, or
- we can use nextFocus which has advantages beause then you don't have to
keep track of actual numbers.This is in XHTML2.
http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-hyperAttributes.html#s_hype
rAttributesmodule
nextFocus takes an IDREF
- SVG also has focusable attribute similar to focustraversable as Peter I am
sure remembers from Java
http://www.w3.org/TR/SVGMobile12/interact.html#focusable-attr I am not sure
that we would want to skip navigation of presentation objects.
Personally I would opt for nextFocus seeing as all the objects do have an id
reference.
I envision having two navigation schemes - following the tab order using the
default focus navigation mechanism or by having the user agents enumerate
the connection options and letting the user slect the next object to receive
focus.
Comments?
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist Chair, IBM
Accessibility Architecture Review Board
blog: http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441
"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost
(Embedded image moved to file: pic25113.gif)Inactive hide details for Janina
Sajka <janina@freestandards.org>Janina Sajka <janina@freestandards.org>
Janina Sajka <janina@freestandards.org>
03/15/2006 11:29 AM (Embedded image moved to
file: pic31875.gif)
To
(Embedded image
moved to file:
pic01724.gif)
mike paciello
<mpaciello@paciell
ogroup.com>
(Embedded image moved to
file: pic25735.gif)
cc
(Embedded image
moved to file:
pic13929.gif)
Richard
Schwerdtfeger/Aust
in/IBM@IBMUS,
"'Dave Pawson'"
<dave.pawson@gmail
.com>, "'Chieko
Asakawa'"
<CHIE@jp.ibm.com>,
office-accessibili
ty@lists.oasis-ope
n.org
(Embedded image moved to
file: pic22463.gif)
Subject
(Embedded image
moved to file:
pic26517.gif)
Re:
[office-accessibil
ity] proposal
(Embedded image moved to
file: pic13991.gif)
(Embe
dded
image
moved
to
file:
pic03
750.g
if)
I'm also in favor of accepting Chieko's for now.
I think we need to fix the things that must be fixed today first. Once we
have essential parity, we can go for multimedia and the kind of
diferentiation that can raise the bar for accessibility. But, let's not try
to push that through too fast. Let's do it deliberately building broader
consensus as we go.
Mike Paciello writes:
> I'd like to second Richard's motion to accept Cheiko's. However, if
> we're going to submit this as a formal document, the proposal needs to
> be
edited
> spelling and grammar.
>
> Regards,
>
> Mike
>
>
> Mike Paciello
> TPG
> +1 603.882.4122 ext 103
>
>
>
>
>
> _____
>
> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
> Sent: Wednesday, March 15, 2006 10:47 AM
> To: Dave Pawson
> Cc: Chieko Asakawa; office-accessibility@lists.oasis-open.org
> Subject: [office-accessibility] proposal
>
>
>
> I would like to propose that we move the multimodal proposal to post
> the June update and accept Chieko's proposal:
>
>
> (See attached file: proposal-alt-texts.odt)(See attached file:
> proposal-alt-texts.html)
>
> My reason being that none of the rendering office products are
multi-modal
> to date and our goal was to fix critical gaps and base presentation
> usability by June. The multi-modal piece is exciting in that it will
greatly
> help DAISY but I worry that we won't have time to address the other
issues
> for the June delivery like keyboard navigation in presentations. I
> also
feel
> that given the time frame - if we start down this path we will find we
have
> a lot more issues to address full multi-modality.
>
> Comments?
>
> Rich
>
>
>
>
> Inactive hide details for "Dave Pawson" <dave.pawson@gmail.com>"Dave
Pawson"
> <dave.pawson@gmail.com>
>
>
>
>
>
>
> "Dave Pawson" <dave.pawson@gmail.com>
>
> 03/13/2006 07:55 AM
>
>
>
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
>
>
> cc
>
> office-accessibility@lists.oasis-open.org, "Chieko Asakawa"
> <CHIE@jp.ibm.com>
>
>
>
> Subject
>
> [office-accessibility] Re: MediaObject Proposal for LongDesc
>
>
> On 10/03/06, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> >
> >
> > Hi Dave, Chieko,
> >
> > I read this and see value in it but it does not fully address an
> interoperability problem with Accessibility APIs.
> >
> > In MSAA, Java, or ATK on Gnome there is the notion of an
accessibleName
> an AccessibleDescription. Description would provide the equivalent of
> longdesc. It provides additional verbose text to the user when asked.
>
>
> >
> > So in the case of an OK button:
> >
> > The accessibleName is would be "OK" and is the equvalent of a label
> > The accessibleDescription might be "Activating this button will
> > result
in
> the indexing of your mail"
>
> I agree on this as a general proposition.
> However I am trying to improve on this for different modalities, by
enabling
> the provision of media other than text?
>
> My basic content model for anything in a document not in the same
> modality as the prime document (typically text) is as below
>
>
>
> > <define name="med-mediaobject">
> > <element name="med:mediaObject">
> > <oneOrMore>
> > <ref name="med-imageobject"/>
> > <ref name="med-textobject"/>
> > <ref name="med-audioobject"/>
> > <ref name="med-videoobject"/>
> > </oneOrMore>
> > </element>
> > </define>
>
> So rather than just insert an image/audio clip/video clip etc, the
> user can insert a number of alternatives, supporting multiple
> modalities, which hopefully will match those of the reader.
>
> I see this as an improvement of only allowing text as the single
> alternative format for the richer media.
>
> So, for Richs example, an audio clip, the author might well add a text
> equivalent or a video clip which provide the same information.
>
> It is my hope that this meets the needs that Rich describes.
> I also believe it negates the need for either alt text or longdesc but
> having read the usage, I'm less sure.
> A development might be to offer guidelines that the first block level
> element in the textObject should be that 'brief' description, followed
> by a more complete equivalent.
>
>
>
> regards
>
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>
>
>
>
>
--
Janina Sajka Phone: +1.240.715.1272
Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and
Canada--Go to http://www.ScreenlessPhone.Com to learn more.
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina@freestandards.org http://a11y.org
Proposal for Short and Long Alternative TextsChieko Asakawa - IBM March 9th, 2006. Table of Contents Proposal for Short and Long Alternative Texts 1 1 Issue: Lack of Long Description 1 2 Difference between the Original SVG and the SVG Namespace of ODF 1 3 Suggestion 2 4 Proposal of Schema Modification 3 1 Issue: Lack of Long DescriptionIn general, alternative texts are defined as gshorth descriptions for non text elements. ODF defines <svg:desc> for this purpose. However, complicated charts, graphics and embedded objects require additional, detailed descriptions. Under these conditions, HTML supports the following two types of alternative text.
glongdesch can provide an additional description for complex content where galth is not sufficient. ODF does not have an element that corresponds to longdesc. OpenDocument Specification v1.0, Section 9.3.9 gThe <svg:desc> element specifies an alternative text as specified in 5.4 of [SVG].h ODF Schema (OpenDocument-schema-v1.0-os.rng) <define name="svg-desc"> <element name="svg:desc"> <text/> </element> </define> 2 Differences between the Original SVG and the SVG Namespace of ODFThe original SVG defines two elements for alternative text (<title> and <desc>). The <title> element is defined as galternative texth and the <desc> element is used to define longer descriptions. However as shown in Table 1, SVG namespace of ODF provides <svg:desc> element for adding alternative text, and it does not have the element for adding longer description.
Table 1: Comparison of alternative text function SVG Specification 1.1, Section 5.4 (http://www.w3.org/TR/SVG/struct.html#DescriptionAndTitleElements) gEach container element or graphics element in an SVG drawing can supply a edescf and/or a etitlef description string where the description is text-only.h Use of these two elements is described in the document, gAccessibility Feature of SVGh. Accessibility Feature of SVG, Section 2.1 (http://www.w3.org/TR/SVG-access/#Equivalent) gtitle : Provides a human-readable title for the element that contains it.h gdesc : Provides a longer more complete description of an element that contains it.h 3 Suggestion
Example: <draw:frame draw:style-name="fr1" draw:name="Object1" text:anchor-type="paragraph" svg:width="12.573cm" svg:height="11.001cm" draw:z-index="0"> <draw:object xlink:href="javascript:void(0);" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> <draw:image xlink:href="./ObjectReplacements/Object 1" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> <svg:title>Graph representing rainfall amount in Tokyo</svg:title> <svg:desc>Rainfall amount in Tokyo dropped in August, that is the smallest amount in these ten years. However on the other months, the amount is higher than last year.</svg:desc> </draw:frame> OpenDocument Specification v1.0, Section 9.3.9 9.3.9 Alternative Text - CURRENT gThe <svg:desc> element specifies an alternative text as specified in 5.4 of [SVG].h PROPOSAL gProvide alternative text for non text elements by using <svg:title>. And for providing a longer, more complete description, use the element <svg:desc> as specified in 5.4 of [SVG].h 4 Proposal of Schema Modification
<define name="draw-frame"> <element name="draw:frame"> <ref name="common-draw-shape-with-text-and-styles-attlist"/> <ref name="common-draw-position-attlist"/> <ref name="common-draw-rel-size-attlist"/> <ref name="presentation-shape-attlist"/> <ref name="draw-frame-attlist"/> <zeroOrMore> <choice> <ref name="draw-text-box"/> <ref name="draw-image"/> <ref name="draw-object"/> <ref name="draw-object-ole"/> <ref name="draw-applet"/> <ref name="draw-floating-frame"/> <ref name="draw-plugin"/> </choice> </zeroOrMore> <optional> <ref name="office-event-listeners"/> </optional> <zeroOrMore> <ref name="draw-glue-point"/> </zeroOrMore> <optional> <ref name="draw-image-map"/> </optional> <a:documentation>proposal</a:documentation> <optional> <ref name="svg-title"/> </optional> <optional> <ref name="svg-desc"/> </optional> <optional> <choice> <ref name="draw-contour-polygon"/> <ref name="draw-contour-path"/> </choice> </optional> </element>
<a:documentation>proposal</a:documentation> <define name="svg-title"> <element name="svg:title"> <text/> </element> </define> <define name="svg-desc"> <element name="svg:desc"> <text/> </element> </define>
<define name="draw-area-rectangle"> <element name="draw:area-rectangle"> <ref name="common-draw-area-attlist"/> <attribute name="svg:x"> <ref name="coordinate"/> </attribute> <attribute name="svg:y"> <ref name="coordinate"/> </attribute> <attribute name="svg:width"> <ref name="length"/> </attribute> <attribute name="svg:height"> <ref name="length"/> </attribute> <a:documentation>proposal</a:documentation> <optional> <ref name="svg-title"/> </optional> <optional> <ref name="svg-desc"/> </optional> <optional> <ref name="office-event-listeners"/> </optional> </element> </define>
<define name="draw-area-circle"> <element name="draw:area-circle"> <ref name="common-draw-area-attlist"/> <attribute name="svg:cx"> <ref name="coordinate"/> </attribute> <attribute name="svg:cy"> <ref name="coordinate"/> </attribute> <attribute name="svg:r"> <ref name="length"/> </attribute> <a:documentation>proposal</a:documentation> <optional> <ref name="svg-title"/> </optional> <optional> <ref name="svg-desc"/> </optional> <optional> <ref name="office-event-listeners"/> </optional> </element> </define>
<define name="draw-area-polygon"> <element name="draw:area-polygon"> <ref name="common-draw-area-attlist"/> <attribute name="svg:x"> <ref name="coordinate"/> </attribute> <attribute name="svg:y"> <ref name="coordinate"/> </attribute> <attribute name="svg:width"> <ref name="length"/> </attribute> <attribute name="svg:height"> <ref name="length"/> </attribute> <ref name="common-draw-viewbox-attlist"/> <ref name="common-draw-points-attlist"/> <a:documentation>proposal</a:documentation> <optional> <ref name="svg-title"/> </optional> <optional> <ref name="svg-desc"/> </optional> <optional> <ref name="office-event-listeners"/> </optional> </element> </define> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]