[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-accessibility] proposal
Chieko & Rich - I agree that it is important to document the use of nextfocus to ensure that authors fully understand how to implement it. Authors should fully understand the effect (or lack of effect) of nextfocus in a z-order scenario. -Mike Mike Paciello TPG +1 603.882.4122 ext 103 -----Original Message----- From: Chieko Asakawa [mailto:CHIE@jp.ibm.com] Sent: Thursday, March 16, 2006 5:36 AM To: office-accessibility@lists.oasis-open.org Subject: RE: [office-accessibility] proposal Rich and Mike, Let me clarify the discussion point for presentation. > follow a last object added scheme and > tabbing starts from the first node added to the next subsequent node added and so on. Is it corresponding to "z-order"? http://en.wikipedia.org/wiki/Z-order MS PowerPoint also adopts z-order for reading order. But it often mismatches to the visual appearance and users gets confusion. So you are suggesting to add a new attribute "nextFocus" to modify the reading order, when the z-order is not appropriate. Is that correct? I think it is a good idea, too. However, we will need to consider authoring issues. It might be confusing to authors to select the next focus, because it affects only the reading order, not visual appearance. If they made a mistake in ordering, there will cause accessibility problems. Best regards, Chieko --------- 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 12:10 <schwer@us.ibm.com>, "'Janina Sajka'" <janina@freestandards.org> cc Please respond to Chieko Asakawa/Japan/IBM@IBMJP, mpaciello "'Dave Pawson'" <dave.pawson@gmail.com>, <office-accessibility@lists.oasis-o pen.org> Subject RE: [office-accessibility] proposal I like the use of nextfocus too Rich. Makes the most sense to me. I need you to comment further on your reasoning regarding skip navigation and presentation objects. If the object is a graph, chart, or other graphic that conveys information, then I agree. However, if the presentation object is non-contextual or otherwise affects the implied reading order within a document, then I would want the option of changing focus. -Mike Mike Paciello TPG +1 603.882.4122 ext 103 (Embedded image moved to file: pic15554.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: pic14636.gif)Inactive hide details for Janina Sajka <janina@freestandards.org>Janina Sajka <janina@freestandards.org> Janina Sajka <janina @freest (Embedded image moved to file: andards pic03119.gif) .org> To (Embedded image moved to file: pic16051.gif) 03/15/2 mike paciello 006 <mpaciello@paciellogroup.com> 11:29 (Embedded image moved to file: AM pic09797.gif) cc (Embedded image moved to file: pic00644.gif) Richard Schwerdtfeger/Austin/IBM@IBMUS, "'Dave Pawson'" <dave.pawson@gmail.com>, "'Chieko Asakawa'" <CHIE@jp.ibm.com>, office-accessibility@lists.oasi s-open.org (Embedded image moved to file: pic22240.gif) Subject (Embedded image moved to file: pic26761.gif) Re: [office-accessibility] proposal (Embedded image moved to file: pic24582.gif) (Embedded image moved to file: pic26191.gif) 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]