See also: IRC log
[Before we got started on this item, we had some discussion of the possible ways to group items in level 3 since there is concern about the inability to reach level 3 by following *all* SC in level 3]
cr: perhaps leave the controversial tests alone for now. the others that seemed to have agreement, accept via straw poll.
wac: had discussed a few, is the next step a proposal? or not enough info to make a proposal?
<scribe> ACTION: cr will either propose changes for 195, 192, 60 or we'll discuss on list (or call)
cr: feel that we have decided about 12, 13, 132
Test 12 - All IMG elements with an ISMAP attribute have a valid USEMAP attribute.
http://www.w3.org/WAI/GL/WCAG20/tests/test12.html
js: doesn't make sense to have both a server-side and a client-side image map
cr: the technique says to use client-side
instead of server-side
... therefore test 12 doesn't make sense.
Test 13 - All links in all client side image-maps are duplicated within the document.
http://www.w3.org/WAI/GL/WCAG20/tests/test13.html
js: dmd did some testing
cr: 2 people said to kill, 2 said optional
mc: part of the baseline assumption. therefore,
mark as transitional.
... it's a deprecated technique.
cr: should we dump it?
mc: don't have to dump it, unless dump the technique as well. but we've got a technique for a WCAG 1.0 checkpoint saying, "don't need to do this anymore"
js: helps people transition (from 1.0 to 2.0)
mc: needs to be clear it is deprecated
cr: so 13 stays in for now, but is deprecated.
wac: later discussion today's agenda to discuss what to do with deprecated techniques/tests
Test 132 - All active areas in all server-side image maps have duplicate text links in the document.
http://www.w3.org/WAI/GL/WCAG20/tests/test132.html
js: "available geometric shape" was probably before "poly" added to spec
cr: may need 1,000 text links for a server-side img map
bc: if can't make a client-side map (because too complex), then probaby need an alternative means that text-links may not provide the functionality.
js, dmd, mc agree
js: if we're thinking it's still possible that someone will need to use a server-side map and that an alternative navigation mechanism is required, need to have something in 2.4?
mc: map sites are using server-side image map
js: svg technique
bc: for 132 - don't want to require text links
mc: need to mark the technique as deprecated
... 132 is the same status as 13
<scribe> ACTION: mc mark technique ssim_textlinks as deprecated and add technique for alt. nav mech for serverr-side img maps (ala map sites)
kk: if we keep 132, the example is invalid.
<scribe> ACTION: cr change the examples in 132
cr: renaming incidental?
js: it was "not relevant" - haven't made a formal proposal
cr: some of the alt-text tests require
"decorative"
... can we assume that "decorative" be changed to "not relevant" in teh straw
poll
concern that "not relevant" might not sit well with designers who feel that decorations are relevant to the content. perhaps use "decorative" but provide examples to explain what we mean.
js: context may matter
bc: just about any photo will have text in it (e.g., street sign, t-shirt, etc.)
resolved: moving forward w/using "decorative" for now
29 - HTML document has a valid doctype declaration
http://www.w3.org/WAI/GL/WCAG20/tests/test29.html
mc: syntactically correct, or a preferred doctype
bc: someone raised an issue
<ben> http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=775
mc: do any asst. tech use doctype?
js: would it be an issue in the way xforms are handled?
mc: likely using namespaces
cr: suggesting that we dump it?
mc: just asking questions
js: these are html tests, html requires a doctype
bc: then we have to test for everything that the validator tests for?
cr: the benefits are iffy?
... let the valiator catch it?
mc: there is a wcag 1.0 checkpoint. if deprecate, would be saying "not important" but we still think doctype is necessary but it's require dby the spec so we don't have to require it.
http://www.w3.org/TR/html4/struct/global.html#idx-document_type_declaration-3
cr: this is a level 1 requirement
mc: valid code is level 1
http://www.w3.org/TR/xhtml1/#strict
wac: xhtml 1 requires both xmlns and doctype
bc: need to be specific in the test/technique which version of html using?
js: html 3.2 require doctype?
mc: do we say don't use anything previous to HTML 4.01
bg: concern about legacy applications
mc: could validate 3.2 against 4.01
<ben> http://www.w3.org/TR/REC-html32
bc: 3.2 also requires doctype
dmd: january 1997 for 3.2
mc: don't have to worry about. if using 3.2 is before accessibility guidelines, therefore likely to update for accessibility anyway.
49 - HTML document has a valid language code
http://www.w3.org/WAI/GL/WCAG20/tests/test49.html
bc: reads level 1 requirement from 3.1 does not require author to provide lang attribute
js: my intent (of proposing tha twording) was that author would provide something that automated tools could use.
wac: why would we have a level 1 requirement that doesn't require the author to do anything?
cr: not a big deal to require the lang attribute
js: i18n group thinks it is essential
mc: encoded in utf-8 and use the chinese characters it could be a japanese document. therefore, need lang attribute.
js: glyphs are different even if the charset is the same. therefore, use the lang attribute for subtle differences in rendering.
dmd: an accessibility issue?
js: if a japanese reader with a learning disability is seeing chars that are rendered slightly differently than what struggled to learn, increase reading difficulty (even more) for them.
mc: content lang header is equally valid, html spec requires lang
js: i18n says difficulties with the header
<scribe> ACTION: bc, gv, js talk about GL 3.1 L1 #1
mc: a valid lang code needs to be valid
value
... determining a valid value is difficult b/c the lang codes keep
changing
bc: i18n is clear
mc: however that list provides for both 2 and 3 chars, other variants
bc: ever remove anything?
mc: no
bc: as long as don't remove, then won't become invalid if you were valid
mc: could be valid but not pass the validator (if list hasn't been updated)
discussion about where the list is, how much it costs, how often it is updated, how it is updated
bc: ref i18n for which lang codes to use
<ben> tutorial: http://w3c.org/International/tutorials/tutorial-lang/
<ben> http://www.w3.org/TR/i18n-html-tech-lang/
js: gen techs links to
<scribe> ACTION: michael add links to i18n info from html techs from specifying lang
cr: test 48 is the presence test and then the code must be ok.
57 - INPUT, type of "text", has an explicit label
http://www.w3.org/WAI/GL/WCAG20/tests/test57.html
118 - INPUT, type of "password", has an explicit label
http://www.w3.org/WAI/GL/WCAG20/tests/test118.html
119 - INPUT, type of "checkbox", has an explicit label
http://www.w3.org/WAI/GL/WCAG20/tests/test119.html
120 - INPUT, type of "file", has an explicit label
http://www.w3.org/WAI/GL/WCAG20/tests/test120.html
121 - INPUT, type of "radio", has an explicit label
http://www.w3.org/WAI/GL/WCAG20/tests/test121.html
bg: concern about using explicit when spec says can use implicit.
js: if there is a label wrapped around, that is explicit.
mc: but the spec calls that explicit
bg: however, test requires label/for
js: note the user agent issue...
mc: explicit or implicit or title
bg: should be to spec
js: agree
cr: another test that discourages
bc: that's a repair technique
cr: allowing all 3 methods?
agreement: allow all three
<scribe> ACTION: michael modify techniques to allow implicit, explicit, or title
<scribe> ACTION: cr: modify tests to allow implicit, explicit, or title
116 - B (bold) element is not used
http://www.w3.org/WAI/GL/WCAG20/tests/test116.html
117 - I (italic) element is not used
http://www.w3.org/WAI/GL/WCAG20/tests/test117.html
bg: they are both in the spec. in techs - have use strong and i. have css techs that say, use css for b and i
http://www.bestkungfu.com/archive/date/2004/05/strongly-emphasizing-semantics/
js: theoretically could modify sound scheme to do something diff for b and strong, however, typically don't hear a difference.
dmd: does XHTML still use b and i?
b and i are not in the latest WD of XHTMl 2.0
dmd: is it an accessibility issue?
... or is it compliance?
mc: think we thought it was going to be a few years ago.
dmd: it seems a little dogmatic, if it's not an accessibilty issue.
bc: if informative, say good advice? at future point, require it?
cr: currently level 1
mc: level 1 to require valid markup
... a technique that matters about version of html
bc: checklist will have to depend on html version?
mc: if xhtml, don't say anything about (validator will pick up)
where is it WCAG 1.0? currently in defn of http://www.w3.org/TR/WCAG10/#style-sheet
will need to list removed techniques
<scribe> ACTION: michael revmoe b/i technique from html techs
<scribe> ACTION: chris remove b/i tests
<scribe> ACTION: michael look at html techs issues to see if this closes any
action 10 = ben look at html techs issues to see if this closes any
<scribe> ACTION: john check that b/i not used in gen techs for 1.3
no change to css techs
174 - Source anchor contains text.
http://www.w3.org/WAI/GL/WCAG20/tests/test174.html
js: source anchor = ??
mc: expand procedure to check for text - currently only checks for img/alt
wac: isn't there another test about this? combine them?
js: this is related, but different
mc: think this is link-text issue, img in an
anchoor could be dropped.
... don't remembre outcome of that discussion.
bc: can you have an object in an a?
mc: in theory, yes
bc: should be talking about text equivs in generic sense instead of alt
mc: need for both - tool will look at anchor or an img, wanted test for each
cr: do have another test for text (imgs must hav alt text)
other tests:
* Alt text for all IMG elements used as source anchors identifies the destination of the link. (test 15)
* Alt text for all IMG elements used as source anchors is not empty when there is no other text in the anchor. (test 7)
* Alt text for all IMG elements used as source anchors is different from the link text. (test 175)
* Alt text for all IMG elements used as source anchors does not begin with "link to" or "go to" (English). (test 195)
mc: propose dropping 1st 2
Test 174 - Each source anchor contains text.
174 says that text for anchor can come from alt-text of img or from text in anchor.
7 and 15 - not necessary b/c of 174 and 197
Test 197 - Each source anchor contains text that describes the link destination.
195 - "the link text"
instead of restricting to alt-text
195 - level 2
mc: currently maps to a level 3
<scribe> ACTION: someone record issue for mapping the text link tests to success criteria
resolved: keep tests 174,175, 195 (w/modification), 197. drop 15 and 7
mc: summarizes becky's message
http://www.w3.org/TR/WCAG20-CSS-TECHS/#number-not-name
wac: is it an accessibility issue? similar to b and i discussion earlier, you can get the info, but how often do you need it or want it?
js: must be enough people doing proofreading who get the info.
mc: user agent issue w/the 3 digit hex value
bc: it's an optional technique, it's good advice
mc: close the 2 bugs by making optional technique
<scribe> ACTION: wendy close bugs 734, 739, remove editorial note from number-not-name, change id of number-not-name, add more info about benefits/flesh out description of technique (e.g., get info from john about proofreading), delete rbg example
<Michael> action items list: http://trace.wisc.edu/bugzilla_wcag/condensedreports/actionitems.php
<scribe> ACTION: michael add actions from today to bugzilla
<scribe> ACTION: everyone - please check action item list for those assigned to you
!ACTION: don't add last 2 action items to bugzilla
next week: requirements, more tests, checklists