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"
<> 

06/28/2007 05:33 AM

Please respond to

<>

To

<>

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:  [mailto:] 

Sent: Thursday, June 28, 2007 4:25 AM

To: Andreas J. Guelzow

Cc: 

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 <>

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