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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Re: [dita] Which CALS Table model should we specify?


Paul Grosso <pgrosso@arbortext.com> wrote on 06/28/2004 04:20:29 PM:

> See the latest XML version of the Exchange table model at:
>
http://www.oasis-open.org/specs/tm9901.html
...
> I think the Exchange Table Model is sufficient and avoids some of
> the cruft of the CALS table model.
>
> However, I wouldn't object if other folks felt a strong need for the
> CALS table model (as long as I don't have to write the XSLT code to
> support spanspecs).


Good thoughts, Paul. Does anyone have particular passion for the full CALS model?

> What sorts of accessibility functionality is there in HTML tables?

The URL below contains a link to W3C techniques for making HTML tables accessible.  Its not that HTML tables are inherently accessible, but there are coding techniques for allowing readers to navigate the cells.  These are mostly very authoring-intensive methods, hence it would be great to provide some source "hints" that can alleviate the task of transforming the content into accessible HTML output.  That question was the topic of this message:

http://www.xslt.com/xsl-list/2002-08/msg00885.html

> I didn't even think PDF was accessible.


Again, apparently a matter of coding strategy. From my reading of articles such as the following, the accessible methods would have to be built into the function of FO composers such as FOP (output optimized for more accessible reading).  I'm not sure we could write transforms that produce "accessible FOs" that would produce intrinsically accessible PDF outside of some assist in the PDF writer.

http://www.planetpdf.com/mainpage.asp?webpageid=3456

> >Did you solve the problem by extending the source table DTD for
> authors to manage the necessary level of accessibility, or by adding
> the accessibility features during transforms (as IBM did), or by other means?
>
> I don't think we've broached this yet, but we are working in the accessibility
> area.  I'd be interested to hear more about what kind of
> accessibility IBM adds
> via the transforms.

The topic2html.xsl file in the dita13 toolkit implements a simple form of support for id and header attributes used by screen readers.  Look for lines like this:


<xsl:attribute name="headers">t<xsl:value-of select="$thisnum"/></xsl:attribute>

The problem, as expressed in Robert Anderson's note (above link), is relating spanned cells unabiguously to their respective headers, etc..  Robert was able to come up with an XSLT algorithm that worked at the time, but the W3C accessibility mavens keep coming up with ever more creative HTML methods that make the problem hard to close.  We never discovered whether anyone else using DocBook for Section 508-compliant HTML output has done similar work on those transforms.

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot



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