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] FW: [office] merging nested tables withsurrounding table

Mike, Lars is saying what I think everyone on the WG has already committed to.

A nit in Lars text - he said, "Such tools only provide a limited navigational context."  This is because the only thing an AT can provide for structural orientation (besides row/col header info) is the row/col address - the addressing scheme defined for ODF subtables is the source of the problem.

After the Monday WG meeting the action item for the WG was to find use cases where subtables are useful other than for when cells are split or merged.

Pete Brunet

IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, TL 678-4594, Fax: (512) 838-9666
Ionosphere: WS4G

"Mike Paciello" <mpaciello@paciellogroup.com>

06/28/2007 05:33 AM
Please respond to

[office-accessibility] FW: [office] merging nested tables with surrounding table

Folks -

I'm following this thread -- please note Lars Oppermann's latest request.
Pete -- is Lar's proposal in line with your recommendation?

- Mike

Mike Paciello
Cell: +1.603.566.7713

-----Original Message-----
From: Lars.Oppermann@Sun.COM [mailto:Lars.Oppermann@Sun.COM]
Sent: Thursday, June 28, 2007 4:25 AM
To: Andreas J. Guelzow
Cc: office@lists.oasis-open.org
Subject: Re: [office] merging nested tables with surrounding table

The request from the accessibility SC is based on the finding, that
nested tables are hard to use with A11Y tools. Such tools only provide a
limited navigational context.

The specification allows for both, nested tables and row/colspans. In
the case of a nested table, the specification also provides the
is-subtable attribute, which merges the nested table with the
surrounding cell.

This means, that implementors of editors currently have a choice of what
kind of structure they generate when implementing a function like "split
this cell" or "merge these two cells".

I think the request of the A11Y SC is mainly about providing guidance to
implementors to prefer the use of col/rowspan for such functions. If
subtables are preferred, the resulting documents are harder to use in an
A11Y context.

So what I would propose for the specification is to state in the
description of is-subtable, that using nested table structures may be
problematic for non-visual renditions of the documents. Henceforth,
col/rowspan should be used whenever appropriate to make the resulting
document more accessible.


Andreas J. Guelzow wrote:
> On Wed, 2007-27-06 at 17:13 +0200, Thomas Zander wrote:
>> On Wednesday 27 June 2007 16:48:37 Andreas J Guelzow wrote:
>>> See above example. Failure to provide such support would complicate the
>>> description of that table.
>> To be sure we are talking about the same thing; the example you gave is
>> naturally still possible using subtables.  I have not seen any suggestion

>> to remove that feature.
> I understand the initial request of the accessibility sc to suggest
> exactly that. At least the argument made are applicable to any kind of
> subtable.
> Andreas

Sun Microsystems                Lars Oppermann <lars.oppermann@sun.com>
Nagelsweg 55                    Software Engineer
20097 Hamburg, Germany          Phone: +49 40 23646 959
http://www.sun.com/             Fax:   +49 40 23646 550
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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