Guessing layout vs. data table

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Guessing layout vs. data table

Aaron Leventhal-3
I'm planning to implement a heuristic the provides screen readers with a
  "guess" as to whether a table is for layout vs. data.

Something like:

Roughly something like
1. If a table includes data-specific markup such as th, caption,
summary, scope, axis, headers: data table
2. If a table does not style the width of itself: data table
3. If a table has 1-2 columns: layout
4. If a table has 1 row: layout
5. If a table has < 12 cells and no visual borders to differentiate the
cells, layout
6. If a table has another table inside of one of the cells, and no
visual borders to differentiate the cells: layout
7. If a table has rowspan or colspan markup, but no visual borders:
layout table
8. If table has set the width to be as wide as the rest of the content,
and has no visual borders to differentiate the cells: layout
9. Otherwise, data table

Rule #3 & #4 already work pretty well, because table navigation isn't
all that crucial for a 2 column or 1 row table. You may as well just
present it as straight text then, it doesn't really affect usability of
the table.

We could also try to arrange this as a point scoring system of some
kind, but I'm not sure it's necessary. My guess is that if we run with
those rules and just provide it as a hint, we can eventually tweak it to
be pretty accurate.

Would love feedback/fixes/ideas:

Thanks,
- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Gregory J. Rosmaita
aloha, aaron!

first, i heartily second jason's configurability and manual
override requests; as far as your list is concerned, to
it i would add the following:

* any FORM or FORM controls embedded in a TABLE or multiple
nested tables

so that filling out order forms and using various web-based email clients which use TABLE to control FORM layout is made (a) possible, (b) efficient, and (c) more reliable - in fact, one could use cues within the table to create pseudo FIELDSETs, LEGENDs, and - most importantly - LABEL (so that the user can ascertain with certainty what TD is intended to serve as a visual label for the form control),

sad that such a solution is still necessary when control over FORM layout can be achieved through the use of proper markup (FIELDSET, LEGEND, and LABEL) in conjunction with CSS2...

gregory.
----------------------------------------------------------------------------
Advice: The smallest current coin. -- Ambrose Bierce, The Devil's Dictionary
----------------------------------------------------------------------------
Gregory J. Rosmaita: [hidden email] AND [hidden email]
Camera Obscura: http://www.hicom.net/~oedipus/
VICUG NYC: http://www.hicom.net/~oedipus/vicug/
United Blind Advocates for Talking Signs: http://ubats.org
----------------------------------------------------------------------------


>I'm planning to implement a heuristic the provides screen readers with a
> "guess" as to whether a table is for layout vs. data.
>
>Something like:
>
>Roughly something like
>1. If a table includes data-specific markup such as th, caption,
>summary, scope, axis, headers: data table
>2. If a table does not style the width of itself: data table
>3. If a table has 1-2 columns: layout
>4. If a table has 1 row: layout
>5. If a table has < 12 cells and no visual borders to differentiate the
>cells, layout
>6. If a table has another table inside of one of the cells, and no
>visual borders to differentiate the cells: layout
>7. If a table has rowspan or colspan markup, but no visual borders:
>layout table
>8. If table has set the width to be as wide as the rest of the content,
>and has no visual borders to differentiate the cells: layout
>9. Otherwise, data table
>
>Rule #3 & #4 already work pretty well, because table navigation isn't
>all that crucial for a 2 column or 1 row table. You may as well just
>present it as straight text then, it doesn't really affect usability of
>the table.
>
>We could also try to arrange this as a point scoring system of some
>kind, but I'm not sure it's necessary. My guess is that if we run with
>those rules and just provide it as a hint, we can eventually tweak it to
>be pretty accurate.
>
>Would love feedback/fixes/ideas:
>
>Thanks,
>- Aaron


-------------------
Email sent using AnyEmail from http://www.hicom.net

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Jason White
In reply to this post by Aaron Leventhal-3
On Thu, Jun 29, 2006 at 08:06:17PM -0400, Aaron Leventhal wrote:
> Would love feedback/fixes/ideas:
The heuristics seem well planned. When roles for tables are
defined/implemented, they should of course override any such algorithm. Are
you planning to include an option whereby the user can make the decision
manually if your algorithm gives a wrong result? For Web sites that one uses
frequently this would be a desirable configuration option.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
At the moment we're just planning on providing a hint to the screen
reader. They're responsible for deciding what to do with it or even
whether to use it at all, so any configuration options etc. are on their
end.

- Aaron

Jason White wrote:
> On Thu, Jun 29, 2006 at 08:06:17PM -0400, Aaron Leventhal wrote:
>> Would love feedback/fixes/ideas:
> The heuristics seem well planned. When roles for tables are
> defined/implemented, they should of course override any such algorithm. Are
> you planning to include an option whereby the user can make the decision
> manually if your algorithm gives a wrong result? For Web sites that one uses
> frequently this would be a desirable configuration option.
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Guessing layout vs. data table

T.V Raman
In reply to this post by Aaron Leventhal-3

Also, add tables that have a non-negligible percentage of empty
cells.


Aaron Leventhal writes:
 > I'm planning to implement a heuristic the provides screen readers with a
 >   "guess" as to whether a table is for layout vs. data.
 >
 > Something like:
 >
 > Roughly something like
 > 1. If a table includes data-specific markup such as th, caption,
 > summary, scope, axis, headers: data table
 > 2. If a table does not style the width of itself: data table
 > 3. If a table has 1-2 columns: layout
 > 4. If a table has 1 row: layout
 > 5. If a table has < 12 cells and no visual borders to differentiate the
 > cells, layout
 > 6. If a table has another table inside of one of the cells, and no
 > visual borders to differentiate the cells: layout
 > 7. If a table has rowspan or colspan markup, but no visual borders:
 > layout table
 > 8. If table has set the width to be as wide as the rest of the content,
 > and has no visual borders to differentiate the cells: layout
 > 9. Otherwise, data table
 >
 > Rule #3 & #4 already work pretty well, because table navigation isn't
 > all that crucial for a 2 column or 1 row table. You may as well just
 > present it as straight text then, it doesn't really affect usability of
 > the table.
 >
 > We could also try to arrange this as a point scoring system of some
 > kind, but I'm not sure it's necessary. My guess is that if we run with
 > those rules and just provide it as a hint, we can eventually tweak it to
 > be pretty accurate.
 >
 > Would love feedback/fixes/ideas:
 >
 > Thanks,
 > - Aaron
 > _______________________________________________
 > dev-accessibility mailing list
 > [hidden email]
 > https://lists.mozilla.org/listinfo/dev-accessibility

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
GTalk:  [hidden email], [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Chris Ridpath
In reply to this post by Aaron Leventhal-3

Aaron Leventhal wrote:
> I'm planning to implement a heuristic the provides screen readers with a
>   "guess" as to whether a table is for layout vs. data.
>
Yalin Wang and Jianying Hu have written an interesting paper on table
type detection. Here's a link:
http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=511478

They developed an algorithm and tested it on about 14000 tables. One of
the things they found was that almost 90% of the tables used on the web
were for layout.

Cheers,
Chris

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Aaron Leventhal
Very cool! Thanks for that.

Now, since you've already read it, how about the reader's digest. How
should we modify the algorithm?
Not lazy, just busy :)  Just trying get the community to help at least
with planning and design -- this is open source!

- Aaron

Chris wrote:

> Aaron Leventhal wrote:
>  
>> I'm planning to implement a heuristic the provides screen readers with a
>>   "guess" as to whether a table is for layout vs. data.
>>
>>    
> Yalin Wang and Jianying Hu have written an interesting paper on table
> type detection. Here's a link:
> http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=511478
>
> They developed an algorithm and tested it on about 14000 tables. One of
> the things they found was that almost 90% of the tables used on the web
> were for layout.
>
> Cheers,
> Chris
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
>  
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Chris Ridpath
The easiest approach is just to tell authors to put <th> elements in their
data tables.
<th> elements must never appear in layout tables and always help in layout
tables.
That would make the detection really easy.
Chris

----- Original Message -----
From: "Aaron Leventhal" <[hidden email]>
To: "Chris" <[hidden email]>
Cc: <[hidden email]>
Sent: Friday, June 30, 2006 3:38 PM
Subject: Re: Guessing layout vs. data table


> Very cool! Thanks for that.
>
> Now, since you've already read it, how about the reader's digest. How
> should we modify the algorithm?
> - Aaron
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Aaron Leventhal
Chris,

Yes, that's fine if the authors use correct markup. We're also solving
problems on the many websites where authors don't do the right thing.

- Aaron

Chris Ridpath wrote:

> The easiest approach is just to tell authors to put <th> elements in
> their data tables.
> <th> elements must never appear in layout tables and always help in
> layout tables.
> That would make the detection really easy.
> Chris
>
> ----- Original Message ----- From: "Aaron Leventhal"
> <[hidden email]>
> To: "Chris" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Friday, June 30, 2006 3:38 PM
> Subject: Re: Guessing layout vs. data table
>
>
>> Very cool! Thanks for that.
>>
>> Now, since you've already read it, how about the reader's digest. How
>> should we modify the algorithm?
>> - Aaron
>>
>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Shane Anderson
In reply to this post by Aaron Leventhal-3
Aaron

I wonder about relying on borders in determining whether a table is used for
data or not. Some tables will use background color rather than borders to
denote row or column association.

Also, what is the thought process behind 12 cells in number 5? What tips the
scale at 12 cells?

Shane Anderson
WebAIM.org


On 6/29/06, Aaron Leventhal <[hidden email]> wrote:

>
> I'm planning to implement a heuristic the provides screen readers with a
>   "guess" as to whether a table is for layout vs. data.
>
> Something like:
>
> Roughly something like
> 1. If a table includes data-specific markup such as th, caption,
> summary, scope, axis, headers: data table
> 2. If a table does not style the width of itself: data table
> 3. If a table has 1-2 columns: layout
> 4. If a table has 1 row: layout
> 5. If a table has < 12 cells and no visual borders to differentiate the
> cells, layout
> 6. If a table has another table inside of one of the cells, and no
> visual borders to differentiate the cells: layout
> 7. If a table has rowspan or colspan markup, but no visual borders:
> layout table
> 8. If table has set the width to be as wide as the rest of the content,
> and has no visual borders to differentiate the cells: layout
> 9. Otherwise, data table
>
> Rule #3 & #4 already work pretty well, because table navigation isn't
> all that crucial for a 2 column or 1 row table. You may as well just
> present it as straight text then, it doesn't really affect usability of
> the table.
>
> We could also try to arrange this as a point scoring system of some
> kind, but I'm not sure it's necessary. My guess is that if we run with
> those rules and just provide it as a hint, we can eventually tweak it to
> be pretty accurate.
>
> Would love feedback/fixes/ideas:
>
> Thanks,
> - Aaron
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Guessing layout vs. data table

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
The lack of borders doesn't necessarily mean something is data but it's
a hint. We could also try to look for background color, but I'm not sure
what the rule would be.

It could be that the rule for #5 is weak, but 12 cells was just a guess.
I think most layout tables don't actually have that many cells.

Again, this is just a hint to the screen reader, which can make up it's
own rules, and we can tweak this.

- Aaron

Shane Anderson wrote:

> Aaron
>
> I wonder about relying on borders in determining whether a table is used
> for
> data or not. Some tables will use background color rather than borders to
> denote row or column association.
>
> Also, what is the thought process behind 12 cells in number 5? What tips
> the
> scale at 12 cells?
>
> Shane Anderson
> WebAIM.org
>
>
> On 6/29/06, Aaron Leventhal <[hidden email]> wrote:
>>
>> I'm planning to implement a heuristic the provides screen readers with a
>>   "guess" as to whether a table is for layout vs. data.
>>
>> Something like:
>>
>> Roughly something like
>> 1. If a table includes data-specific markup such as th, caption,
>> summary, scope, axis, headers: data table
>> 2. If a table does not style the width of itself: data table
>> 3. If a table has 1-2 columns: layout
>> 4. If a table has 1 row: layout
>> 5. If a table has < 12 cells and no visual borders to differentiate the
>> cells, layout
>> 6. If a table has another table inside of one of the cells, and no
>> visual borders to differentiate the cells: layout
>> 7. If a table has rowspan or colspan markup, but no visual borders:
>> layout table
>> 8. If table has set the width to be as wide as the rest of the content,
>> and has no visual borders to differentiate the cells: layout
>> 9. Otherwise, data table
>>
>> Rule #3 & #4 already work pretty well, because table navigation isn't
>> all that crucial for a 2 column or 1 row table. You may as well just
>> present it as straight text then, it doesn't really affect usability of
>> the table.
>>
>> We could also try to arrange this as a point scoring system of some
>> kind, but I'm not sure it's necessary. My guess is that if we run with
>> those rules and just provide it as a hint, we can eventually tweak it to
>> be pretty accurate.
>>
>> Would love feedback/fixes/ideas:
>>
>> Thanks,
>> - Aaron
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility