E-mail List Archives
Thread: Table headers not behaving
Number of posts in this thread: 10 (In chronological order)
From: Ian.Lloyd
Date: Tue, Sep 10 2002 6:24AM
Subject: Table headers not behaving
No previous message | Next message →
-----BEGIN PGP SIGNED MESSAGE-----
********************************************************************
The contents of this email are intended exclusively for the
addressee. If you are not the addressee you must not read
use or disclose the email contents ; you should notify us
immediately [ by clicking "Reply" ] and delete this email.
Nationwide monitors e-mails to ensure its systems operate
effectively and to minimise the risk of viruses. Whilst it has
taken reasonable steps to scan this email, it does not
accept liability for any virus that may be contained in it.
********************************************************************
I've been advising colleagues to use headers and ids in tables for more
complicated tables where scope doesn't cut it.
I've just come back from holiday to find out that some relatively simple
tables (with just one colspan and rowspan) are not behaving when using the
CTRL + ALT to navigate around (I would expect it to announce the headers,
but it is doing so inconsistently). And because I've just returned from
holiday, brain has yet to kick in to action, so all help greatly appreciated
...
FYI, I am using IE5 and Connect Outloud.
Here is a snippet of an example table - can anyone tell me if this is
incorrect coding? Or is it the screen readers themselves that are not yet up
to the job of referencing multiple headers?
Many thanks, here's the table code:
<table cellspacing="2" cellpadding="3" border="0" width="95%" summary="Table
detailing the Classic Card Rates">
<thead>
<tr>
<th rowspan="2"> </th>
<th colspan="2" id="product_title"><a href="#top"><img
src="../_credit-card_images/arrow-up.gif" alt="To top button" border="0"
align="right"></a>Classic Card</th>
</tr>
<tr>
<th id="annual" headers="product_title">Annual Rate</th>
<th id="monthly" headers="product_title">Monthly Rate</th
</tr>
</thead>
<tbody>
<tr>
<td class="data" scope="row">Rate for first 6 months</td>
<td class="NBSdata" headers="product_title annual">0% p.a.</td>
<td class="NBSdata" headers="product_title monthly">0% </td>
</tr>
<tr>
<td class="data" scope="row">Ongoing Rate</td>
<td class="NBSdata" headers="product_title annual">13.9% p.a.</td>
<td class="NBSdata" headers="product_title monthly">1.09%</td>
</tr>
<tr>
<td class="data" scope="row">APR for Purchases & Balance Transfers</td>
<td class="NBSdata" headers="product_title annual">11.5% APR</td>
<td class="NBSdata" headers="product_title monthly">N/A</td>
</tr>
</tbody>
</table>
Ian Lloyd, Electronic Channels
Nationwide Building Society
e-mail: = EMAIL ADDRESS REMOVED =
tel: 01793-655260
fax: 01793-656368
-
From: Paul Bohman
Date: Tue, Sep 10 2002 9:23AM
Subject: RE: Table headers not behaving
← Previous message | Next message →
You've run across a bug in the JAWS algorithms, which is documented in
the WebAIM tables tutorial at http://www.webaim.org/howto/tables3
(towards the bottom of the page). Connect Outloud is essentially a
scaled down version of JAWS, with the same bugs.
JAWS simply cannot handle any tables with any spanned rows or columns
correctly. It's sad, but true. Other screen readers do not have the same
problem. This is a bug specific to JAWS. IBM Home Page Reader and Window
Eyes, for example, would read this table correctly.
The only solution, unfortunately, is to change the structure of the
table. In many cases this is a difficult proposition, and it may not be
possible to restructure all such tables. In some cases, you may have to
provide an additional alternative version of the data outside of a
table, like this:
<begin example>
Rate information for "Classic Card:"
Rate for first six months: annual - 0%, monthly - 0%.
Ongoing rate: annual 13.9% - p.a., monthly - 1.09%.
APR for purchases and balance transfers: annual - 11.5% APR, monthly -
not applicable.
<end example>
I know that most developers don't like it when I tell them about this
bug in JAWS. I don't like it either, but we have to remember that JAWS
is just software, and like all software, it has its glitches.
If you're now getting worried about other potential bugs in screen
readers, don't worry too much. There are little things here and there,
but not like this one. Most of the problems have to do with lack of
support for certain accessibility features, rather than actual bugs. But
the table rowspan/columnspan issue is an actual bug. JAWS reads the
*wrong* headers when you span rows or columns.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu
From: John Foliot - bytown internet
Date: Tue, Sep 10 2002 9:52AM
Subject: RE: Table headers not behaving
← Previous message | Next message →
Which poses the question: do developers code to standards and leave the
implementation to the "interpreters (user agents)" or do we code to software
bugs such as the one documented below? As Paul notes, 2 major screen
reading technologies get it right, one gets it wrong.
Developing complex tables is work enough to ensure accessibility, do we need
to also work around software bugs? Everybody has their role to play,
including Freedom Scientific. While not everybody agreed with the WaSP
stance (http://www.webstandards.org/) when they first emerged, two years
later we have (generally) compliant browsers. So who was right?
I do not pose this question to antagonize, but by the same token I
(personally) feel that it needs to be discussed.
(Please - no flames!)
JF
>
From: Ineke van der Maat
Date: Tue, Sep 10 2002 10:09AM
Subject: Re: Table headers not behaving
← Previous message | Next message →
Hello John,
You wrote:
>Which poses the question: do developers code to standards and leave the
implementation to the "interpreters (user agents)" or do we code to
software bugs such as the one documented below? As Paul notes, 2 major
screen
> reading technologies get it right, one gets it wrong<
Perhaps this article gives you an answer at your question. It was sent
on the new w3c-public-evangelist-mailing list. The title is: "99,9 % of
websites are obsolete".
http://www.digital-web.com/features/feature_2002-09.shtml
greetings
Ineke van der Maat
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Mark Rew
Date: Tue, Sep 10 2002 10:34AM
Subject: Re: Table headers not behaving
← Previous message | Next message →
When we develop we should develop to the standards such as Section 508, html
4.01 etc. This way we will work with most of the packages that have agreed to
use these stanards. Then we try to encourage software vendors to comply with
the same standards. One way is the US Government mandating compliance with
Section 508 as a requirement of a purchase order.
Mark Rew
----- Original Message -----
From: "John Foliot - bytown internet" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, September 10, 2002 12:43 PM
Subject: RE: Table headers not behaving
> Which poses the question: do developers code to standards and leave the
> implementation to the "interpreters (user agents)" or do we code to software
> bugs such as the one documented below? As Paul notes, 2 major screen
> reading technologies get it right, one gets it wrong.
>
> Developing complex tables is work enough to ensure accessibility, do we need
> to also work around software bugs? Everybody has their role to play,
> including Freedom Scientific. While not everybody agreed with the WaSP
> stance (http://www.webstandards.org/) when they first emerged, two years
> later we have (generally) compliant browsers. So who was right?
>
> I do not pose this question to antagonize, but by the same token I
> (personally) feel that it needs to be discussed.
>
> (Please - no flames!)
>
> JF
>
> >
From: ::kevination::
Date: Tue, Sep 10 2002 11:00AM
Subject: Re: Table headers not behaving
← Previous message | Next message →
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Foliot - bytown internet wrote:
>
> Developing complex tables is work enough to ensure accessibility, do we need
> to also work around software bugs? Everybody has their role to play,
> including Freedom Scientific. While not everybody agreed with the WaSP
> stance (http://www.webstandards.org/) when they first emerged, two years
> later we have (generally) compliant browsers. So who was right?
>
Pro: No one get's left behind
By recognizing and accommodating the failings of various User
Agents(UA) we allow more people to access in the short-term. After-all
it's pretty damn hard to blame someone you don't even know for a buying
a non-standards compliant or buggy browser.
Con: Hacks are time-bombs
By coding hacks into our code we risk that some updated UA is going to
interpret the hack incorrectly. Essentially we are leaving a time-bomb
in the code and daring UA developers to trigger it. In the long-term
this may reduce the number of people able to access your information.
The answer for me is to never use hacks.
I don't always succeed. If I do end up using a hack I try to educate the
client on the consequences. I may also apologize for not recognizing the
problem before I hit development. I also include a clear explanation of
the hack in the code. My hope is that when the hack does explode,
another developer will understand my comment and be able to develop a
new fix quickly.
The real answer may lie in linking Accessibility compliance with
software quality liability legislation. Such a solution may also cause
more problems than it would solve.
- --
- ---
kevin D. white
email, = EMAIL ADDRESS REMOVED =
im, simplecypher
- ---
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.90-nr1 (Windows 2000)
iQIVAwUBPX4xXe4zpFgPJZelAQJk3hAAkwO2CUvqJMRBp3p4nXqJlU7cfuJMCPsw
5Rw2uMTYQdTzqqI45Rc+Ywe0dUDwuY8pNstd4Wd0d2Vpn3e0XlTs6aOMOjYPFh00
6ROIEsmGq0YNWABtXZKq0ELfM3JT2ynkwJoC5tNjUqpxbfP/+W3hBhHzJJX2q2uS
y+44Oi6VRTA+mLcUIFvKVmtCxlJibf/QdSSDuV9DPyef6SHt4VoWY9smo9/2Blg9
y6B0SPUOTDnklHs3/H3XwH5ZTNl2lUACQgq1zVt9osy3rNvoK+Wlm5YWekhNmrdB
efBcN2Vjx+W+SDFFn9EnnVYD+sw46AbxYBPRcbfhuPwzRW8chzfd/OXOs1p/xztX
HsBN0n+tSghy7LIUJ8QorrkweAUw6vT0fUgaJdCv0unQ4OZAKOxY7/8S9ae0D3Dq
X8Y4rRGrkrnLf0ruCr0F//FE7I9XpJg5nw1suWf61RPdUj7qw9Uo+MBGjKcKR28E
e3nLHc/WIlBPFavTIFyx5Djs2ZqqcgPeJTxX635Lbr6rc0R9CmSZg2wK8+qL4ZOg
Px3mibxPSExGfZY7ZrMG7mTzrMKlC2/Da+byEbI2u6KlmlQMXkhGl0p8NHzDgpZK
xFFxc8jzt3babVc6G/3dk3y5O5oAj5BwX7pts7NMvV3WJEi3YkRnoVlpY54tPdOw
gxXQdi+LURA=T4kT
-----END PGP SIGNATURE-----
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Holly Marie
Date: Tue, Sep 10 2002 11:10AM
Subject: Re: Table headers not behaving
← Previous message | Next message →
From: "John Foliot - bytown internet"
| Which poses the question: do developers code to standards and leave
the
| implementation to the "interpreters (user agents)" or do we code to
software
| bugs such as the one documented below? As Paul notes, 2 major screen
| reading technologies get it right, one gets it wrong.
I say we code the tables for data when we need to do so. According to
the guidelines.
User agents have known about these items since there were tables back in
HTML3?
Two others get it right, yet, the leading and most widely used does not?
[not sure about the stats on that one?]
| Developing complex tables is work enough to ensure accessibility, do
we need
| to also work around software bugs? Everybody has their role to play,
| including Freedom Scientific.
I agree.
| While not everybody agreed with the WaSP
| stance (http://www.webstandards.org/) when they first emerged, two
years
| later we have (generally) compliant browsers. So who was right?
It is hard to say where to agree or disagree with WaSP, as it has made
some transformations of its own. They took a hard line for a while, yet
also understood the reality of that hard line. Even today people are
balking at using xhtml and css2, because clients want to understand why
their pages cannot look the same across every view. The targets at the
browsers a few years back, was good, and came out of this need to get
some sort of compliance, because it was very difficult to mark up a page
that could be presentable in the two major browsers without writing a
bunch of hacks and work arounds.[at times, it still can be.]
Tools, people, and also user agents[or devices], all need to address
these issues. And maybe IBM and others who comply ought to capitalize on
the fact they can offer the users a better working device at the basic
level, govenmental, public, and educational groups should toss those
contracts to those that are complying, and maybe hitting them where it
hurts most is the way to go... Sales. [then I bet some action gets done]
The unfortunate flip side to all of this is the reality that people who
have already invested in these expensive and broken tools, cannot afford
to make the change?
| I do not pose this question to antagonize, but by the same token I
| (personally) feel that it needs to be discussed.
Unfortunately, complicated data in tables works well and best for the
majority of the visiting audience when placed in such a layout. Data
will not work as well or may not be as usable in text or linear format.
holly
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Tue, Sep 10 2002 3:25PM
Subject: RE: Table headers not behaving
← Previous message | Next message →
>>Holly Marie wrote:
Unfortunately, complicated data in tables works well and best for the
majority of the visiting audience when placed in such a layout. Data
will not work as well or may not be as usable in text or linear format.
My response:
You're right. Tables usually are the best method to display data. Where
data need to be shown, put them in a table and mark it up correctly.
However, it's good to be aware of the JAWS bug with spanned rows/columns
so that those who want to ensure that tables created that way can be
made accessible to JAWS users by creating a linearized version. The
linearized version will be unfriendly to most people, and is offered as
an alternative, not a replacement for the table. Similarly, the table
version will be unfriendly to JAWS users due to the JAWS bug.
As a general rule, though, we should code to the standards. Doing so
will ensure that the content is accessible to the greatest number of
people, software, and devices. The exceptions to this rule are few. The
spanned rows and columns is an exception. And yes, it is Freedom
Scientific's responsibility to fix it.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Michael R. Burks
Date: Tue, Sep 10 2002 5:25PM
Subject: Sites for Children with Special Needs
← Previous message | Next message →
All,
I am looking for web sites devoted to children and teens with special needs,
please reply off list.
Any help is greatly appreciated.
Sincerely,
Mike Burks
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Carol Foster
Date: Wed, Sep 11 2002 7:08AM
Subject: Re: Table headers not behaving
← Previous message | No next message
Apologies if I missed this, but does anyone know if Freedom Scientific is
working on this? Has anyone talked to them about it? I gather that it is
still a problem in the latest versions of JAWS/ConnectOutloud, but I haven't
tried it for myself.
Thanks,
Carol
Paul Bohman wrote:
> . . . .
> However, it's good to be aware of the JAWS bug with spanned rows/columns
> so that those who want to ensure that tables created that way can be
> made accessible to JAWS users by creating a linearized version. The
> linearized version will be unfriendly to most people, and is offered as
> an alternative, not a replacement for the table. Similarly, the table
> version will be unfriendly to JAWS users due to the JAWS bug.
>
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/