WCAG WG TTF weekly telecon

finish reviewing alt-text test files

cr: would like to either accept or reject tests. how do we do that? majority rules - look at straw poll, if don't say kill, it's accepted?

mc: everything is open, will get discussed in public draft.

cr: simplify the poll to "accept" or "reject"?
... accepted means that we agree to publish in a public draft
... we need to have closure on these.
... will go through the 6 final tests re: alt-text.

<ChrisR> check status: http://www.w3.org/WAI/GL/WCAG20/tests/checkstatus.html

Alt text for all AREA elements identifies the purpose or function of the image area. (test 65)

cr: it means the link destination

mc: whatever confusion we had for the other test, doesn't apply to area. should be straightforward

bc: associate this with level 2 #6 under gl 3.2

cr: currenlty has as 1.1

bc: changes the level of it, but seems more straightforward

wac: concern about changing the level. wording maps well to 1.1, concern about level 2

mc: we need test files now w/out worrying about the level

bc: #6 is The destination of each link is identified through words or phrases that either occur in the link or can be programmatically determined.

wac: 3.2 criterion seems to be a subset of the 1.1 criterion.

js: slight update needed to rewording to map to latest 1.1 text

cr: like the language of the 3.2 criterion, it's clearer.

wac: accept the test, map to both, futz with wording later

175 - Alt text for all IMG elements used as a source anchors is different from the link text.

http://www.w3.org/WAI/GL/WCAG20/tests/test175.html

cr: idea is to avoid redundancy and duplication

mc need to clarify in applicability condition that only applicable if other link text in the link

js: concerned that could get slight variations in wording, but basically synonyms and still pass the test.
... alt-text of scissors and text says "delete" and alt-text says "cut" that would technically pass.
... but it would be potentially confusing

bc: in a 2 cell table, text for img and link were identical. seems it is a user agent issue. creating confusion by making them be slightly different when purpose is the same.

mc: bc's example is 2 links. this test is the img and text in the same link.
... do we have a test for that?

cr: prereq test, requires that img is "" if img is decorative. in js's example, alt text could be ::

js: don't think that you can say that img is decorative. for some, the iconic representation is more understandable than the text.
... what if we had a test that said, "if the screen text identisifes the 3.2 test, then the req is the alt attribute is empty?"
... there is text that identifies the link destination, in that case, the alt should be empty.

mc: new window al-text on img, link text is ... not empty. not desirable 100% of the time.

chris

cr: ditto

js: the img is not decorative, conveying info. graphic in the link would have to meet test of convey same info as the graphic.
... it tells the user that it opens in a new window and link provides the destination.

mc: need to create new tests or add detail to this test?

cr: define decorative? define where should be different?

js: when the img conveys diff info from the link text, the alt-text should be different.

cr: think the two things should always be different.

mc: never be the same

js: true
... it's never decorative when it is in the link

mc: sometimes it is

cr: the picture of scissors and text is "cut"

js: that is not decorative. it's a functional graphic and for some users is the primary interface element.
... decorative if the img can be dispensed with

bg: what should the alt-text be?

js: ""

bg: do we really need to get involved if it is decorative or not?
... "" is different from "cut"

bc: propose - Alt text for all IMG elements used within anchors is different from the link text when the image is not decorative.
... only applies when not decorative

mc: sounds like this test is ok, although may want to create other tests. perhaps bc's proposal will help.

cr: reluctant to change the text, b/c it is already long. to add something to it (in title), might make more confusing.
... propose that this test is ok. perhaps, look back at test for decorative.

wac: does decorative test say anything about links?

cr: should at least put in another example (when img used in link).

js: think we decided to use word "decorative" in the test and then use the SC language...

cr: yes, that's in the test.

js: therefore, definition of decorative is not that open.

cr: agreeing this test is ok, perhaps look at decorative.

<scribe> ACTION: cr will send msgs to list on test 16 (decorative)

Alt text for all INPUT elements with a TYPE attribute value of "image" contains all text in the image unless the image text is decorative or appears elsewhere in the document. (test 193)

http://www.w3.org/WAI/GL/WCAG20/tests/test193.html

mc: even if it appears elsewhere you need the text in the context of the submit function

cr: think that decorative is the same as incidental

js: incidental has different connotation than decorative. ok to use incidental instead of decroative.

cr: remove "appears elsewhere in the document"

bg: don't you want to ensure that the img will convey the img will submit? if i use input type='image and it doesn't contain text, nothing that says it must say it is a submit button. is that covered by another test?
... aren't we covered by another test? guess not b/c it is image id as submit button.

cr: test 59 says, "Alt text for all INPUT elements with a TYPE attribute value of "image" identifies the purpose or function of the image."

bg: only talks about the text not that it is a submit button

cr: this is to ensure that if there is text in the img it is also in the alt-text
... don't think we answered question about incidental.

<Zakim> wendy, you wanted to say "define incidental instead of dec"

js: not saying to use incidental every place

ag: concerned about translatability of "incidental"

cr: remove "elsewhere int he doc..."
... perhaps have ambiguity with "decorative"

<scribe> ACTION: john look for good, translatable synonym for incidental

<scribe> ACTION: chris modify test 193 (remove "elsewhere in teh doc...")

<David> Definition of incidental: 1) occurring or apt to occur as an unpredictable or minor concomitat 2) or a minor, casual, or subordinat nature

bc: think we'll have several similar tests for each element. can we generalize the test? a test that applies to all non-text content?

cr: no. they are a little different. alt-text for img may be different. can have a longdesc (that can contain text from the img). won't have longdesc for submit button.

bc: i'm ok with accepting it for now, but if we see several nearly identical tests we may want to create some general tests.

194 - Alt text for all AREA elements contains all text in the image area unless the image text is decorative or appears elsewhere in the document.

http://www.w3.org/WAI/GL/WCAG20/tests/test194.html

dmd: related to ben's point - thinking about how people will go through the document - lists of links of tests.
... concerned that people will be confused by the similarities and number of tests.
... realize that in a machine environement, it can rattle through, but the amount of tests are a lot for a human to handle.

mc: re: test 194 - drop "or appears elsewhere" as with the last test

cr: agree to remove "elsewhere". david's question is realted to discussion on checklists.

bc: are there cases where the text in the img might be described in a longdesc?

cr: can have longdesc on area?

bc: could be attached to the image

mc: if the text in the img under the region defined by area is part of what the graphical user perceives as link text, then should all be in the area. in longdesc is not sufficient. won't be accessing at same time as accessing link.

wac: "If the text is not decorative, " ... removing entirely? or replace with something? seems that something should be there.

cr: ensure that any text in img goes in alt. prereq that alt must identify the destination. don't have a prereq for empty alt because don't think you can have empty alt for area.

<scribe> ACTION: chris drop "if the text is not decorative..." for test 194

process questions: time on other 2 tests or move to checklists, applicability conditions

Alt text for all IMG elements used as source anchors does not begin with "link to" or "go to" (English). (test 195)

http://www.w3.org/WAI/GL/WCAG20/tests/test195.html

Alt text for all INPUT elements with a TYPE attribute value of "image" does not use the words "submit" or "button" (English). (test 192)

http://www.w3.org/WAI/GL/WCAG20/tests/test192.html

<David> does jaws say "submit"? on a submit button

mc: agree with in principle. w/submit button - often text just says "submit." we said want alt-text to be the same as image text. conflicts w/previous tests.
... not sure can apply all the time.

dmd: i like the first one, the 2nd has problems that mc suggested.

js: agree w/david.
... alt-text for a button should not contain "button" but "submit" seems ok if that's the text in the img.

bc: "go to" may not apply everywhere. on kids' sites especially. places where could be valid. "visit the x page..." no reason to ban at level 1.

js: bc's point is good. issue is not when there is a single link, it's when you have several links that begin with the same phrase or letter than prevents navigating in alpha order from link list.

cr: agree these are not reallylevel 1. they are nice things to do.

wac: perhaps map to the level 2 criterion in 3.2

js: agree w/ben that if it ok if there a single link than if there are 7 link sthat all say the same thing

dmd: need a separate test?

wac: add to this test. if it occrus once, ok. more than once, an issue.

cr: what is the cut-off limit? does it depend on the language?

dmd: for simplicity - more than one.

cr: for 195, if more than once, not ok.

bc: remove "go to"

js: would like to keep it.

dmd: for that matter, for any 1st two words...any time the 1st two words are the same in more than 2 links have issues.
... there may be other words we're not thinking of...

wac: that would make it less English-specific

js: the more i think about it, the harder this one becomes. there are places wher eit is legit for text to be the same. e.g., mlutiple versions of a doc (word, pdf)
... word verison of [title of doc], pdf version of [title of doc] - either way you get the same words.
... if it appears twice...

dmd: increase # to 5 words?

bc: make the test optional

ag: make it optional. if you pick up 2 word combinations, then have to generate more and justify why.
... should write a best practices document if you want to talk about that.

js: the problem is tha the usefulness of the alt-text decreases if all alt-text links begin wtih the same words.
... have to manually scroll through each link rather than jump by letter

kk: when first brought up test, at first questioned "go to" but after discussion, agree (esp on multiple links) this is probably not a good way to do it.

cr: map to other guideline and add "more than once" to the test. you can put it in once, ok. more than once, nope.

<scribe> ACTION: chris map test 195 to guideline 3.2 and add "more than once" to the test. you can put it in once, ok. more than once, nope.

js: language issue?

ag: how apply it to all languages?

cr: two issues - look for "link tos" and "go tos" and second - don't want links that start with same things.

ag: get rid of this test entirely. if keep it, write it generically, "words used to start links...don't do it"

bc: agreed a while back that would table something that is not sufficient for meeting success criteria. propose to drop for now and revisit later.

cr: do i discuss this on the list?
... want to discuss on the list or not?

<scribe> ACTION: chris take test 195 to the list for discussion

Alt text for all INPUT elements with a TYPE attribute value of "image" does not use the words "submit" or "button" (English). (test 192)

<scribe> ACTION: chris take test 192 to the list

checklists

http://www.accessinmind.com/w3c/ConceptPage1.html

http://www.accessinmind.com/w3c/ConceptPage2.html

http://www.accessinmind.com/w3c/ConceptPage3.html

ag: building these checklists is based on applicability condidtions and keywords.
... build applicability conditions into techniques.
... then can determine if technique/test is n/a, pass, or fail
... possible changes to techniques: http://www.accessinmind.com/w3c/General1_1.html
... could mark a technique as always required, in that case, no applicability conditions.
... for a general technique - see 4 boxes:
... Applicability Conditions, Testable Statements, Related Tests From WCAG 2.0 Test Suite, Resources
... if one of these statements is true, then this technique is applicable:

* Is the web content itself non-text content which provides a function (e.g. A flash animation)?

* Does the web page contain non-text content which provides a function?

ag: if applicable, then look at the Testable Statements
... then link test suite tests to testable statements
... another example - http://www.accessinmind.com/w3c/HTML14_4.html

dmd: not sure understand the first checklist prototype, changes to techniques. are we still on testing?

ag: yes and no. need to be able to determine if a technique is applicable or not to determine if it has passed or failed.

dmd: trying to link techniques to checklists?

ag: suggesting modification to technique to support creating of checklist.

dmd: not about navigation, it's about wording?

ag: it's only minor changes, most of the info is there.
... checklist is separate but needs to draw info from somewhere.

dmd: changes to techniques?

ag: extra content for each technique and perhaps reformulation of tests.
... if each technique had a testable statement, could discuss what tests are needed.
... for other technologies, will need to create test suites. by creating testable statemetns first, can scope out test suites.

dmd: like a traffic cop for checklists>

bc: it's more of a collection of info that we need about techniqeus before we can create checklists.

mc: ready for editos to begin making edits?

bc: discussed prototype for 1.1, since that's furthest along

js: want to raise the question about general techniques re: 1.1. those were the first ones i wrote, not sure how well they will map into this.
... if need me to, could rewrite, although have to bump something else to do.

dmd: i'm feeling a little lost. when was this discussed?

js: last week chris, alistair, and ben agreed to meet separately to discuss.

dmd: what are concept 1, 2, 3?

bc: how someone who wants to conform would build a checklist to determine conformance.

[figuring out how the first page would work, what the possibilities might be]

[keyword search]

ag: keywords would change depending on which technologies you chose

dmd: we predetermine the keywords. examples?

ag: forms, data table, etc.

dmd: this could be used both to build traffic cop and checklist

ag and bc: yes

dmd: would be good not to do the same thing twice

ben - did you discuss and/or relationships between tests and techniques?

ag: propose that we begin prototype for guideline 1.1 and see how this all falls together.

<scribe> ACTION: alistair, ben - prototype checklist for guideline 1.1

action 8 = alistair, ben, david, chris - prototype checklist for guideline 1.1

action items

mc: i've got action items from everyone (from last few meetings).

mc reminds everyone of their items

zaim, bye