RE: [office-accessibility] proposal

office-accessibility message

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.

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

"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