World Wide Web Consortium (W3C) logo Web Accessibility Initiative (WAI) logo

WAI Evaluation & Repair Interest Group (ER-IG) Teleconference

date: Monday, 22 November 1999
chair: Len Kasday
scribe: Gregory J. Rosmaita


  1. ER presentation at XML99
  2. XML topics
  3. ERT Review
  4. Report Tool
  5. Tablin
  6. Announcements
Wendy Chisholm (WC)
Michael Cooper (MC)
Daniel Dardailler (DD)
Len Kasday, (LK
William Loughburough (WL)
Brian Metheny (BM)
Chris Ridpath (CR)
Gregory J. Rosmaita (GJR)



LK: there is an oft-repeated myth that HTML is easy to learn

GJR: that's true if you had experience using HTML 2.0 and 3.2--they were far simpler, and once you mastered one, the next one was less daunting; most students don't have that practical education

LK: concerned about courses that teach HTML and other MLs

GJR: most list a WYSIWYG tool as a requirement; all those types of courses are is an introduction to an interface, not to a markup language; it is a glorified desktop publishing approach, that doesn't teach the student a thing about structuring content and concepts underlying the markup

LK: I don't know of any WYSIWYG tools that offer a prompt to put in ALT text qua ALT text when one is adding an image to a page

GJR: HomeSite does a nice job of integrating prompts for accessibility information--second text entry field in the "Add Image" dialog box--but then, HomeSite is basically an enhanced text-edior

LK: does HomeSite have a WYSIWYG view?

GJR: yes, what they call "Display" mode, but I've never tried it, mostly because of the alert that pops up when you invoke it, warning you that upon entering "Display" mode your HTML may become corrupted, so I've never tried it

MC: FrontPage has a similar problem

LK: FrontPage offers a "low res" option to add to IMG, not part of default dialog for adding images

MC: tried to get ALT text into error messages for Bobby 3.2, which is coming out next month; not as robust as we would like right now because of time constraints, but it will definitely be in 4.0

LK: put in references to particular tools; without putting into ERT would be useful to put into intro that tools should refer to those types of hints?

CR: do we want to refer to existing products like that?

LK: don't have to name them; useful to have specific hints as to how these things work in particular editors

GJR: refer to AU sample implementations and conformance evals in introductory text or as an appendix

LK: drafting an appendix could slow things down, and we're already behind schedule

CR: I like the idea of a good practices appendix, though

Resolved: ERT will have an appendix, but drafting of appendix will not hold up release of ERT

CR: will start; will add items as things come up

LK: be general enough to be non-controversial

AGENDA ITEM 1: ER Presentation at XML99

LK: XML '99 in Philadelphia; number of WAI people talking at this conference, including: Judy Brewer, Jutta, Harvey Bingham, and myself; I will be discussing ER work; this is an XML conference, so would be useful to address XML; would like to reference XML as much as possible; would like to talk about what sort of references we would have in ER context; already been talk on list about schemas and Schematron; I haven't looked at it that closely--has anyone else?

MC: took quick look -- haven't become thoroughly familiar with Schemas, but use XPATH expression to chose elements--XPATH allows you to get specific (images must have alt text)--neither XSL or Schema would allow you to validate what that ALT text is; inherit limitation there; some current work on XML trying to address that by having access to content and not just structure

LK: some things in ERT that are algorithms, some heuristic, some human judgement -- this would be algorithms and some heuristics

MC: not even all algorithms

LK: is the Schematron the most specific work being done on this?

WC: Charles McCathieNevile been talking about creating a Schema for WCAG as he is doing for ATAG--some of that could be reused

MC: would allow us on our end to define specific connections to facilitate connections between what Bobby does and what WCAG does; model I'd like to see extended

// ACTION: LK contact Charles McCathieNevile to discuss this

WC: talked with Rob Swick, the W3C staff contact for RDF, about how to create RDF schema to make table transformation better--what info can authors provide about cells that is more detailed than what is available in HTML

LK: talk on IG list about using RDF to make statements about SVG image; sent off email a few months ago to people in RDF land asking about that, but never heard anything back

GJR: talk with Charles McCathieNevile about that, too--he's very involved with SVG developments and is currently drafting a note on SVG and Accessibility

// ACTION: GJR send LK pointer to CMN's draft Note on accessibility features of SVG

AGENDA ITEM 2: ERT Discussion

CR: working on tables -- started off with something easy, moving on to more difficult parts; moving through them slowly, but surely; haven't updated ERT draft in a week as I was away last week -- will do so today

LK: anything you would like to raise for discussion -- maybe we can get some quick answers

CR: row and column headers for data table only, not layout tables; no perfect way of determining which is which; going to have to prompt user for every single table--"Is this a data table?" if so, need headers; data table with 2 or more layers of headers; guess idea is if have table and first 2 rows are similar data and next 2 rows are different data, supposed to have headers for 2 different types of data?

WC: nested headers--depends on the data--sometimes have data that spans different levels--green eyes versus brown eyes divided into males and females--associating cell with both header levels

CR: would then have row of headers for males and row of headers for females?

WC: right

MC: THEAD in SCOPE -- outermost header cell refers to column group in next row refers to just this column

WC: mark both up as TH--tool could look for 2 rows of TH--number of ways to mark it up--SCOPE would be easiest, but would have to define SCOPE for each header

LK: without any extra HTML4, would be straightforward for UA to pull out applicable headers

WC: a lot of times people guessing about header--2 levels may stop when get to first level, not go back up one

LK: in principle, UA could just go up a column and pick up all headers lined up with that column--whether one column wide or spans multiple columns

WC: this is what Mark Novak's tool does--current MSIE DOM doesn't make it easy to get that info; MN had to do guessing to navigate through elements; don't know all of the issues--you may want to talk to him about it

LK: take table, figure out HTML4 extra attributes from looking at table

WC: just HTML not access scope and headers; developed a few patterns--if have table, assumed layout table--if wanted to try to read it as data table, would go back and reread it and do it in a different way--give you more info on second pass

LK: that would suggest that as repair tech tool could algorithmically figure out what those extra attributes are and either stick-em-in or suggest them

CR: repair tool could figure out what extra headers might be?

LK: not the headers, but the extra HTML attributes that explicitly make connections, so that UA doesn't have to analyze table to figure out what is going on--table with headers mid-way down the table, tool could not figure out, need human algorithm could make guess

WC: this looks like a header--what level? show me the cells you want associated with it; A-Prompt does some nice things--if sees table, will walk you through--this table doesn't have headers, do you want to add them? do you want me to take the first row and convert to headers, or create a new row?

CR: ok--have a better idea about what GL was getting at--will write up something and post to the list today

CR: Technique 3.5.3 Do not use tables for layout unless content makes sense when linearized; if only 2 columns in table, good chance is being used out for layout

WC: graphics in a table is an easy case

LK: selectable region in the middle--for example, a 3 by 3 table: center cell selectable, other cells individual images and not selectable; if that table is a composite image of a person, one cell would be part of ear, one one eye, etc. don't want ALT text for each one, just for one of them, to identify the person and provide a textual equivalent for the selectable item, but would want to leave the ALT text for the rest null

WC: how do you detect that is problem; if detect, suggest use client-side image map; break up into 2 parts: first for author--help fix it, second for user--provide content; right now want to focus on author

LK: if have table with bunch of individual images in it, that ALT text for all non-linked images can have null ALT text

WL: not a good idea--not always the case--very seldom is

LK: if data table, ok to have bunch of images that have bunch of images and all need alt text--if layout table, one gets ALT text and others get null;

WL: isn't it conceptual to have both? a hybrid table--overall a layout table with a genuine data table nested

WC: layout table one in which cells are not associated; data table data in cells reliant on data in other cells

LK: what about WL's scenario

WC: IBM does that with nested tables

LK: is it a GL that where tabular data included in a layout table, need to have it marked up as a nested table

WC: nested tables interesting because they may be a cell within another table--that is a bad authoring practice; we aren't going to be able to fix everything--need to tell author that he needs to redesign this

LK: right now, we are allowing tables for layout; if use tables for layout and want to put data table within layout table, what do we do?

WC: would like to avoid data tables nested within data tables--no way through HTML to fix that to associate cells inside nested tables with headers in outer table

LK: is there a legitimate use for nested tables? if so, perhaps the problem is with the HTML spec

WC: MN's tool will go through and report: found 5 tables on this page 3 of them are nested; the user can navigate each table, but not contiguously--must first enter nested tables individually

LK: sounds fine to me--if have nested tables like that, each should be self-contained and not reference specific columns outside itself

WC: something to be added to WCAG GLs for linearization of table techniques and nested table techniques

// ACTION WC: propose addition to WCAG GLs to address this

CR: is it used for layout? ask them to check? is there any format for visual formatting

MC: is this a layout table or not? if yes, and TD found (used to get bold), then is an error; can automatically determine once ask about layout table

BM: tool should remember how the author defines layout tables, so that it isn't constantly crying wolf

LK: can also perhaps determine if table is being used for markup if there is an H1 inside the table; what other TABLE elements or attributes are mis-used for layout purposes?

MC: is the ALIGN attribute part of this GL? partially structural, partially layout

CR: not sure

LK: all attributes of a cell need to be considered then

MC: don't know if that is structural markup -- not defining table structure itself, is only associated with it

CR: if have P in table cell and align it center, is that ok or should you use the align attribute for the cell?

MC: question is, "are they equivalent?"

LK: need clarification of what is structural markup in tables

BM: what is purpose of GL?

MC: TD could potentially cause a screen reader to trigger tables mode, but attributes shouldn't be triggering that

BM: if just eye-candy, not too significant

MC: I like that approach--5.5 has appearance of being straightforward; even if use table for layout, summary can be "This table is used for layout"

LK: that would be nice place to give a summary of what is where in the reading order; series of links, advertisements, body of text

BM: all tables should have a summary

LK: in addition to a caption?

MC: caption displayed like a TITLE

LK: what if have caption that fully describes table, SUMMARY unnecessary

BM: don't mind being overly redundant

MC: if each thing has a purpose, won't take you too long to repeat it

BM: WCAG checkpoint says should always be a summary

LK: ok -- case closed

MC: like idea of absolutes, because I work on a tool!

LK: are we talking non-null;

MC: somewhat debatable--could say has to have more than 5 or 10 characters

CK: what if SUMMARY is just "Layout"?

BM: that's 6 characters, so is ok!

CR: Techique 5.6: Abbreviations for Header Labels; if have table header that has short word as header, don't need ABBR, but if have verbose header, may need ABBR

LK: what does the GL actually say -- does it use the word abbreviations or ABBR?

MC: note mentions HTML's ABBR attribute

// BM leaves

LK: on face of it, could mean that GLs are wrongly interpreting ABBR?

CR: [reads technique for checkpoint from WCAG]

Provide abbreviations for header labels. [Priority 3]
For example, in HTML, use the "abbr" attribute on the TH element.

LK: does WCAG have it backwards? what is the purpose of this checkpoint, and what do they mean by ABBR?

MC: what exactly is the purpose of ABBR in general?

GJR: I think that they mean that if you are using an abbreviation in a header, enclose it in an ABBR container if you are using HTML; ABBR is important for accessibility because screen readers, for example, usually come with a set of abbreviation expansions that have been pre-defined for the screen reader's dictionary, so that, for example, when the screen reader encounters "Dr." it can expand it to either "Drive" (as in an address) or "Doctor"; if you have an address such as:

Dr. Smith
11 Doe Dr.

a screen reader might read it as "Drive Smith, 11 Doe Drive"; by using the ABBR element in HTML, however, an author could enclose each instance of the abbreviation "d r period" in an ABBR, defining the word "Doctor" as the expansion for the first instance and "Drive" as the expansion for the second, so as to pass on to the AT the correct expansion for 2 identical abbreviations; the ABBR element, therefore, allows for the contextualization of abbreviations, and as such is of inestimable utility for accessibility, as well as for anyone indulging in mobile computing

MC: ok, that explains the HTML element ABBR, but what about this checkpoint?

LK: WCAG says use terse abbreviation

GJR: my understanding of the purpose of the checkpoint is that an author may want to use an abbreviation for a header for formatting purposes, so that the table columns won't distort his or her desired layout or the perceived gracefulness of the table; if the author has a header that reads "Cost of Tractor Part 1294XRQ, model Z299, manufactured by General Motors' Construction Parts Plant in Gary, Indiana", he could: (1) abbreviate it, so as to keep the heading short and terse; (2) enclose the abbreviation in an ABBR, if using HTML, so that anyone using the page visually, can mouseover to expand the abbreviation, or, for someone using a screen reader in combination with a UA with ABBR expansion set to "on", the AT would speak the expanded ABBR when that user queries the header, so that he or she is returned something semantically sensible, rather than a short string of cryptic characters, such as "TP Z299"

// ACTION GJR: ask GL WG for clarification on ABBR in header checkpoint in WCAG


MC: We're out of time

LK: OK--let's take our discussion to the list

Monday, 6 DECEMBER, 1999 (10 a.m. Boston time)
Monday, 20 DECEMBER 1999 (10 a.m. Boston time)


Terminal Index
1. ER-IG Home
2. ER-WG Home
3. Minutes from Past ER-IG Meetings
4. WAI Home Page
5. W3C Home

Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

W3C Validated HTML 4.0!