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
- From: Pete Brunet <brunet@us.ibm.com>
- To: <mpaciello@paciellogroup.com>
- Date: Thu, 28 Jun 2007 09:04:16 -0500
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
<mpaciello@paciellogroup.com> |
|
To
| <office-accessibility@lists.oasis-open.org>
|
cc
|
|
Subject
| [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.
Cheers,
Lars
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]