office-accessibility message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [office-accessibility] proposal
- From: "mike paciello" <mpaciello@paciellogroup.com>
- To: "'Richard Schwerdtfeger'" <schwer@us.ibm.com>,"'Janina Sajka'" <janina@freestandards.org>
- Date: Wed, 15 Mar 2006 22:10:18 -0500
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
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_hyperAttributesmodule
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
Janina Sajka
<janina@freestandards.org>
Janina Sajka
<janina@freestandards.org>
03/15/2006 11:29 AM |
|
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]