W3C

Techniques Task Force of the WCAG WG weekly telecon

2 Feb 2005

Agenda

See also: IRC log

Attendees

Present
Wendy, Alex_Li, Chris, Ben, Michael_Cooper, Shadi, John_Slatin, Becky_Gibson, David_MacDonald, Ken Kipnes
Regrets
Alistair_Garrison, Don_Evans
Chair
michael
Scribe
wendy

Contents


Finish review of alt text test files http://www.w3.org/WAI/GL/WCAG20/tests/checkstatus.html#alttests

[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

Review Fasttrack tests http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0341.html

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

Review proposal to close issues 734 and 739 http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0357.html

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

Action item reminder

<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

Summary of Action Items

[NEW] ACTION: bc, gv, js talk about GL 3.1 L1 #1
[NEW] ACTION: chris remove b/i tests
[NEW] ACTION: cr change the examples in 132
[NEW] ACTION: cr will either propose changes for 195, 192, 60 or
... we'll discuss on list (or call)
[NEW] ACTION: cr: modify tests to allow implicit, explicit, or
... title
[NEW] ACTION: everyone - please check action item list for those
... assigned to you
[NEW] ACTION: john check that b/i not used in gen techs for 1.3
[NEW] ACTION: mc mark technique ssim_textlinks as deprecated and
... add technique for alt. nav mech for serverr-side img maps (ala
... map sites)
[NEW] ACTION: michael add actions from today to bugzilla
[NEW] ACTION: michael add links to i18n info from html techs from
... specifying lang
[NEW] ACTION: michael look at html techs issues to see if this
... closes any
[NEW] ACTION: michael modify techniques to allow implicit,
... explicit, or title
[NEW] ACTION: michael revmoe b/i technique from html techs
[NEW] ACTION: someone record issue for mapping the text link tests
... to success criteria
[NEW] 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
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.109 (CVS log)
$Date: 2005/02/02 18:01:11 $