OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-accessibility] proposal


Hi Dave,

Comments below.


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


"Dave Pawson" <dave.pawson@gmail.com> wrote on 03/16/2006 08:10:31 AM:

> On 16/03/06, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> >
> >
> >
> > 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.
> They are semantically identical if semantics are taken from the svg
> world Rich.

> We gain no benefit from two such similar elements.
> A longdesc without structure is IMHO of little added value.
> The Caption element does more in terms of svg:title.

Title would be a short name for an object -like caption. While you are navigating a diagram, with a screen reader,
you do not want want to here a long description with your screen reader. That said,
Caption is a rectangular drawing object in your presentation which has a different
purpose in that it is also rendered on the screen and as an author I might not want that:

The element represents a rectangular drawing shape with an additional set of lines. It can be used as a description for a fixed point inside a drawing.
<define name="draw-caption">
<element name="draw:caption">
<ref name="draw-caption-attlist"/>
<ref name="common-draw-position-attlist"/>
<ref name="common-draw-size-attlist"/>
<ref name="common-draw-shape-with-text-and-styles-attlist"/>
<optional>
<ref name="office-event-listeners"/>
</optional>
<zeroOrMore>
<ref name="
</zeroOrMore>
<ref name="draw-text"/>
</element>
</define>
The attributes that may be associated with the element are:
Position, Size, Style, Layer, Z-Index, ID, and Transformation – see section 9.2.15
Text anchor, table background, draw end position – see section 9.2.16
Caption point
Round corners




>
>
>
>
> >
> > 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.
>
> I'm assuming the subject has changed, and we are talking about SVG
> vector graphics.


yes

> Connectors seem almost impossible to utilise via a machine.
> A group element, as per SVG would help, then use svg:desc and svg:title (or
> caption for the group) enabling a textual description of the group of lines.
>


Groups definitely help and I am not saying not to use groups. But groups can be formed
and then connected to other objects. In this instance we would want the group (IMO) to
hide all the internal connections, etc. and act as a single drawing object which would be
connected and become part of the navigation sequence.
 
> Take the tiger on the SVG website. What value would connectors add there?
> Thousands of lines, hundreds of connectors. Too much work for too
> little reward IMHO
>

I think we are in violent agreement. The tiger would be a group and all connections within would be hidden as a result of the grouping.
In ODP we have connectors and when used we want to connect the objects together and show the associations. Here
is an example I am playing with:

(See attached file: presentationtest.odp)


Finally, groups can be ungrouped by the author for editing purposes and in these cases we have a problem and need
connectors again.
 
>
>
>
> regards
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk

=?UTF-8?B?cHJlc2VudGF0aW9udGVzdC5vZHA=?=



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]