14 April 2000



Wendy Chisholm
Gregg Vanderheiden

Scribe's Note: the following abbreviations are used capriciously throughout these minutes:

JW: using Evaluation and Repair Document (ERT) to review checkpoints, because has WCAG checkpoints listed in numerical order; better than WCAG checklist, which is by priority; the problem is that I'm sitting here with a braille display attempting to read the document while leading discussion, which is a bit awkward

GJR: could CMN read each checkpoint and then JW could lead discussion?

CMN: will get a copy up


1.1 Provide a text equivalent for every non-text element [Priority 1]
Refer also to checkpoint 9.1 and checkpoint 13.10.
Techniques for checkpoint 1.1

JW: seems fine; my problem is with the examples -- they are far too HTML specific; any reactions?

ASW: I agree

JW: one issue that I did have is that at some point -- maybe as separate checkpoint -- that we develop a requirement that is a generalization of the image map checkpoints that could be applied to SVG as well, what I'm getting at is that, by requiring that authors label regions of an image where the markup language allows this, we can cover both client-side image maps and SVG; I perceive a need for a separate checkpoint, so as to avoid overburdening the first checkpoint with too many requirements -- reactions?

// NONE //

1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1]
Refer also to checkpoint 1.5 and checkpoint 9.1.
Techniques for checkpoint 1.2

JW: not sure what to do with that one -- very specific to legacy technology

GJR: could be technique under 1.1 -- replace with generalized language

CMN: I agree--it's just a special case of 1.1

JW: ok, so put a technique in the HTML module, but the question remains, should we have a checkpoint dealing with images that have sensitive regions, and if so, does it fall under labeling parts of image, rather than an image as a whole?; with SVG one can describe parts of image -- that is a very good functionality of SVG that should be stressed here; possibly as a technique for 1.1 under the SVG module, or as part of proposed checkpoint -- ideas?

// NONE //

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1]
Techniques for checkpoint 1.3

JW: seems fine as it stands -- any objections?

// NONE //

JW: my only qualification is that I would like us to develop a better alternative to the "Until user agent." expression; I know that it is a long term issue that has been with us since the beginning of the GL drafting process, but if anyone has superior methodology for dealing with the "Until user agent." concept, either by better wording or by lumping all of the until clauses into one GL, please propose on list

CMN: there may be other pieces to this puzzle

// ACTION CMN: think about the other pieces //

JW: the idea behind the current WCAG 1.3 needs to exist, but not, I think, as part of 1.1, although perhaps there is a way to combine them

CMN: question is: does 1.1 capture the concept of subordinate textual equivalents that can be used to describe parts of an image, as well as the concept that the image as a whole needs to be described succinctly

1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]
Techniques for checkpoint 1.4

JW: my initial feeling was that this expresses a concept that is sufficiently important that it should be separated from related concepts; while I think it still should be, there is the possibility of combining 1.3 and 1.4

CMN: synchronization cues are important -- provided that they well written

JW: good idea -- I personally endorse it; other comments?

CMN: confused about what you endorse

JW: that we leave WCAG 1.4 as is -- it is very good as it stands; if being ruthless in our quest for consolidation and abstraction, could roll into 1.3, but I feel that it is important enough to stand alone as a separate requirement

1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3]
Refer also to checkpoint 1.2 and checkpoint 9.1.
Techniques for checkpoint 1.5

JW: all to do with client side image maps

CMN: 2 things -- ensure that there is an equivalent; in some cases there are things that need to be done manually; first part is subsumed by 1.2 (making text equivalent available); rest belongs under the concept of transforming gracefully

// Cynthia Shelly (CS) joins //

CMN: things that have to do with "until user agents." need to be kept in one place -- then we can address the outstanding issues about what we mean and what we expect

JW: that is an issue that needs to be dealt with on its own; any other comments on GL1?

CMN: to summarize: 1.2 is subsumed under 1.1; 1.3 and 1.4 stand on own; 1.5 partly subsumed under 1.1 and partly separated by "until user agents."; any objections to my summarization?

// NONE //

GL2 ""

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1]
Techniques for checkpoint 2.1

JW: quite like this one

CS: already pretty general

JW: anyone identify any problems with it?

CMN: I have a vague thought -- I'll come back to it later if we have time, or post it on list if not

WCAG 2.2

2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].
Techniques for checkpoint 2.2

JW: somewhat separate requirement than 2.1 -- could combine if wanted, but there is, in my opinion, no compelling reason to do so

CS: 2.2 is lower priority, which I think is a good reason to maintain the separation; the problem I had with this one is that there aren't good examples on what comprises sufficient contrast and what doesn't

JW: that is a Techniques document issue if it hasn't already been addressed in the latest version of the Techniques document

     Scribe's note:
     1) The most recent version of the WCAG Techniques
     document can always be found using the following
     2) As of this teleconference, the latest version
     of the WCAG Techniques document is that dated 9
     March 2000:

GL 3

WCAG 3.1

3.1 When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2]
Refer also to guideline 6 and guideline 11.
Techniques for checkpoint 3.1

JW: speaks directly to an unfortunate legacy of the evolution of markup languages and their usage

CMN: this is one where I would generalize the concept fairly substantially

JW: the GL itself implies this; could say "Use available -- and widely deployed? -- markup languages to represent content"

CMN: have in WCAG when language exists use instead of images, use relative units, markup lists, quotations, changes in natural language -- my approach would be to say "Use semantically sensible markup languages"

JW: Use available markup languages according to specification

CMN: would like to make new requirement -- the current one about using appropriate markup languages is far too woolly; would like to have one that says "Use semantic markup" or "Mark up semantics according to specification" -- that covers the whole thing; SVG and SMIL and other markup languages are non-textual ways of conveying information, but they provide enough semantic and structural information to make the content they control intelligible in other modalities

CS: also use alternative equivalents for UAs that don't support those markup languages

JW: one area that needs to be improved is that we don't specify what needs to be preserved;

CMN: first: a markup language will typically specify semantics of what one can mark up using that language -- authors should be encouraged (or required) to mark up those things properly, within the context of the markup language being used

JW: if one is using WCAG to design a markup language or an XML application, is there utility in having an indication of what is absolutely necessary without drafting an exhaustive list of what is needed? don't want a straight listing of common weak usage cases, but a strong indicator of what a new markup language or XML application needs in order for it to be accessible

CMN: seems to me a very big ball of wax for us to tackle today

JW: no, not today, but it does need to be investigated; if not in this guidelines document, then in something specifically addressing the design of XML applications; make sure that content can be marked up semantically and in a well-structured manner; stylesheets can be mentioned as another checkpoint under this GL, relative units could be subsumed under using stylesheets appropriately

WCAG 3.2 to 3.7

3.2 Create documents that validate to published formal grammars. [Priority 2]
Techniques for checkpoint 3.2
3.3 Use style sheets to control layout and presentation. [Priority 2]
Techniques for checkpoint 3.3
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2]
Techniques for checkpoint 3.4
3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
Techniques for checkpoint 3.5
3.6 Mark up lists and list items properly. [Priority 2]
Techniques for checkpoint 3.6
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2]
Techniques for checkpoint 3.7

CMN: would keep 3.2, 3.3, and 3.4 separate for the minute; 3.5, 3.6 and 3.7 should be rolled together under "Use semantics and structure in accordance with the markup language being used"

JW: essentially what I was thinking

CS: you're not mentioning CSS relative sizes

CMN: right, because those are relative things; that is an implementation detail

CS: but "em" and percentage are mentioned in example text

CMN: examples are editorial, and will be changed

JW: they are also non-normative

CS: that's not entirely clear when reading WCAG

CMN: send note on that to list to spark discussion on it

CS: will do

// ACTION CS: post concerns about examples used in GL3 (and anywhere else that concern her) to list //


WCAG 4.1

4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1]
Techniques for checkpoint 4.1

CS: pretty straightforward

JW: could combine with language declaration requirement for the entire document; they have different priorities, though, don't they?

CMN: they do, but these 2 checkpoints should appear in close proximity to one another

JW: yes, reordering necessary

// RESOLVED: Reorder GL4 so as to make the current 4.3 checkpoint 4.2, and renumber the remainder accordingly //

WCAG 4.2

4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3]
Techniques for checkpoint 4.2

CMN: in HTML, for example, this would be covered by "provide semantic info" under GL3

JW: yes; well, it could be, depending upon how you interpret "semantics"

CMN: one issue that will arise is the prioritizing of kinds of semantics

JW: another issue is that of using specialized dictionaries to guide pronunciation or to define unusual vocabulary; those can be very useful accessibility aids; ACRONYM and ABBR specialized case of more generalized problem; we could have a checkpoint devoted to that more generalized problem or roll all under GL3

CMN: start by subsuming all under GL3, but mark for review; we're looking to collapse things down, right?

JW: as much as possible without losing anything

CMN: then let's keep this as an open issue

CS: I think would be better under GL3

WCAG 4.3

4.3 Identify the primary natural language of a document. [Priority 3]
Techniques for checkpoint 4.3

JW: 4.3 should be 4.2; we can't put it under 4.1 because of different priority

CS: one minor comment; I know that priority levels aren't based on ease of doing things, but 4.3 is very easy, so would there actually be a problem rolling it into 4.1?

CMN: you wouldn't think so, but we have had objections to that in the past

JW: 4.1 is what is really important, 4.3 doesn't matter as much; documents that use mixed languages is the problem that needs to be solved

CS: yes, declaration of a natural language for a page is a much more common scenario than indicating the natural language of a resource or span of text


WCAG 5.1 - to 5.7

5.1 For data tables, identify row and column headers. [Priority 1]
Techniques for checkpoint 5.1
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1]
Techniques for checkpoint 5.2
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]
Refer also to checkpoint 3.3.
Techniques for checkpoint 5.3
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]
Techniques for checkpoint 5.4
5.5 Provide summaries for tables. [Priority 3]
Techniques for checkpoint 5.5
5.6 Provide abbreviations for header labels. [Priority 3]
Techniques for checkpoint 5.6

JW: think can deal with these as a block; 5.1 "Identifying row and column headers" -- there is an interesting relationship between this and forms; the requirement could be dropped into GL3 as part of a catch-all semantic requirement; this is an interesting requirement in relation to tables and forms -- associating category or field names with corresponding values -- row and column headers are only a special case of that; this requirement should be specified in a way that covers tables, forms, and anything else with similar capabilities

CS: data and layout tables in same section is confusing; admonition from using layout tables going to make a lot of people reject this GL as a gut reaction; having a separate section for data tables and layout tables would lead to more conformance; the 2 types of table should be split

JW: anything to do with layout tables should be in HTML module of techniques and eliminated from guidelines; should go under existing checkpoints that cover structure and presentation

CMN: a lot of this falls under GL3

JW: idea -- not proposal -- checkpoint under GL3 which discusses field names and field values to make clear that that is a requirement -- where can't be determined automatically, need to be made explicit; would cover tables and forms in one fell swoop and perhaps other

CMN: 4.4 could be extended to cover other things

JW: drop into GL3 and generalize it; could go after general semantic checkpoint -- any negative reactions to that?

// NONE //

WGAC 5.3

JW: already discussed; idea is move under more general CP under GL3 or more general CP stating that shouldn't use structural markup for presentational purposes; could discuss conditions as separate or partial exception under CP or in techniques doc; whole requirement should be subsumed

WCAG 5.4

JW: expansion on 5.3, so should go the same way as 5.3 -- become part of a more general checkpoint under GL3

WCAG 5.5

CMN: covered by 1.1

JW: don't think so -- summary not an equivalent -- doesn't give same info as table; not the same granularity or detail

CMN: almost no equivalent is better than none

CS: very HTML specific

JW: reluctant to over-use concept of equivalents; could be better specified -- providing a summary for certain types of content is useful, so could become a separate generalized checkpoint;

CS: provide summaries for content which is complicated or relies on layout

JW: has complex structure; complex structure in a table not visual, but semantic; content cells will have one or more categories into which they fall due to headers; complicated by fact that there are different ways in which one can read it

WCAG 5.6

CS: very HTML specific

JW: ACRONYM and ABBR could go into general discussion of providing definitions and explanations, and pronunciation information; details can be worked out; CMN also suggested moving under GL3 -- possibility if deal with ABBR and ACRONYM as special cases

CS: this CP is a special case of a special case!

JW: yes; any more comments on GL5?

// NONE //


JW: we're going to have problems with some of these

WCAG 6.1

6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1]
Techniques for checkpoint 6.1

JW: already a serious problem; XML formats inherently rely on stylesheets for presentation; one way of dealing with this is to delete it

CMN: don't think that is a good enough solution

JW: me neither

CS: is primary goal backwards compatibility?

CMN: sensible ordering model for backwards compatibility; content in sensible order in source form

CS: wording that is here should be in HTML techniques; in XML, the important thing is the need to allow user to substitute own stylesheet

JW: doesn't really pick up basic rationale; same issue arises with SVG -- want proper logical groupings of content in same way want logical ordering in an HTML file; default rendering in case of HTML is reasonable

JW: where UAs have support for rendering without stylesheets.

CMN: it's about having stuff which produces content that is, to some extent, readable

CS: assuming that target audience is human, not machine

CMN: even if target is machine, ensure that comprehensible by humans to a certain degree

JW: part of it is solved by GL3 -- proper structure and semantics -- then with different stylesheet or none, in case of HTML, renders in proper way; could put under GL3 or leave here; might not be appropriate here -- proper ordering of markup, structure, and semantics make application of alternative or client-side stylesheets possible and practical -- issue that needs to be worked on; just harvesting thoughts today, remember, so let's move to 6.2

WCAG 6.2

6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1]
Techniques for checkpoint 6.2

CS: unclear on what 6.2 means?

CMN: anything that changes

CS: how do you generalize?

JW: that CP is about as general as can get; our goal is one set of GLs with multiple techniques, one thing could go into HTML techniques, another might be more appropriate elsewhere

WCAG 6.3

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]
Refer also to guideline 1.
Techniques for checkpoint 6.3

JW: again, this CP is about as general as it can get

CS: there times when doesn't make sense; applications written using web technologies, rather than documents that are products of a web-based application

GJR: don't perceive the difference -- the question is: what is the end result for the user? doesn't matter how page generated, as long as user has access to all content

JW: correct, and it has already been ruled out of scope for these GLs

CS: but the line isn't clear; when trying to build a dynamic page, is it an application or document?

CMN: both, so if it is not accessible, it is not accessible

CS: what if it is accessible with scripts on and using MSAA

CMN: that is a very special case

GJR: that is a case where the document or application itself is not accessible; that is the scope of these GLs; not "this page conforms to WCAG provided that."

CS: I still have a concern: I'm confused as to what I have to do in order to make a web-based application accessible versus what I need to do to ensure that a document is accessible

CMN: is thing on the web or just written in HTML; if latter, not, strictly speaking, web content

CS: what if the thing is an HTML-formatted dialog caused by an HTTP call?

CMN: please put these issues on list to start discussion on specific cases

JW: checkpoint still as general as possible, needs to be kept

WCAG 6.4

6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]
Techniques for checkpoint 6.4

JW: about as general as can get

CMN: event handlers are part of ensuring that scripts and applets are accessible under GL8

JW: could drop under GL8

CMN: probably the same case for 6.5

WCAG 6.5

6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]
Techniques for checkpoint 6.5

CMN: partly covered under 6.1, and partly covered under GL8 -- 8.1 to be precise

JW: right; whole issue of direct accessibility needs to be developed in relation to capabilities given by DOM2 and beyond; need to work out best way to work out requirements


WCAG 7.1 to 7.3

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1]
Techniques for checkpoint 7.1
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2]
Techniques for checkpoint 7.2
7.3 Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2]
Refer also to guideline 8.
Techniques for checkpoint 7.3

JW: 7.1 and 7.2 are very close -- what is priority level of each?

CS: 7.2 is P2

JW: what about 7.3?

CS: could be combined with 7.2

JW: so, combine 7.2 and 7.3 and keep 7.1 separate?

CMN: my problem is distinguishing between flickering images and blinking text

JW: reason for P1 is flicker can cause seizures

CS: does blinking text cause same problem?

CMN: not clear to me difference between images and text blinking

JW: difference is degree

GJR: suggest that we discuss this with the ER WG -- they had an extended discussion over these particular checkpoints this past summer

CMN: I'm fine with globbing them all together, but only if we put a big question mark on priority level

JW: that's what I was thinking

CMN: other point is the whole thing of this is all "until user agent stuff", which we want to roll together

JW: at least can say conservatively trying to roll 3 checkpoints into 1 and examine priority level carefully afterward

WCAG 7.4 and 7.5

7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2]
Techniques for checkpoint 7.4
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. [Priority 2]
Techniques for checkpoint 7.5

CS: 7.4 and 7.5 pretty similar

CMN: difference is interestingly small; or perhaps uninterestingly small

JW: the latter, and 7.4 and 7.5 should be combined; there is also the "until User Agents." issue; is there a more sensible way of dealing with those types of issues?

// CMN recorded as doing his part in the global campaign to get individuals to upgrade their browsers //


WCAG 8.1

8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
Refer also to guideline 6.
Techniques for checkpoint 8.1

JW: only one CP under this GL

CMN: leave alone

JW: one where have to make requirements clearer

CMN: that's what the Techniques are for; have people been following the thread on IG? majority of IG traffic for moment

Scribe's Note: The thread, entitled "Seeking Guidance" begins at:
< >


WCAG 9.2 and 9.3

9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2]
Refer to the definition of device independence.
Refer also to guideline 8.
Techniques for checkpoint 9.2
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]
Techniques for checkpoint 9.3

CMN: want to start at 9.2 -- 9.2 and 9.3 covered in 8.1

JW: should all be brought under GL8?

WCAG 9.1

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1]
Refer also to checkpoint 1.1, checkpoint 1.2, and checkpoint 1.5.
Techniques for checkpoint 9.1

CMN: 9.1 very HTML oriented; not sure how to abstract

JW: the advantage of SVG is that can write up image and label and describe portions of it, image map the same thing -- can't describe each part of server-side imagemap,

JW: P1 in relation to image map and P2 for other images; general requirement use image markup formats or MLs that allow regions of images to be labeled and or described; different priorities under different circumstances

CMN: WCAG 13.1 " Clearly identify the target of each link" - - is exactly the thing that server-side image maps can't do;

CS: backwards compatibility issues of server-side image maps; can superimpose a client-side image map over a serverside one to provide for graceful degradation

JW: affinity between SVG and image maps, needs to be highlighted; in SVG can put actions on sections of images, and can describe them -- agree that should be brought under 13.1 -- could also be addressed as a more general way to address the multiple/single equivalency conflict/controversy

CMN: implied in part by 1.1 and 13.1, as well as GL3 part marking up semantics; marking up semantic concept of image

JW: GL3 will need special attention without clear explanations, meaning won't be obvious; semantic issue on SVG in relation to grouping different than equivalent issue for parts of images; under GL1 could have requirement regarding preference for ML that allows one to label parts of image

WCAG 9.4 and 9.5

9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]
Techniques for checkpoint 9.4
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3]
Techniques for checkpoint 9.5

CS: put 9.4 and 9.5 together

JW: my thinking is slightly different, but closely related, so should try to combine

// time check -- 10 minutes remaining //


10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]
Techniques for checkpoint 10.1
10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2]
Refer also to checkpoint 12.4.
Techniques for checkpoint 10.2
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. [Priority 3]
Techniques for checkpoint 10.3
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]
Techniques for checkpoint 10.4
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3]
Techniques for checkpoint 10.5

JW: similar to auto-refresh and updating

CS: if doing popups with scripts, alert people beforehand

CMN: better ways of doing it than not doing it at all

JW: partly based on needs of CD community

CMN: group refreshing and redirecting together; GL10 is all "until user agent" class; more specific solutions -- need to figure out base requirements of users agents

JW: generalizing requirements; 10.2 already subsumed by proposed checkpoint for field names

CS: still need temporary techniques

CMN: problem is things that are "permanently temporary" boundaries not defined

CS: maybe issue better addressed in longer white paper

JW: should be addressed in HTML techniques document

CMN: getting back to the things you have to do now; outside of English speaking countries, can't make the assumption that UA fixes going to permeate globally; not everyone has MSAA or a newer UA or assistive technology for their native language

CS: type of audience is another question; I'm interested in whether home pages tailored for a particular browser are ok, if they are accessible?

JW: point is, don't write pages for a particular browser

CS: but that's exactly what people do

JW: common practice -- especially when erroneous -- shouldn't drive WCAG,; I am opposed to segmenting by UA; by segmenting by knowledge or expertise is probably inevitable

CMN: each thing is incredibly specific; need to figure out how to get rid of the "until user agent clause"; there is an assumption that we can get rid of these checkpoints, but when?

JW: I think a year ahead

CMN: that's a very optimistic forecast

GJR: "until user agent" checkpoints should be addressed in concert with ER; strategies and repair implementations are supposedly the purview of the ER WG -- only when repair strategies are available as proxies (or plug ins) is it going to be possible for us, in good conscience, to remove the "until user agent." clauses and checkpoints

CMN: also need to make explicit things that aren't yet explicit

JW: there is still an outstanding action item for all GL WG members to go through the rest of checkpoints and to work on generalization strategies before dealing with those kinds of issues;

// time check: 5:35 PM Boston time //

JW: in summation, GL10 has a big question on it; I'm proposing that we discuss the remaining checkpoints on list; we can run a session to continue the work we have gotten a very good start on today in next week's teleconference if necessary; we do have a constraint here -- the User Agent WG may still want a discussion of the navigation portion of our respective documents; we may have already clarified their concerns sufficiently via email, which would preclude the necessity of a joint telecon; completion of this work, and equally necessary discussion on generalization, should be completed before we address specific issues; discussion on CD has been subject of much traffic on list -- question is establishing priorities for next meeting, and seeing how much of remaining work can be done on-list; general action item from last week still stands; If UA WG feels that navigation issues need to be addressed could do at next teleconference or at the following telecon

// Telecon Adjourns at 5:37 PM Boston time //