TBODY

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

TBODY

Gian Wild-2
Hi all

Does anyone know how screen readers handle TBODY?

Cheers,
Gian

--
Gian Wild
Accessibility Specialist
web. www.gianwild.com.au
email. [hidden email]
mobile. 042 442 6262
Reply | Threaded
Open this post in threaded view
|

RE: TBODY

Steve Green-5
They ignore it.


From: [hidden email] [[hidden email]] on behalf of Gian Wild [[hidden email]]
Sent: 09 January 2013 07:06
To: [hidden email]
Subject: TBODY

Hi all

Does anyone know how screen readers handle TBODY?

Cheers,
Gian

--
Gian Wild
Accessibility Specialist
web. www.gianwild.com.au
email. [hidden email]
mobile. 042 442 6262
Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Olaf Drümmer
In reply to this post by Gian Wild-2
Hi Gian,

On 9 Jan 2013, at 08:06, Gian Wild wrote:

Does anyone know how screen readers handle TBODY?

any understanding or requests how they should handle it?

Olaf

Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Andy Keyworth
In reply to this post by Gian Wild-2

 

 

> Hi Gian,

> On 9 Jan 2013, at 08:06, Gian Wild wrote:

> Does anyone know how screen readers handle TBODY?

> any understanding or requests how they should handle it?

> Olaf

 

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484 
email. [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Andy Keyworth
In reply to this post by Gian Wild-2

Hi,

 

Thought I’d jump in on this one- I tested some simple HTML tables (both with and without the <TBODY> element) using JAWS 10.0 and NVDA 2012.2.1. None of these seemed to recognize, or change behavior due to, <TBODY>.

 

I’m hard-pressed to think of an example or situation where changing screen reader behaviour for <TBODY> would really be mandated; it’s an under-utilized element; many tables have header cells right inside what we’d consider the table body, anyway; and well-structured, accessible tables are possible anyway.

 

 

>Hi Gian,

>On 9 Jan 2013, at 08:06, Gian Wild wrote:

>Does anyone know how screen readers handle TBODY?

>any understanding or requests how they should handle it?

>Olaf

 

(Apologies for the accidental duplicate message sent earlier.)

 

Cheers,

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484 
email. [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Userite
Hi Andy,
 
The <tbody>, <thead> and <tfoot> elements were designed to be used when printing a long tables via a printer (not a screen). Their purpose was to repeat the header cells on the top of each page so that continuation sheets are easier to understand. Most spread-sheet programmes such as MS Excel have this function built in under their print options.
 
If you have a long table in HTML you *can* use CSS to fix the horizontal position of the <thead> and <tfoot> blocks so that the main data part of the table rolls up and down within a frame. I have done this as an exercise with students – but I have never seen it done in the real world. However this is a method for visual presentation and so of no use to a screen reader which already has the function to repeat the relevant <th> cells whenever requested.
 
In practice, 99% of the times that I come across <tbody> etc. it is just cluttering up the HTML code to no purpose whatsoever.
 
Regards
Richard
Sent: Monday, January 21, 2013 7:09 PM
Subject: Re: TBODY
 

Hi,

 

Thought I’d jump in on this one- I tested some simple HTML tables (both with and without the <TBODY> element) using JAWS 10.0 and NVDA 2012.2.1. None of these seemed to recognize, or change behavior due to, <TBODY>.

 

I’m hard-pressed to think of an example or situation where changing screen reader behaviour for <TBODY> would really be mandated; it’s an under-utilized element; many tables have header cells right inside what we’d consider the table body, anyway; and well-structured, accessible tables are possible anyway.

 

 

>Hi Gian,

>On 9 Jan 2013, at 08:06, Gian Wild wrote:

>Does anyone know how screen readers handle TBODY?

>any understanding or requests how they should handle it?

>Olaf

 

(Apologies for the accidental duplicate message sent earlier.)

 

Cheers,

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484
email. [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

RE: TBODY

Andy Keyworth

Makes sense, Richard- thanks!

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484 
email. [hidden email]

 

From: Userite [mailto:[hidden email]]
Sent: January-22-13 2:58 PM
To: Andy Keyworth; [hidden email]
Subject: Re: TBODY

 

Hi Andy,

 

The <tbody>, <thead> and <tfoot> elements were designed to be used when printing a long tables via a printer (not a screen). Their purpose was to repeat the header cells on the top of each page so that continuation sheets are easier to understand. Most spread-sheet programmes such as MS Excel have this function built in under their print options.

 

If you have a long table in HTML you *can* use CSS to fix the horizontal position of the <thead> and <tfoot> blocks so that the main data part of the table rolls up and down within a frame. I have done this as an exercise with students – but I have never seen it done in the real world. However this is a method for visual presentation and so of no use to a screen reader which already has the function to repeat the relevant <th> cells whenever requested.

 

In practice, 99% of the times that I come across <tbody> etc. it is just cluttering up the HTML code to no purpose whatsoever.

 

Regards

Richard

Sent: Monday, January 21, 2013 7:09 PM

Subject: Re: TBODY

 

Hi,

 

Thought I’d jump in on this one- I tested some simple HTML tables (both with and without the <TBODY> element) using JAWS 10.0 and NVDA 2012.2.1. None of these seemed to recognize, or change behavior due to, <TBODY>.

 

I’m hard-pressed to think of an example or situation where changing screen reader behaviour for <TBODY> would really be mandated; it’s an under-utilized element; many tables have header cells right inside what we’d consider the table body, anyway; and well-structured, accessible tables are possible anyway.

 

 

>Hi Gian,

>On 9 Jan 2013, at 08:06, Gian Wild wrote:

>Does anyone know how screen readers handle TBODY?

>any understanding or requests how they should handle it?

>Olaf

 

(Apologies for the accidental duplicate message sent earlier.)

 

Cheers,

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484
email. [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

RE: TBODY

Roger Hudson-2
In reply to this post by Userite

I would be very interested to know how screen magnifiers such Zoom Text and Magic handle thead.

 

Thanks,

Roger

 

From: Userite [mailto:[hidden email]]
Sent: Wednesday, 23 January 2013 6:58 AM
To: Andy Keyworth; [hidden email]
Subject: Re: TBODY

 

Hi Andy,

 

The <tbody>, <thead> and <tfoot> elements were designed to be used when printing a long tables via a printer (not a screen). Their purpose was to repeat the header cells on the top of each page so that continuation sheets are easier to understand. Most spread-sheet programmes such as MS Excel have this function built in under their print options.

 

If you have a long table in HTML you *can* use CSS to fix the horizontal position of the <thead> and <tfoot> blocks so that the main data part of the table rolls up and down within a frame. I have done this as an exercise with students – but I have never seen it done in the real world. However this is a method for visual presentation and so of no use to a screen reader which already has the function to repeat the relevant <th> cells whenever requested.

 

In practice, 99% of the times that I come across <tbody> etc. it is just cluttering up the HTML code to no purpose whatsoever.

 

Regards

Richard

Sent: Monday, January 21, 2013 7:09 PM

Subject: Re: TBODY

 

Hi,

 

Thought I’d jump in on this one- I tested some simple HTML tables (both with and without the <TBODY> element) using JAWS 10.0 and NVDA 2012.2.1. None of these seemed to recognize, or change behavior due to, <TBODY>.

 

I’m hard-pressed to think of an example or situation where changing screen reader behaviour for <TBODY> would really be mandated; it’s an under-utilized element; many tables have header cells right inside what we’d consider the table body, anyway; and well-structured, accessible tables are possible anyway.

 

 

>Hi Gian,

>On 9 Jan 2013, at 08:06, Gian Wild wrote:

>Does anyone know how screen readers handle TBODY?

>any understanding or requests how they should handle it?

>Olaf

 

(Apologies for the accidental duplicate message sent earlier.)

 

Cheers,

 

Andy Keyworth
Senior Web Accessibility Specialist | T-Base Communications Inc.
19 Main Street │ Ottawa, ON │ K1S 1A9
telephone. 613. 236. 0866 Ext. 256 │ fax. 613. 236. 0484
email. [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

RE: TBODY

Jan Eric Hellbusch
In reply to this post by Userite
Hi Richard,

> In practice, 99% of the times that I come across <tbody> etc. it is just cluttering
> up the HTML code to no purpose whatsoever.

Agree.
Over the years many people claimed THEAD, TFOOT and TBODY should be used properly, so screenreaders can deal with the data. The only thing that sort of went wrong was that when using those elements correctly, the footer is placed between header and bodies. The reading sequence was then obviously incorrect.

Because the elements are for printers and not for screenreaders, I tried to get people to use them only for long tables and even then the sequence (head, footer, bodies) was not satisfactory. It seems that JAWS has fixed this issue since version 11. Tables marked up with THEAD, TFOOT and TBODY can be read in correct order in JAWS when using table navigation key strokes.

Jan


--
Jan Eric Hellbusch
Tel.: +49 (231) 86436760 oder +49 (163) 3369925
Web: http://2bweb.de     Twitter: www.twitter.com/2bweb
--
Das Buch über barrierefreies Webdesign:
"Barrierefreiheit verstehen und umsetzen - Webstandards für ein zugängliches und nutzbares Internet"
812 Seiten, Dpunkt Verlag (2011)
http://www.barrierefreies-webdesign.de/dpunkt/




Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Ramón Corominas
I am not sure that the reading order of a table should always be
thead-tbody-tfoot. Maybe it seems more logical, but in many cases it can
also reduce usability.

Most tables that have a <tfoot> include important information there such
as footnotes or global information for the table that users must know to
understand the main <tbody> information. In my opinion, screen readers
should provide an option to indicate the order in which the user wants
to read <tfoot> information.

Regards,
Ramón.

Jan wrote:


>> In practice, 99% of the times that I come across <tbody> etc. it is just cluttering
>> up the HTML code to no purpose whatsoever.
>
> Agree.
> Over the years many people claimed THEAD, TFOOT and TBODY should be used properly, so screenreaders can deal with the data. The only thing that sort of went wrong was that when using those elements correctly, the footer is placed between header and bodies. The reading sequence was then obviously incorrect.
>
> Because the elements are for printers and not for screenreaders, I tried to get people to use them only for long tables and even then the sequence (head, footer, bodies) was not satisfactory. It seems that JAWS has fixed this issue since version 11. Tables marked up with THEAD, TFOOT and TBODY can be read in correct order in JAWS when using table navigation key strokes.


Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Userite
Hi Ramon,

I like your optimism
>>In my opinion, screen readers should provide an option to indicate the
>>order in which the user wants to read <tfoot> information.<<

However, as Jan says, it only recently that Jaws has worked out how to
deliver <tfoot> AFTER the table data. (Remember Jaws cost $1,000 !!)

If the <tfoot> contains global information then it is in the wrong place.
global information should be presented before the data (perhaps in the
summary :)

Let's admit it, <tbody> etc. should only be used when you are offering your
visitor a printable option.

Regards
Richard
www.userite.com


-----Original Message-----
From: Ramón Corominas
Sent: Thursday, January 24, 2013 8:01 PM
To: Jan Eric Hellbusch
Cc: 'Userite' ; 'Andy Keyworth' ; [hidden email]
Subject: Re: TBODY

I am not sure that the reading order of a table should always be
thead-tbody-tfoot. Maybe it seems more logical, but in many cases it can
also reduce usability.

Most tables that have a <tfoot> include important information there such
as footnotes or global information for the table that users must know to
understand the main <tbody> information. In my opinion, screen readers
should provide an option to indicate the order in which the user wants
to read <tfoot> information.

Regards,
Ramón.

Jan wrote:


>> In practice, 99% of the times that I come across <tbody> etc. it is just
>> cluttering
>> up the HTML code to no purpose whatsoever.
>
> Agree. Over the years many people claimed THEAD, TFOOT and TBODY should be
> used properly, so screenreaders can deal with the data. The only thing
> that sort of went wrong was that when using those elements correctly, the
> footer is placed between header and bodies. The reading sequence was then
> obviously incorrect.
> Because the elements are for printers and not for screenreaders, I tried
> to get people to use them only for long tables and even then the sequence
> (head, footer, bodies) was not satisfactory. It seems that JAWS has fixed
> this issue since version 11. Tables marked up with THEAD, TFOOT and TBODY
> can be read in correct order in JAWS when using table navigation key
> strokes.



Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Ramón Corominas
Richard said:

> If the <tfoot> contains global information then it is in the wrong
> place. global information should be presented before the data (perhaps
> in the summary :)

According to the HTML spec:

"The table head and table foot should contain information about the
table's columns. The table body should contain rows of table data."

IMO, the purpose of the <tfoot> element is to be able to include
information such as footnotes (the typical asterisks describing
exceptions, clarifications, references, etc.), which may affect more
than one data cell, but not all of them. This information is "global" in
the sense that it affects to any data cell that contains the asterisk,
but it is not "global" to all the cells in the data table. Thus, this
information may/should be available before the user encounters the data
cell that needs clarification. This information must be also printed in
every page in a multi-page printed table.

> Let's admit it, <tbody> etc. should only be used when you are offering
> your visitor a printable option.

Why? If <thead>, <tfoot> and <tbody> were used properly, and if user
agents start to provide support for them, they could be really
interesting for many users. For example, you can use more than one
<tbody> element in the same table. This means that you can use different
styling for different cells without using classes for every <tr>, and
screen reader users could have more options to navigate to certain parts
of the table without going through all the cells.

For example (not perfect, but I think it will explain the idea):

<table>
<caption>2nd. International Congress. Agenda</caption>
<thead>
   <tr>
     <th>Date</th>
     <th>Time</th>
     <th>Talk</th>
     <th>Speaker</th>
   </tr>
</thead>
<tfoot id="tfoot">
<tr>
   <td colspan="4"><!-- I don't like this as "td", but also not as "th",
maybe <tfoot> could include elements different from "tr" -->
   <ul>
     <li>(1) Limited space, please register in advance</li>
     <li>(2) Pending</li>
   </ul>
   </td>
</tr>
</tfoot>
<tbody id="day1" aria-label="Day 1: 25th January">
   <tr>
     <th rowspan="5" scope="row">25th January</th>
     <td>9:00</td>
     <td>Mr. John Smith <a href="#tfoot">(1)</a></td>
     <td>HTML5</td>
   </tr>
   <tr>
     ...
   </tr>
</tbody>
<tbody id="day2" aria-label="Day 2: 26th January">
   ...
</tbody>
</table>

In this example, if user agents provide access to the different parts of
the table, a screen reader user could go directly to day 2, day 3, etc.,
without having to read day 1. The user could also go directly to the
tfoot information to read the clarifications and, more importantly, to
go back to the point she was reading before junping to the <tfoot>.

Of course, this is not something that can be done now, because user
agents don't provide this kind of navigation, but it is something that
can be done to improve the user experience.

Regards,
Ramón.

Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Karl Groves-5
In reply to this post by Userite
On Thu, Jan 24, 2013 at 7:04 PM, Userite <[hidden email]> wrote:

>
> Let's admit it, <tbody> etc. should only be used when you are offering your
> visitor a printable option.
>

I think it bears mentioning that the TBODY element i going to be in
the table whether you put it there or not, as all browsers put it in
the DOM when they render the page.

Karl

Reply | Threaded
Open this post in threaded view
|

Re: TBODY

Pierre Dubois-2
Userite wrote Jan 25
>
> If the <tfoot> contains global information then it is in the wrong place. global information should be presented before the data (perhaps in the summary :)

Here some references to support it

http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#footnotes
http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#table-descriptions-techniques



Footnotes vs column summary (tfoot element)

As defined in the HTML5 specification, the tfoot element represents
the block of rows that consist of the column summaries (footers).
(http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-tfoot-element)

The question is: What exactly is a "column summary"?

Table footnotes (global information about the tabular data) is
definitely not "columns summary". Column summary is often know as the
"total" row or row group at the bottom the the table. So When you read
that row or row group you get a summary of the data per columns.

When a table have global information defined inside the tfoot, the
elements (tr, th, td) inside the tfoot is used for layout. That create
a hybrid data table combined with a layout table. That make it fail
the WCAG Level A. See F46: Failure of Success Criterion 1.3.1 due to
using th elements, caption elements, or non-empty summary attributes
in layout tables (http://www.w3.org/TR/WCAG-TECHS/F46.html).



Multiple tbody element and WCAG

Having multiple tbody have a role in the accessibility when you use
the technique H63: Using the scope attribute to associate header cells
and data cells in data tables
(http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H63).

When you have an header cell (th) that is marked with the scope
"rowgroup" it needs to be anchored in a row group (tbody). See the
HTML5 specification:
http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#attr-th-scope-rowgroup



What could be the full potential of using multiple tbody and multiple
colgroup by excluding the printing and the zebra stripping use case?

Here's my answer. What is yours?

When the WCAG technique H63 (scope attribute) or H43 (id/headers
attribute) is use to make a complex HTML table accessible, that can
create two different perception of the same table, one for the screen
readers and one for the visual user. My research to combine both
perception resulted in the elaboration of 12 techniques (WCAG 2.0
style). Also that research resulted to: a proposal to add a new
attribute (hassum) at the table element, a proposal to remove the
scope and headers attribute and a proposal to change the current table
algorithm. (https://github.com/duboisp/Table-Usability-Concept)

Here a few techniques (WCAG 2.0 style), that I drafted, where a visual
user and a screen reader can benefit equally of an HTML table that
have multiple tbody element and multiple colgroup element. (All the
technique and related documentation -
http://wet-boew.github.com/wet-boew/demos/tableparser/index-eng.html)
* Defining a Data Row Group -
http://wet-boew.github.com/wet-boew/demos/tableparser/rowgrouping-techniques.html
* Summaries a Data Row Group -
http://wet-boew.github.com/wet-boew/demos/tableparser/summariesrowgroup-techniques.html
* Summaries a Data Column Group -
http://wet-boew.github.com/wet-boew/demos/tableparser/colgroupsummary-techniques.html




Cheers

Pierre