- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 17 Feb 1999 20:06:29 -0500 (EST)
- To: David Norris <kg9ae@geocities.com>
- cc: "Leonard R. Kasday" <kasday@ACM.org>, WAI <w3c-wai-ig@w3.org>
I like David's suggestion. Another thought is to play to the strengths. The difficulty with tables is that they can't be read column-wise, but only row-wise, by most systems. So one obvious thing to do is lay them out both ways, if necessary adding the alternate via some kind of link. Another alternative is to generate an alternative which includes the header information in each cell. Both of these are repair strategies, and not really elegant solutions - the elegant solution is to read tables better. They are after all, there because they provide an important way to represent information. If you have the ability to generate your pages from a database then there is a lot you can do. My own experience with this is mostly using Cold Fusion, although I have done some of it in PERL, but it certainly doesn't require very complex magic. It just requires some programming ability, and the afore-mentioned access to some kind of on-the-fly generation which can be configured to produce accesssible HTML in the first place. Some of the obvious choices for such a job are ruled out because thye insit on using javascript or Java controls, or images without appropriate alt-text, or some other basic failure. Charles McCN On Wed, 17 Feb 1999, David Norris wrote: In the case of screen readers. I think it more productive, overall, to design speech enabled user agents that better render HTML. (For example, T.V. Raman's EmacSpeak running a speech friendly browser.) Making tables accessible isn't as much of an issue as making a program that renders tables in an accessible manner. (I think you hinted toward this issue.) The W3C guidelines do a good job to provide for accessible tables, one must follow those guidelines. Of course, following those guidelines doesn't always lead to accessible tables, to the user, because there are few programs that do a good job of rendering them. It seems, to me, that many screen readers spend a large portion of their code working around bad HTML than following the W3C guidelines. Having an alternative format for a spread sheet could be a good thing. Although, many spreadsheets support HTML table imports these days. It may have the side benefit of rendering the table in more accessible software. I would expect the link to be marked as an alternative file type, though. <A href="someAltFile" rel="alternate" type="text/comma-separated-values">someAltFileDescription</A> It might be nice to place this in a LINK tag in the head. <LINK href="someAltFile" rel="alternate" type="text/comma-separated-values" title="someFileTitle"> I know, most browsers don't render this. But, I would still expect one to use it for those that do. Many speech friendly browsers, Lynx for example, support LINK. ,David Norris World Wide Web - http://www.geocities.com/CapeCanaveral/Lab/1652/ Page via mail - 412039@pager.mirabilis.com ICQ Universal Internet Number - 412039 E-Mail - kg9ae@geocities.com --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://purl.oclc.org/net/charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Wednesday, 17 February 1999 20:06:37 UTC