GL TELECON
14 April 2000
Attendance
Present
Regrets
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
GL1
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 //
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 //
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
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
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 ""
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
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
URI:
<http://www.w3.org/WAI/GL/WCAG10-TECHS>
2) As of this teleconference, the latest version
of the WCAG Techniques document is that dated 9
March 2000:
<http://www.w3.org/WAI/GL/WD-WCAG10-TECHS-20000309/>
GL 3
WCAG 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
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 //
GL4
WCAG 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
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
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
GL5
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 //
GL6
JW: we're going to have problems with some of these
WCAG 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
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
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
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
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
GL7
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
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 //
GL8
WCAG 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:
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2000AprJun/0009.html
>
GL9
CMN: want to start at 9.2 -- 9.2 and 9.3 covered in 8.1
JW: should all be brought under GL8?
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
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 //
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 //