E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: deborah.kaplan@suberic.net
Date: Fri, Sep 02 2011 8:00AM
Subject: data or layout table
No previous message | Next message →

I need to make a website which shows thumbnail images of quilt
squares linking to more comprehensive information about those
same quilt squares, along with larger images. I think this is
best laid out as tables; tables reinforce the idea that the
column and row information is significant, and in this case
there's historical context that is preserved in the way the quilt
squares were put together.

Is this data table or a layout table? It's not a data table in
the classic sense, with row and column headers (and in order to
treat it as a data table I would have to force headers in some
way). But it's not a pure layout table either. It's important
information to know where the quilt squares fall relative to each
other.

What would be ideal from a screenreader perspective? From a
visual browser perspective it's irrelevant what I choose.

Thanks for any suggestions,

-Deborah

From: Jared Smith
Date: Fri, Sep 02 2011 8:48AM
Subject: Re: data or layout table
← Previous message | Next message →

On Fri, Sep 2, 2011 at 8:02 AM, < = EMAIL ADDRESS REMOVED = > wrote:

> What would be ideal from a screenreader perspective? From a
> visual browser perspective it's irrelevant what I choose.

If the natural reading order of the table (left to right, top to
bottom) is logical and makes sense, then I would not add table
headers. The overhead of the table markup would likely outweigh any
potential benefit it would provide.

Jared

From: Jared Smith
Date: Fri, Sep 02 2011 8:57AM
Subject: Re: data or layout table
← Previous message | Next message →

On Fri, Sep 2, 2011 at 8:02 AM, < = EMAIL ADDRESS REMOVED = > wrote:

> What would be ideal from a screenreader perspective? From a
> visual browser perspective it's irrelevant what I choose.

If the natural reading order of the table (left to right, top to
bottom) is logical and makes sense, then I would not add table
headers. The overhead of the table markup would likely outweigh any
potential benefit it would provide.

Jared

From: Duff Johnson
Date: Fri, Sep 02 2011 9:21AM
Subject: Re: data or layout table
← Previous message | Next message →

On Sep 2, 2011, at 10:48 AM, Jared Smith wrote:

>> What would be ideal from a screenreader perspective? From a
>> visual browser perspective it's irrelevant what I choose.
>
> If the natural reading order of the table (left to right, top to
> bottom) is logical and makes sense, then I would not add table
> headers. The overhead of the table markup would likely outweigh any
> potential benefit it would provide.

That's interesting... I have a different view... curious to get your thoughts.

1) Leaving aside the matter of non-Western languages, the logical reading order of a table is ambiguous. LRTB in many cases, TBLR in other cases.

Yes, this is a case in which HTML "natural reading order" may be disconnected from the content's "logical reading order" <g>.

2) "Logical and makes sense" isn't good enough to meet an "equivalent access" standard for tables because while the content might be comprehensible, if the logical relationships aren't explicit then the AT user has no way of determining the logical relationships and has no means of navigation.

Accordingly the need for table headers in HTML (and elsewhere), it seems to me, is a function of whether or not headers are logically present in the table, period.

Duff Johnson

US Committee for ISO/DIS 14289 (PDF/UA), Chair

p +1.617.283.4226
e = EMAIL ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com

From: Angela French
Date: Fri, Sep 02 2011 9:27AM
Subject: Re: data or layout table
← Previous message | Next message →

Jared - could you explain this: " The overhead of the table markup would likely outweigh any potential benefit it would provide." I have a similar situation with the presentation of document downloads on the site I'm working on. They are in tables, and that feels wrong to me.Maybe I'm worrying too much and overkilling it.
Angela French

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Friday, September 02, 2011 7:49 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] data or layout table

On Fri, Sep 2, 2011 at 8:02 AM, < = EMAIL ADDRESS REMOVED = > wrote:

> What would be ideal from a screenreader perspective? From a visual
> browser perspective it's irrelevant what I choose.

If the natural reading order of the table (left to right, top to
bottom) is logical and makes sense, then I would not add table headers. The overhead of the table markup would likely outweigh any potential benefit it would provide.

Jared

From: Jared Smith
Date: Fri, Sep 02 2011 9:51AM
Subject: Re: data or layout table
← Previous message | Next message →

On Fri, Sep 2, 2011 at 9:20 AM, Duff Johnson wrote:

> Accordingly the need for table headers in HTML (and elsewhere), it seems to me, is a function of whether or not headers are logically present in the table, period.

I agree that this is almost always the case. But sometimes data is
presented in a table in a way that makes sense visually, but when
accessed by a screen reader could be very confusing. In such cases,
adding headers (even perhaps keeping them hidden) might be best for
accessibility.

Consider Deborah's example of images, links, and a bit of information
presented in a table. It would make sense to a screen reader reader
user if the information is read left to right through rows as...
Image, link, info.
Image, link, info.
etc...

This would be little different than presenting them without a table
layout. Adding headers would just add overhead that is not necessary.

However, if the logical reading order is...
Image, image, image.
Link, link, link.
info, info, info.
etc...

... this would quickly become very difficult to comprehend linearly in
a screen reader, yet would still make perfect sense visually. The
presentation of each column visually (e.g., a column of image
thumbnails of quilt squares) presents information that a screen reader
user would not easily get. In this case, the addition of a column
header would greatly improve accessibility.

Hopefully that makes sense.

Jared

From: John Foliot
Date: Fri, Sep 02 2011 12:48PM
Subject: Re: data or layout table
← Previous message | Next message →

Jared Smith wrote:
>
> On Fri, Sep 2, 2011 at 9:20 AM, Duff Johnson wrote:
>
> > Accordingly the need for table headers in HTML (and elsewhere), it
> seems to me, is a function of whether or not headers are logically
> present in the table, period.
>
> I agree that this is almost always the case. But sometimes data is
> presented in a table in a way that makes sense visually, but when
> accessed by a screen reader could be very confusing. In such cases,
> adding headers (even perhaps keeping them hidden) might be best for
> accessibility.

+1

>
> Consider Deborah's example of images, links, and a bit of information
> presented in a table. It would make sense to a screen reader reader
> user if the information is read left to right through rows as...
> Image, link, info.
> Image, link, info.
> etc...
>
> This would be little different than presenting them without a table
> layout. Adding headers would just add overhead that is not necessary.
>
> However, if the logical reading order is...
> Image, image, image.
> Link, link, link.
> info, info, info.
> etc...
>
> ... this would quickly become very difficult to comprehend linearly in
> a screen reader, yet would still make perfect sense visually. The
> presentation of each column visually (e.g., a column of image
> thumbnails of quilt squares) presents information that a screen reader
> user would not easily get. In this case, the addition of a column
> header would greatly improve accessibility.
>
> Hopefully that makes sense.

It does to me Jared, but I will re-state it slightly differently to be
sure I understood you <grin>

If each cell in any row contains an image, info and link:

<td><a href="3b_info.html"><img alt="quilt square 3b"
longdesc="[if required/desired]"></a></td>

...then likely the addition of a header row(s) is likely not going to add
a lot of value.
However, if we had 3 cells:

<td><img></td> <td><a href></a></td> <td>info</td> - especially
if they are in subsequent rows

...then adding TH's would be critical for comprehension.

***********

Deborah, given that this is a quilt (and Mom does quilting, so I actually
know more about quilting than I should admit), it strikes me that what you
are really after is an actual grid construct (which table will give you).
The tricky part becomes how much association each adjacent cell (quilt
block) has to surrounding cells (other quilt blocks) - in my pseudo code
above you will notice that I added as alt text a "name" of the block
(quilt square 3b) which hints at which cell it likely is: I will assume
that there will also be surrounding/related text (instructions) that could
also help clarify this to end users, as well as the linked text about that
quilt block itself.

I really think that this is a case where "figuring out accessibility"
requires some thinking "outside of the box", and not just an instant
response to what a validator would suggest: through good use of language
we can also help build the visual model that a quilt comprises - a series
of individual blocks, stitched together to create a larger whole. I
suspect that if you did something like what I have suggested, then you
actually could consider your table a layout table, and could add the ARIA
role="presentation" to the <table> - although I would want to test this
with screen readers before rolling it out. <=== !important

JF's $0.02 worth

From: Sailesh Panchang
Date: Fri, Sep 02 2011 1:15PM
Subject: Re: data or layout table
← Previous message | Next message →

Generally, I am not in favor of adding a row , say off-screen, that
contains column headers for a data table that has no visible column
headers.
1. If a table makes sense when read row-wise, then consider marking
cells in col#1 as TH or using scope=row in col#2 (if col#2 serves as a
better row header).
Else add a brief summary: "Read this table row by row" for a table
with image, link, some info in each row- type of table.
2. And lastly if the logical reading order is to read down col#1 then
col#2 etc. then the design needs to be altered:
Use an outer a layout-table with 1 row and 3 cells to contain a table
in each cell.
A DIV can also be used as a container instead of the layout table if
one chooses.
I also recommend this when I see a 4-col table in which cells in
col#1 and 3 serve as labels for cells in col2 and 4 respectively. Here
use two 2-col data tables in a outer div or layout table.
Sailesh Panchang


On 9/2/11, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> Jared Smith wrote:
>>
>> On Fri, Sep 2, 2011 at 9:20 AM, Duff Johnson wrote:
>>
>> > Accordingly the need for table headers in HTML (and elsewhere), it
>> seems to me, is a function of whether or not headers are logically
>> present in the table, period.
>>
>> I agree that this is almost always the case. But sometimes data is
>> presented in a table in a way that makes sense visually, but when
>> accessed by a screen reader could be very confusing. In such cases,
>> adding headers (even perhaps keeping them hidden) might be best for
>> accessibility.
>
> +1
>
>>
>> Consider Deborah's example of images, links, and a bit of information
>> presented in a table. It would make sense to a screen reader reader
>> user if the information is read left to right through rows as...
>> Image, link, info.
>> Image, link, info.
>> etc...
>>
>> This would be little different than presenting them without a table
>> layout. Adding headers would just add overhead that is not necessary.
>>
>> However, if the logical reading order is...
>> Image, image, image.
>> Link, link, link.
>> info, info, info.
>> etc...
>>
>> ... this would quickly become very difficult to comprehend linearly in
>> a screen reader, yet would still make perfect sense visually. The
>> presentation of each column visually (e.g., a column of image
>> thumbnails of quilt squares) presents information that a screen reader
>> user would not easily get. In this case, the addition of a column
>> header would greatly improve accessibility.
>>
>> Hopefully that makes sense.
>
> It does to me Jared, but I will re-state it slightly differently to be
> sure I understood you <grin>
>
> If each cell in any row contains an image, info and link:
>
> <td><a href="3b_info.html"><img alt="quilt square 3b"
> longdesc="[if required/desired]"></a></td>
>
> ...then likely the addition of a header row(s) is likely not going to add
> a lot of value.
> However, if we had 3 cells:
>
> <td><img></td> <td><a href></a></td> <td>info</td> - especially
> if they are in subsequent rows
>
> ...then adding TH's would be critical for comprehension.
>
> ***********
>
> Deborah, given that this is a quilt (and Mom does quilting, so I actually
> know more about quilting than I should admit), it strikes me that what you
> are really after is an actual grid construct (which table will give you).
> The tricky part becomes how much association each adjacent cell (quilt
> block) has to surrounding cells (other quilt blocks) - in my pseudo code
> above you will notice that I added as alt text a "name" of the block
> (quilt square 3b) which hints at which cell it likely is: I will assume
> that there will also be surrounding/related text (instructions) that could
> also help clarify this to end users, as well as the linked text about that
> quilt block itself.
>
> I really think that this is a case where "figuring out accessibility"
> requires some thinking "outside of the box", and not just an instant
> response to what a validator would suggest: through good use of language
> we can also help build the visual model that a quilt comprises - a series
> of individual blocks, stitched together to create a larger whole. I
> suspect that if you did something like what I have suggested, then you
> actually could consider your table a layout table, and could add the ARIA
> role="presentation" to the <table> - although I would want to test this
> with screen readers before rolling it out. <=== !important
>
> JF's $0.02 worth
>
>
>

From: deborah.kaplan@suberic.net
Date: Fri, Sep 02 2011 1:21PM
Subject: Re: data or layout table
← Previous message | Next message →

The nuance in this conversation is fascinating; thanks, guys.

In this case, the quilt is 16 by 6, so there's a fair number of
panels. I definitely like the idea of providing some structure to
make it easier to navigate (so, for example, if someone remembers
they were the contributor to the panel in column 13, row 3, it
becomes easier to navigate to that panel). Using a table instead
of a CSS grid seems to provide that structure.

John, good point about providing the row/column information in
the alt text. I have that metadata available to me (and it's how
I will be laying out the HTML in the first place), so there's no
reason not to add it to the image title.

John said,

> I will assume that there will also be surrounding/related text (instructions) that could also help clarify this to end users, as well as the linked text about that quilt block itself.

Indeed!

> I really think that this is a case where "figuring out accessibility" requires some thinking "outside of the box"

Yes, this is definitely one of those occasions where
accessibility is all about subtleties.

And on that note, I have another question about this same
project, because I have some idea about how to design for screen
readers but I admit I am terrible at designing for magnification.
Because this quilt is 16 by 6, it's very wide. I'm torn between
leaving it as it is with the understanding that people will have
to use their horizontal scrollbars on pretty much any monitor, or
rotating the whole thing 90° -- which means the thumbnails will
be on their sides. The latter seems much more sensible to me, but
I don't know if that would cause visual or cognitive problems.

-Deborah

From: Jared Smith
Date: Fri, Sep 02 2011 1:27PM
Subject: Re: data or layout table
← Previous message | No next message

On Fri, Sep 2, 2011 at 12:42 PM, John Foliot wrote:

> However, if we had 3 cells:
>
>        <td><img></td>  <td><a href></a></td>  <td>info</td> - especially
> if they are in subsequent rows
>
> ...then adding TH's would be critical for comprehension.

Not necessarily. The table headers aren't vital in this situation
either because the content is no less comprehensible than if it were
outside a table. If the screen reader just reads through the content
in order, it makes sense. As Deborah indicated, it's not really data
being presented - it's just linear information with borders around
them. Headers would add unnecessary overhead.

As you note, CSS to control this presentation would be better, but
would read no different and be no more or less accessible than if it
were in a layout table (so long as you don't complicate things by
adding table headers).

But what if there were 10 items per row instead of 3? Then this is
starting to look more like data than presentation and headers would
probably help. You might ask, "Is it likely that the user would want
or need to navigate up and down through columns?" If so, it's probably
data and should have headers. Yes, I realize this is not well defined.

Now if the layout were:

<tr>
<td><img></td> <td><img></td> <td><img></td>
</tr>
<tr>
<td><a href></a></td> <td><a href></a></td> <td><a href></a></td>
</tr>
etc.

... this would be confusing if read linearly in a layout table,
especially if there were more than a few columns or rows. And there
would be no easy way to navigate the table columns to determine which
image goes with which link, etc. In this case, headers would be
necessary.

This is certainly one of those fuzzy areas of accessibility.

<plug type=shamless>
I'll be speaking on these types of things at the Accessibility Summit
later this month -
http://environmentsforhumans.com/2011/accessibility-summit/
You can also vote today for a SXSW proposal I have on this topic -
http://panelpicker.sxsw.com/ideas/view/12184
</plug>

Jared