- From: Bill Mason <w3c@accessibleinter.net>
- Date: Mon, 25 Jun 2007 01:24:13 -0700
- To: public-html@w3.org
Gregory J. Rosmaita wrote: > aloha, bill! > > isn't the point of the exercise to improve the quality of the product? > surely that is what the HTML WG is chartered to do, develop > > quote (source: http://www.w3.org/2007/03/HTML-WG-charter) > * A language evolved from HTML4 for describing the semantics of > documents and applications on the World Wide Web. This will be > a complete specification, not a delta specification. > unquote > > what then, constructive, do you have to add to the discussion? If you find my messages non-constructive, feel free to ignore them. > i've already quote justified unquote my proposal and the reasons > behind it, but here we go again: > > if i peruse an online circular, and it is comprised completely of > tables, do i not need to know that the first table contains > a recurring menu of choices; the second, a means of searching > the site; the table where the specials are visually laid out (often > without ALT or explicit orientational text) and i ESPECIALLY > need summaries on the tables that contain the forms through > which i transact with a business (although i'd prefer fieldsets, > legends, and labels - or just plain wholesale adoption of XForms); > which table contains the confirmation information before i > finalize the order slash transaction, etc. The odds that authors of such pages are going to update the code to HTML 5 and put in such summaries are minimal, any more than those authors dropped their layout tables for CSS when it became available. HTML 5 is not going to fix your problems with legacy pages using tables for layout. > go to your online banking interface -- chances are, everything > is stuck in tables that nest like rabbits, so i fail to understand > why it would be a bad thing if summary was a required attribute > of TABLE, whether or not that TABLE is used to display data set > relationships, or being mis-used in an attempt to control the > layout of the page... My online bank home page has exactly one table, to lay out 3 images horizontally -- and that probably could have been done via CSS float or positioning. Requiring summary is undesirable because: * Layout tables are slated to be nonconforming anyway, and mandating summary on all data tables is not necessarily desirable (see below) * I would doubt there will be a great number of authors of a knowledge level to both know of and want to create conforming HTML 5 code and still construct a page of not just a layout table, but multiple nested layout tables. > if you are using TABLE as a grouping mechanism, then why not > require that a summary of its use and intention be made available > to those who cannot perceive the grouping? that is why the > value summary="" (summary equals-sign quote quote - the > equivalent of a null alt value) should cause a validator to return > an error when the page is analyzed... Even if we pretend that all HTML 5 pages will never have a layout table, it is entirely possible (as was recently suggested) [1] to provide summary information outside the summary attribute, thus making having one a requirement a problem. > layout tables aren't simply quote graphical unquote or quote > stylistic unquote -- they have been constructed precisely for > the purpose of grouping information into discrete visual portals > in order to maximize screen real estate (er, the visual canvas) > and to communicate visually that this thing belongs to this set > of things, while these things belong to another set of things > entirely... Given that the intent of the specification is to make layout tables nonconforming, if people use them anyway I doubt their conformance to the use of summary will be the uppermost thing on their mind. > given that, why would anyone object to making summary > a required attribute of TABLE? See above. Suffice to say, regarding the rest, I don't think you've made a valid justification for requiring summary. As I noted elsewhere [2], I believe summary belongs in the specification, but I don't find your rationale to be an argument for that belief. > besides, bill -- accessibility is in the eye, ear, fingertip, or > some combination thereof of the beholder... you asked for a > justification, when there has been a need identified, and a > proposal has been made, and a pre-existing solution happens to > provide a means of satisfying that need TODAY, not when HTMLx is > finally offered to the public... besides, verbosity is best left > to the end-user to decide, not for a webmaster to make an assumption > (such as this is purely decorative, or this doesn't qualify as content > -- it's art); that being said, i'd rather hear the contents of a null > ALT text than innumerable string such as: quote spacer unquote; > quote clear pixel unquote; quote indecipherable filename unquote; > and so on, but if you are using a TABLE as a layout table, you > are doing so to convey something to the user, even if you don't > realize it -- that here, and here, and here and here you can > find related information... who knows -- perhaps the onerus > burden of providing a summary will be a disincentive for > page authors to misue table to achieve layout effects... > > i have had countless persons, who, after asking me to spec a machine > for a blind employee that would allow the employee access to the > office's new network, express surprise when i recommend (if the user > is braille literate) that they provide both a screen reader and a > refreshable braille display... can't they do with one or the other, > they ask, to which i reply, you wouldn't force a sighted employee to > choose exclusively between the use of a screen or the use of a > printer, would you? > > the bottom line is: make the information available and allow the end > user to set the verbosity slash level of granularization they want -- > and remember, in different circumstances, one's need for and/or > tolerance of orientational and contextual information varies greatly, > from document to document, user to user... > > gregory. -- Bill Mason Accessible Internet w3c@accessibleinter.net http://accessibleinter.net/ [1] http://www.wcagsamurai.org/errata/intro.html [2] http://lists.w3.org/Archives/Public/public-html/2007Jun/0684.html
Received on Monday, 25 June 2007 08:24:27 UTC