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 caption proposal comments


Bruce,

I modified the caption proposal to replace the target id for describedby to be <draw:text-box> vs. <text:p>. The reason is that we discovered later that the caption can have multiple <text:p> per the schema and therefore the encapsulating text box should be the target id. This of course does not change the schema but it does change the ODF specification.

Where is the TC at on the caption proposal. Has it agreed to use describedBy or are they wanting to do something more heavyweight like introducing a caption element?

Captions are not clearly associated with the drawing objects which they caption and this is needed for accessibility.

Establish clear relationship between a drawing objects and its caption by including a new optional draw:describedby attribute to the following drawing objects.


<draw:rect>
<draw:line>
<draw:polyline>
<draw:polygon>
<draw:regular-polygon>
<draw:path>
<draw:circle>
<draw:ellipse>
<draw:g>
<draw:page-thumbnail>
<draw:measure>
<draw:caption>
<draw:connector>
<draw:control>
<dr3d:scene>
<draw-custom-shape>
<dr3d:scene>
<draw:frame>

draw:describedby shall take a value of IDREF. The value for draw:describedby attribute shall be the target id assigned to the <draw:text-box> used to represent the corresponding caption. As text:p is an XML element it may have an ID assigned by default. The following attribute list should be included as optional to the above drawing objects:

<define name="common-draw-describedby-attlist" combine="interleave">
<attribute name="draw:desribedby">
<ref name="IDREF"/>
</attribute>
</define>

When a caption is assigned by a user agent, an id must be assigned to the element containing the text used to caption a drawing element. The drawing element being captioned must then be assigned the draw:describedby attribute with an IDREF equivalent to the id of the captioning text thus establishing a relationship between the captioned text and the object captioned as needed for accessibility. Removing the caption should result in removing the draw:describedby attribute of the object that was being captioned.

If the user agent supports a platform which provides a draw:describedby relationship in its accessibility API, this relationship for captions should be used to fulfill the relationship.


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
Inactive hide details for "Bruce D'Arcus" <bruce.darcus@OpenDocument.us>"Bruce D'Arcus" <bruce.darcus@OpenDocument.us>


          "Bruce D'Arcus" <bruce.darcus@OpenDocument.us>

          06/05/2006 04:03 PM


To

office@lists.oasis-open.org

cc


Subject

Re: [office] accessibility caption proposal comments


On Jun 5, 2006, at 4:44 PM, Dave Pawson wrote:

>> > How do you see one as better than the other?
>>
>> OK, let's break apart two separate issues: association and semantics.
>>
>> On the second, my contention is that "caption" is an important
>> semantic
>> structure, and so deserves its own element. To say something is
>> "describedBy" is -- per above -- rather vague.
>
> I'm sure we could argue that either way.
> Caption has fairly clear semantics to me, but my gut
> reaction is that it's a brief, rather than full description?

Sounds right.

>> If we ARE going to go down the road of using attributes to make this
>> association, then I think:
>>
>> a) we need to give it much more thought so that we adopt a consistent
>> approach to these problems
>> b) it needs to happen in conjunction with the metadata effort
>
> No real arguments.
>
> I'm willing to support a nested  text equivalent to an image
> or drawing. Naming to be agreed on.
> Not sure I'd support RDF to mark up such a description.
> Simple inlines and some block (probably basic para class of markup)
> would seem natural to me?

We're still a ways away from a specific suggestion for that use case
(and the TC has still to approve the use cases in any case, once we
finish them!), but my hunch in writing it was that the caption would
indeed be plain text, but that it might possibly be auto-generated from
separate metadata, either embedded in the image (a la XMP), or stored
somewhere in the file wrapper. So, yeah, we're on the same page.

There has, however, also been some discussion of adding metadata within
the content file by using the existing style system (but enhanced with
an optional uri), but we're not yet at the stage where we're discussing
that in any depth. You could imagine, though, that it could involve
tagging a title within a caption with a "title" span style, which
happened to have a uri that corresponded to dc:title. Presumably that
could be helpful for accessibility since not only would the software
know it is now reading, say, a caption for an image, but also when it
comes across its title.

Bruce


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


GIF image



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