E-mail List Archives
Thread: Examples of and justification for id/headers in complextables
Number of posts in this thread: 13 (In chronological order)
From: Laura Carlson
Date: Tue, May 15 2007 11:50AM
Subject: Examples of and justification for id/headers in complextables
No previous message | Next message →
The HTML 5 working group is questioning the usefulness of marking up
id/headers in complex tables. In fact have those two attributes are not
currently in the HTML 5 specification [1].
I have cited test results, examples, and references [2] of their use.
The editor of the spec would like examples of actual real-world use "in
the wild". [3]
Also they specifically want evidence provided for each attribute which
answer the following [4]:
> * What are the use cases?
> * What problems it solves and how?
> * Who benefits and how?
> * The incentive that authors will have to actually use it.
> * How it could be implemented.
> * The incentive that UA vendors have to implement it.
Any examples or input would be appreciated.
Thanks,
Laura
[1] http://lists.w3.org/Archives/Public/public-html/2007May/0012.html
[2] http://lists.w3.org/Archives/Public/www-html/2007May/0467.html
[3] http://lists.w3.org/Archives/Public/www-html/2007May/0471.html
[4] http://lists.w3.org/Archives/Public/www-html/2007May/0419.html
From: Robinson, Norman B - Washington, DC
Date: Wed, May 16 2007 11:30AM
Subject: Re: Examples of and justification for id/headers incomplextables
← Previous message | Next message →
Laura,
This technique is outlined as a part of our official policy,
used in statements of work, vendor requirements, both internally and
externally. The USPS AS-508-A Section 508 Technical Guidelines:
(specifically the section on tables)
http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr39. Due to
our concern on this issue, we have it in our policy and don't rely on
the W3C. We've specifically gone so far as to state when we refer to the
W3C topics, users "must defer to the Postal Service guidelines."
I hope that is of use in the discussion. Please message me
directly with any specific questions.
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
From: Spellman, Jeanne
Date: Thu, May 17 2007 11:00AM
Subject: Re: Examples of and justification for id/headers incomplex tables
← Previous message | Next message →
Fidelity Investments depends heavily on complex tables for displaying
product and customer account information. Portions of the web site have
been using complex table markup for years to improve accessibility.
Unfortunately, most of the examples I am familiar with are behind the
customer password. For those with personal Fidelity accounts, look in
the Accounts and Trade section.
> 1. What are the use cases?
> 2. What problems it solves and how?
> 3. Who benefits and how?
> 4. The incentive that authors will have to actually use it.
> 5. How it could be implemented.
> 6. The incentive that UA vendors have to implement it.
(1)Id/headers are used in dynamic tables for grouping rows and/or
columns (e.g. Large Cap Funds, International Funds, etc).
Id/headers are used on dynamic tables with irregular shapes, where the
table provides a "total" row in a larger, more prominent font that will
not fit in the regular cell. Cells are then merged in that row, breaking
the standard connection to the TH for that column.
(2)Id/headers in a dynamic table are easier to code and have less
cross-browser CSS implementation problems than other techniques for row
and column grouping.
(3)It benefits screen reader users by providing header information for
individual cells. I would also find this feature very useful if extended
to my cellphone and PDA browsers when I am viewing a large table with
data streamed vertically in a small screen, to have the ability to see
the scrolled-off-the-screen headers with the visible data.
(4)Fidelity has an accessibility group that trains developers and
designers in techniques for providing accessible financial information.
(5)The implementation should stay the same as HTML 4. UA vendors
shouldn't take it out of their products.
(6)Large financial institutions need to present complex financial data
in tables. Large financial institutions that do business with the U.S.
Federal government are required to provide Section 508 accessibility
compliance. Many large financial institutions like Fidelity Investments
and Bank of America have a commitment to providing accessibility to
customers.
Additional Use Cases for Complex Table Markup (just in case these are in
danger, as well)
Axis is used when presenting a dynamic list of transactions where a
status (e.g. "today's transaction") is presented with a tinted
background for sighted users, and the axis attribute is used to provide
equivalence for screen reader users.
Table summaries are heavily used for data tables (sometimes
inappropriately in layout tables, but the developers are trying to be
helpful).
Table scope attributes are used routinely on data tables.
An additional use case for the scope attribute is on complex tables
where the first cell in a row is the mutual fund symbol and the mutual
fund name is the second cell. Scope is used in the second cell to read
out the fund name to screen readers querying the headers for the cell
instead of the symbol (which is usually unintelligible in JAWS).
Jeanne Spellman
From: Laura Carlson
Date: Mon, May 21 2007 6:50AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
A sincere thank you to everyone who supplied examples and information
to my inquiry.
Here is the resulting post that I sent the HTML 5 Working Group:
http://lists.w3.org/Archives/Public/public-html/2007May/1032.html
Reply from the editor:
http://lists.w3.org/Archives/Public/public-html/2007May/1036.html
My follow up post:
http://lists.w3.org/Archives/Public/public-html/2007May/1069.html
Jeanne, the editor particularly asked if it would be possible to get
actual Fidelity examples (not samples) that demonstrate id/headers use
in the real world.
If anyone has further production examples or justification please send
them to me and I will forward to the working group.
Anyone wanting direct input into HTML5 can join the group. For further
info visit:
http://ln.hixie.ch/?start=1173385976&;count=1
Best Regards,
Laura
From: Keith Parks
Date: Tue, May 22 2007 11:30AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
On May 21, 2007, at 5:41 AM, Laura Carlson wrote:
> If anyone has further production examples or justification please send
> them to me and I will forward to the working group.
If you're still looking for tables that need this, I believe I'm
working on one now.
The site is still under construction, but the table is at the bottom
of this page...
<http://www.sa.sdsu.edu/annualreport/success.html>;
Most of the data cells require three headers to properly identify the
info. For instance, a few rows down, the "2.64" value needs to be
tied to "Summer Bridge Students", "Mean GPA" *and* "Biology 100". So
I set it up (correctly, I hope) using the ID/headers scheme.
I suppose one could argue (as the person who responded to your
Working Group posts might) that SCOPE alone could work if the info
were broken in to separate table. But the single table seems pretty
clear to me, visually, and I hate to make it *less* clear and compact
just to make it accessible, if there is a mark-up scheme that ties
all the headers to their respective data.
HTH,
Keith
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.keithparks.com
http://www.sa.sdsu.edu/communications
----------------------------------------------------------
(Objects on your screen may be closer than they appear)
From: tedd
Date: Wed, May 23 2007 9:10AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
>Most of the data cells require three headers to properly identify the
>info. For instance, a few rows down, the "2.64" value needs to be
>tied to "Summer Bridge Students", "Mean GPA" *and* "Biology 100". So
>I set it up (correctly, I hope) using the ID/headers scheme.
>
>I suppose one could argue (as the person who responded to your
>Working Group posts might) that SCOPE alone could work if the info
>were broken in to separate table. But the single table seems pretty
>clear to me, visually, and I hate to make it *less* clear and compact
>just to make it accessible, if there is a mark-up scheme that ties
>all the headers to their respective data.
I don't know for certain, but this seems to make sense:
http://www.access-board.gov/sec508/guide/1194.22.htm#(o)
However, please forgive me if I am mistaken, but I think that Laura
is supporting using headers and id's instead of scope.
In the examples given in the above link, it appears that scope may be
easier to implement and to be used for accessibility. But, I am still
in the dark about full extent of this.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Laura Carlson
Date: Thu, May 24 2007 7:00AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
> However, please forgive me if I am mistaken, but I think that Laura
> is supporting using headers and id's instead of scope.
No, not instead of scope, just in addition to scope.
Headers"" currently is not in the HTML 5 spec. They are keeping the
scope="" attribute because they consider it adequate to describe all
data tables. The relevant part of the spec at:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tabular.html#header-and-data-cell-semantics>;
(Side note: the HTML 5 spec keeps font, i, and b)
> In the examples given in the above link, it appears that scope may be
> easier to implement and to be used for accessibility.
Because scope is simpler, shorter and less error-prone than id/headers,
it would great if worked for complex tables and had better support. It
would be great also if all complex tables could be transformed into
simple tables. I agree, they are a big pain to mark up.
Laura
From: Moore, Michael
Date: Thu, May 24 2007 8:10AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
Good morning,
I have been lurking on this thread for a while, and I think its time to
speak out.
<rant>
Although many, if not most, complex tables can technically be defined
using the scope attribute alone, or together with colgroup screen reader
performance with these tables is spotty at best. When more than a
single row or column header must be assigned to a single data cell the
only reliable method is to assign ids to the header cells and then point
to them using the headers attribute within the data cells. This is
particularly true for older versions of assistive technologies of which
there are many "in the wild" due to the cost of the assistive technology
and the fact that the average income and unemployment rate for people
who require these assistive technologies is well below that of the
non-disabled community.
There are added advantages to the headers attribute. First, page
authors can specify the reading order of the headers within the data
cell to make the data more understandable. This is because when the
headers attribute is used the assistive technology will read the headers
in the order that they are listed within the attribute. The second
advantage is that if headers, scope, and caption were widely used "in
the wild" then it would be possible to write data mining bots and
crawlers that could search tabular data on the web and present it
interesting and creative ways.
The fact that a useful attribute is currently not commonly used "in the
wild" is no reason to drop it from the HTML 5 specification. Given the
number of tables without scope defined, the number of forms without
labels, and a host of other major and minor structural and accessibility
related errors that exist "in the wild", choosing which elements and
attributes to keep based upon frequency of proper use is a poor strategy
to employ when developing a new html specification.
The working group should concentrate on eliminating elements and
attributes that allow developers to define presentation and behavior
within the html as in xhtml. Elements and attributes that contribute to
more precisely defining the information presented within a web page
should retained, and possibly expanded. How about conversation and
speaker elements to mark up transcripts.
</rant>
Mike Moore
Accessibility Specialist
Department of Assistive and Rehabilitative Services (DARS)
From: Laura Carlson
Date: Thu, May 24 2007 9:30AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
> I have been lurking on this thread for a while, and I think its
> time to speak out.
Thank you very much Mike. Well said.
Best Regards,
Laura
From: Spellman, Jeanne
Date: Thu, May 24 2007 12:30PM
Subject: Re: Examples of and justification for id/headers incomplex tables
← Previous message | Next message →
> Because scope is simpler, shorter and less error-prone than
id/headers,
> it would great if worked for complex tables and had better support.
It
> would be great also if all complex tables could be transformed into
> simple tables. I agree, they are a big pain to mark up.
Scope only seems simple in theory. When working with complex, dynamic
tables, id/header is easier, as they are simple attributes that are
easily expressed as variables. Setting up colgroups and the varieties of
row group elements are problematic in CSS styling and cross-browser
implementation flaws. For financial institutions that live and breathe
complex data tables, the id/header attribute is a simple solution that
is reliable cross-browser.
Scope does not address the problem of tables with merged cells. Only
id/header allows the developer to precisely assign the header for a
merged cell cross-browser.
Laura, I haven't forgotten about getting you specific examples, but I'm
seeking permission to post code examples.
From: Andrew Kirkpatrick
Date: Thu, May 24 2007 2:12PM
Subject: Re: Examples of and justification for id/headers incomplextables
← Previous message | Next message →
> Scope only seems simple in theory. When working with
> complex, dynamic tables, id/header is easier, as they are
> simple attributes that are easily expressed as variables.
> Setting up colgroups and the varieties of row group elements
> are problematic in CSS styling and cross-browser
> implementation flaws. For financial institutions that live
> and breathe complex data tables, the id/header attribute is a
> simple solution that is reliable cross-browser.
I'm not sure what the CSS styling issue you describe has to do with the
use or non-use of scope. Can you explain more? Even if you use scope
you still might need to use id for assigning styles.
> Scope does not address the problem of tables with merged
> cells. Only id/header allows the developer to precisely
> assign the header for a merged cell cross-browser.
That depends on where the heading or the content cells are merged. If a
spanned row or column heading cell has scope properly assigned it is
unambiguous which data cells are associated with it. If the data cells
are merged across heading cell boundaries then that would require
id/headers.
I see tables where my initial reaction is "that should be more than one
table" - these tables often need id/headers for correct and unambiguous
associations between data and heading cells. I don't see any good
reason why keeping the "headers" attribute should be a problem, but I
also agree that scope is the easiest way to handle this association for
most tables.
AWK
From: Laura Carlson
Date: Fri, May 25 2007 11:10AM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | Next message →
Michael Moore wrote:
> The working group should concentrate on eliminating elements and
> attributes that allow developers to define presentation and behavior
> within the html as in xhtml. Elements and attributes that contribute
> to more precisely defining the information presented within a web page
> should retained, and possibly expanded.
Agreed.
As I mentioned before, anyone interested in the future of HTML please
consider joining the HTML 5 working group. Members get a vote on
proposals and issues. Accessibility and standards advocates currently
seem to be a minority.
Ian Hickson posted:
> Anyone can actually join the W3C HTML Working Group. I encourage
> everyone interested in the development of HTML5 to take part. If you
> don't take part, and the language develops in a way you don't like,
> then you have but yourself to blame.
>
> Taking part in the group is not a big commitment. You can spend as
> much or as little time contributing; you don't need to read every
> e-mail on subjects you don't care about, you don't need to call in or
> attend face-to-face meetings. In fact, the W3C has stated in the
> group's charter that no binding decisions will be made at meetings;
> you are guaranteed equal say whether you are present or not.
For further info and instructions for joining visit:
http://ln.hixie.ch/?start=1173385976&;count=1
Best Regards,
Laura
From: Christophe Strobbe
Date: Thu, May 31 2007 2:10PM
Subject: Re: Examples of and justification for id/headers in complex tables
← Previous message | No next message
Hi Laura,
At 14:41 21/05/2007, you wrote:
>A sincere thank you to everyone who supplied examples and information
>to my inquiry.
>(...)
>If anyone has further production examples or justification please send
>them to me and I will forward to the working group.
Here are two more examples of tables with id and headers:
*
<http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.osc/osccaccs.htm>;
(in a frameset);
* <http://www.webaim.org/techniques/captions/mediaplayers/>;.
Best regards,
Christophe
--
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group
on Document Architectures
Kasteelpark Arenberg 10 bus 2442 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm