<Becky_Gibson> scribe: becky

<Becky_Gibson> MC: gen info about tests - should not assume that these are meant for automated test tools

<Becky_Gibson> cr: agree - these are not necessarily for machines - some can't be tested by machines; most are meant for people to apply

<Becky_Gibson> mc: gregg has never been 100% clear with test suite - just want to make sure we are all on the same page

<Becky_Gibson> mc: on to the test review

<Becky_Gibson> mc: Ken's review of #24 - text equiv for applets must be updated if applet changes

<Becky_Gibson> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0392.html

<Becky_Gibson> mc: suggested beefing up the description

<Becky_Gibson> js: thought he meant the applet

<Becky_Gibson> cr: problem is the gL don't req. that programmatic objects are not req. to have text equiv

<Becky_Gibson> bc: applets are excluded from having non-text content

<Becky_Gibson> js: no SC under 1.3 that are related

<Becky_Gibson> js: reminded that one of problems with this test is that current def. of non-text content excludes programmatic objects

<Becky_Gibson> js: so no place for this test to map to

<Becky_Gibson> mc: so can't resolve this test until gl issue with non-text content gets resolved

<Becky_Gibson> bc: but Ken raises good point- how to know that the applet has changed?

<Becky_Gibson> bc: if make a change, have to refresh page - which brings user back to top of page - which is bad for screen readers

<Becky_Gibson> ls: what about a date or seconding changing widget -would that be included?

<Becky_Gibson> cr: should this test be that applets must have test equiv.

<Becky_Gibson> bc: can't make that decision yet - have to resolve gl issue about text equiv for programmatic objects

<Becky_Gibson> cr: this test should go back to earlier state becuz of outstanding issues

<Becky_Gibson> cr: move it back to new state?

<Becky_Gibson> cr: until resolve applet text-equiv. issue in larger group

<Becky_Gibson> ag: java not has an accessible api - can't java applet itself hold the alternative?

<Becky_Gibson> bc: that is basically what the debate it abt. competent UA should be able to access accessible api and get that info

<Becky_Gibson> ag: moving into territory of "until user agent"

<Becky_Gibson> js: 2 different kinds of text alternavites: alt attribute ( which object doesn't have) is spoken by screen reader even tho

<Becky_Gibson> UA can access the item alt is associated with (like image)

<Becky_Gibson> js: one type is label the other is a substitute (spoken when UA can't handle the associated item)

<Becky_Gibson> js: need to distinguish between the too

<Becky_Gibson> bc: for applet can use alt attribute

<Becky_Gibson> bc: applet is deprecated

<Becky_Gibson> mc: is deprecated but not removed; level 1 allows using deprecated elemetns

<Becky_Gibson> bc: yes - catch all as long as it is documented

<Becky_Gibson> dm: can put applet in object

<Becky_Gibson> mc: but no alt attrib on object

<Becky_Gibson> dm: is applet used alot?

<Becky_Gibson> mc: yes used alot- even for stupid reasons - like in place of an applet

<Becky_Gibson> js: used often in education space

<Becky_Gibson> dm: is applet tag still used or have people migrated to object?

<Becky_Gibson> mc: applet tag is still used

<Becky_Gibson> mc: what is proposal for this test? put on hold or poll whole group

<Becky_Gibson> bc: propose reject because we likely won't require checking for change in applet

<Becky_Gibson> bc: impractical to update alt attribute when applet changes

<Becky_Gibson> mc: test 24 -reject

<Michael> scribe: David

bg: propose #168 make optional a good thing to do, but should not be forced to group

js: at least for radio buttons, fieldset and legend are necessary

bg: but puts a border

js: use css:

bg: we should put that in a technque

mc: we'll need legend tests

bg: I submitted example

ag: some of this stuff kicks back to techniques

mc: yup there are actions about that

<Michael> ACTION: Chris make test 168 required for radio buttons only

<Michael> ACTION: Chris create optional tests for fieldset for non-radio controls

<Michael> ACTION: Chris create LEGEND quality tests

<Michael> ACTION: John create general techniques about grouping form controls with emphasis on radio buttons

<Michael> ACTION: Michael modify technique #fieldset to match test changes

<Michael> action 2 = Chris put optional tests for non-radio buttons in the holding bin (don't create tests yet)

<Michael> ACTION: Chris reject test 24

#163

bc: let's reject it, issue no lger on radar

mc: do we have reverse test because it is an anti-technique

bc: can't do that

bg: above said let's zap it

<Michael> ACTION: Chris reject test 63

#92

bg: needs work, because there is no "auto-submit"...change to select item not lead to extremem changes in content...but that is very hard to test...

<Michael> Guideline: http://www.w3.org/TR/2004/WD-WCAG20-20041119/#consistent-behavior-unpredictable-change

bg: I've made alternative test

mc: that's good,

I've attached an example that works with a screen reader

generall agreement

I'm always a good boy

<Michael> ACTION: Chris modify test 92 per Becky's suggestions

<Michael> ACTION: Michael modify technique #autosubmit per Becky's suggestions

<scribe> scribe: becky

:-)

<Becky_Gibson> :-)

<Becky_Gibson> mc: discuss test about language on the body tag

<Becky_Gibson> cr: test #49 requires lang attribute on HTML elem

<Becky_Gibson> cr: yvette asked if lang on body attritbute is enough

<Becky_Gibson> cr: determined that it must be on the HTML element (via post to list)

<Becky_Gibson> cr: lang attribute on body is not good enough

<Becky_Gibson> mc: so no additional action for test 49

<Becky_Gibson> cr: will respond to Yvette

<Becky_Gibson> mc: test 143 - doc must have address for author

<Becky_Gibson> mc: have discussed removing this technique - not fully agreed yet

<Becky_Gibson> mc: suggest removing tech - no one has come up with an accessibility reason for including address element

<Becky_Gibson> group: kill that technique and thus the test

<Michael> ACTION: Michael remove technique #address

<Becky_Gibson> cr: test 144 also gets rejected

<Michael> ACTION: Chris remove test 143 and 144

<Becky_Gibson> cr: if not requiring name can't req. that it be valid

<Becky_Gibson> mc: test 97 and 109 - doc must be readable when style sheets removed

<Becky_Gibson> mc: propose accept 97 and 109 and create new test for style element

<Becky_Gibson> bc: why do both tests have same title?

<Becky_Gibson> mc: need to differentiate titles - one refers to linked styles and other refers to style attribute

<Becky_Gibson> ag: issue with tying elements together - why is this not a css test?

<Becky_Gibson> mc: html document is loading css and we want it to be readable in absence of css

<Becky_Gibson> js: gen. issue with our use of the word document

<Becky_Gibson> js: rest of GL deals with delivery units

<Becky_Gibson> js: Alistair has pointed out that we need to get more consistency in document vocabulary

<Becky_Gibson> bc: GL has replaced document with contents

<Becky_Gibson> cr: propose replace document with content in the test

<Michael> ACTION: Chris replace "document" with "content" in test 97 and 109

<Becky_Gibson> ag: just want to see more separation - concerns about associating html and css together in html techs document

<Becky_Gibson> bc: does seem like this is a css test; if you have not specified css in you checklist why would you want ot see this test

<Becky_Gibson> ls: use of style is conforming to our GL - you are separating structure from style

<Becky_Gibson> ls: how does use of css violate GL

<Becky_Gibson> mc: there are ways you can use css that will change the meaning of the content or css can generate content

<Becky_Gibson> mc: which can cause problems

<Becky_Gibson> ls: not convinced - have lost meaning if the spec. that you are depending upon doesn't pass gl

<Becky_Gibson> js: reading order GL is one example

<Becky_Gibson> js: someone can dump content in page in random order and then use css to visually align the content on the screen

<Becky_Gibson> js: but screen reader or UA that doesn't support css will see/hear content in page (random) order

<Becky_Gibson> ls: not disagreeing - but there are ways to interpret the css to figure out the reading order

<Becky_Gibson> bg: see this as similar to Javascript issue

<Becky_Gibson> bc: one of principals of css is that it can be removed without affecting the document

<Becky_Gibson> js: how does this relate to reading order?

<Becky_Gibson> bc: spec doesn't address issue of removing but core principles of css address this

<Becky_Gibson> js: so really a 4.1 (use the tech. according to spec) GL issue

<Becky_Gibson> bg: css can be used to make things more accessible (showing focus)

<Becky_Gibson> bc: perhaps need to make the same assumption about css as about JS

<Becky_Gibson> bc: css is designed to be turned off - but when scripting enters equation then you have to

<Becky_Gibson> bc: assume functionalit will be turned off

<Becky_Gibson> bc: so this test ok for css but not for scripting

<Becky_Gibson> mc: within DHTML context perhaps css with script is different than just js or just css

<Becky_Gibson> ag: html tech this test is releated to: use css to specify styling

<Becky_Gibson> ag: perhaps should be don't use html presentational markup rather than mentioning css directly

<Becky_Gibson> mc: agree - another styling lang. could come up which might be more desirable

<Becky_Gibson> ls: main problem is does the tech. work with screen readers vs. can it work with screen readers

<Becky_Gibson> ls: discrepancy with way checkpoints are writtng

<Becky_Gibson> written

<AliG> AG Change 13.1 Task from "Use CSS, not HTML, to style documents." to "Avoid presentational HTML markup".

<Michael> ACTION: Michael Change 13.1 Task from "Use CSS, not HTML, to style documents." to "Avoid presentational HTML markup".

<Becky_Gibson> bc: need to capture that not changing the reading order needs to get captured in the tests somewhere

<Becky_Gibson> mc: if is fallback tech then we aren't going to do tests for it

<Becky_Gibson> bc: how would it be fallback tech?

<Becky_Gibson> mc: is a css tech

<Becky_Gibson> ag: agree that it should be css tech: make sure any content css is being used to style does not change its reading order

<Michael> ACTION: Wendy create a CSS technique for page displaying ok when CSS not supported

<Michael> ACTION: Chris move test 97 and 109 into the hypothetical CSS test suite

<Becky_Gibson> mc: move #97 and #109 "CSS test suite" which doesn't yet exist

<Becky_Gibson> mc: we're BACK!

<Becky_Gibson> mc: test 64 already accepted - keep it

<Becky_Gibson> mc: test 66 - by adding all the specific file extentions we limit ourselves

<Becky_Gibson> mc: test doesn't have specific pass condition

<Becky_Gibson> mc: pass was that there were no sound files rather than there are sound files with correct transcripts

<Becky_Gibson> cr: there are other tests the deal with sound files - how to handle that

<Becky_Gibson> mc: this issue affects those as well

<Becky_Gibson> cr: what is the suggestion?

<Becky_Gibson> mc: not sure what to do with sound file sufixes

<Becky_Gibson> mc: can be provide an 'example' list of sound file extensions - leave it up to tester to understand what files are sound files

<Becky_Gibson> bc: should the exmaple file play a sound? the examples don't always have the situation we are testing for

<Becky_Gibson> mc: do we need to make all the examples actually exist? for example sound files and image files

<Becky_Gibson> bc: this test file doesn't seem like a logical way to include sound files

<Becky_Gibson> bc: tried to run the test file to see if it made sense but that didn't work

<Becky_Gibson> bc: are there other tests - like anchor link to a sound file; also one for embed or bg sound

<Becky_Gibson> bc: consolidate them all - any direct links to sound files include text transcript

<Becky_Gibson> cr: would like to keep them separate at test suite level

<Becky_Gibson> cr: test files need to be fixed up so have good examples

<Becky_Gibson> cr: need a change to list of suffixes so marked as "example" list and not exhaustive

<Becky_Gibson> mc: agree that we want to make "real" files exist

<Michael> ACTION: Chris make sound files, images, etc. in the test files exist so the links are real

<Michael> ACTION: modify test 66 to say file extensions are just a sample list, and provide example for actual link to text transcript

<Michael> action 17 = Chris modify test 66 to say file extensions are just a sample list, and provide example for actual link to text transcript and do this to the other sound file tests

<Becky_Gibson> bc: does that mean we are consolidating the test with one fail example and a list of extensions

<Becky_Gibson> bc: don't want Chris to have to create examples for each known sound file type!

<Becky_Gibson> mc: right just one working example with reference that it is an example and applies to other sound types as well

<Becky_Gibson> mc: test #194 - already accepted

<Becky_Gibson> mc: just need to update the pre-req

<Michael> ACTION: Chris update prerequisite test for 194

<Becky_Gibson> ag: general comment: take out the prereq. test on each test file and insert that into the checklist

<Becky_Gibson> mc: sounds like a bigger discussion

<Becky_Gibson> cr: think having pre-req tests in there is usefule

<Becky_Gibson> mc: pre-req is useful -

<Becky_Gibson> bc: but agree that that logic is going to also be exposed in the checklist

<Becky_Gibson> bc: right now pre-req are only pointing to html things

<Becky_Gibson> ja: don't think we should remove from test files

<Becky_Gibson> mc: we can deal with the issue in checklists as well

<Becky_Gibson> ag: but are building in addn bits and pieces

<Becky_Gibson> ag: might have a test that you run separately to support something that you aren't useing

<Becky_Gibson> ag: (scribe correction) might run one test separately and not understand the pre-req test because it relates to something

<Becky_Gibson> ag: that you aren't using

<Becky_Gibson> cr: seems like it needs more discussion

<Becky_Gibson> mc: perhaps an agenda item for another meeting

<Becky_Gibson> mc: are we okay with #194?

<Becky_Gibson> cr: still discussion around word decorative - but think it will do for now

<Becky_Gibson> mc: test 68 - area should not open new window without warning

<Becky_Gibson> mc: we don't say what warning is - that is a fault of the technique

<Becky_Gibson> mc: have discussed various warning formats in the pages - text in the link, in the title, near the link or in the doc

<Becky_Gibson> mc: but never agree on which are acceptable

<Becky_Gibson> mc: can't do anything with test until resolve

<Becky_Gibson> bc: but don't have too many options for area

<Becky_Gibson> mc: in the alt, in the text surrounding, and in the document

<Michael> ACTION: open issue about appropriate warning for new windows, re technique #links_popup

<Becky_Gibson> cr: Michael to figure out what warning is and let this test sit for a bit

<Becky_Gibson> mc: test #65 alt text for all area elements .......

<Becky_Gibson> mc: already accepted so keep that decision

<Becky_Gibson> mc: other issues - link text does not begin with link to or go to

<Becky_Gibson> mc: length of alt text

<Becky_Gibson> group: too late to get into these now - put first on next week's agenda

<Becky_Gibson> mc: tests reviewed by Tim

<Becky_Gibson> mc: list items not used to format text - #70

<Becky_Gibson> cr: text from this text was incorrect

<Becky_Gibson> bc: seems like tim reviewed #69

<Becky_Gibson> bg: what is accessibility of maquee?

<Becky_Gibson> bc: moving text - timed text GL

<Becky_Gibson> cr: put 2.2 level2 SC 2

<Becky_Gibson> cr: put under GL 2.2 level 2 SC2

<Becky_Gibson> bg: asks lisa - are there any helpful uses of marquee?

<Becky_Gibson> ls: can't think of any - can think of disadvantages

<Becky_Gibson> ls: concern with the way the checkpoint is written - if you are conforming to spec. then what are you violating?

<Becky_Gibson> ls: how does this relate to process we are creating

<Becky_Gibson> cr: spec doesn't require alt attribute on images but we are requiring one

<Becky_Gibson> bc: ironically enough - all images must have alt gets superceded by checking to alternative on non text content

<Becky_Gibson> cr: tests are meant to be practical and usable

<Becky_Gibson> bc: is marquee caught by validator?

<Becky_Gibson> mc: yes, HTML WG is blind to its existence

<Becky_Gibson> dm: if we don't want it used we have to say that

<Becky_Gibson> bc: is there a css tech about blink or marquee?

<Becky_Gibson> mc: no marquee equiv

<Becky_Gibson> bg: not all browsers support turning text-decoration:blink off via JS

<Becky_Gibson> mc: so keep marquee test?

<Becky_Gibson> ls: but we don't really need it

<Becky_Gibson> mc: important to keep and explain why just checking for validation is not enough

<Becky_Gibson> ls: prefer using this tag rather than JS - since it is easier to reformat when the tag is used

<Becky_Gibson> cr: so is it ready for a straw poll?

<Becky_Gibson> mc: inclined to keep it

<Becky_Gibson> bc: fine with keeping it

<Becky_Gibson> mc: would be helpful for tim to be here to dicsuss his review

<Becky_Gibson> ja: will have my review done by next week

<Becky_Gibson> mc: next week agenda is already busy

<Becky_Gibson> mc: review thorny alt text issues

<Becky_Gibson> mc: discuss checklists

<Becky_Gibson> mc: continue with test review

<Becky_Gibson> mc: next week is last week before Face 2 Face

<Becky_Gibson> mc: no meeting on 3/2 (due to Tech plenaries)

<Becky_Gibson> mc: likely no meeting the week of CSUN

<Michael> I have made the request to generate http://www.w3.org/2005/02/16-wai-wcag-minutes Michael

<ben> I have made the request to generate http://www.w3.org/2005/02/16-wai-wcag-minutes ben

<ben> RRSAgent format minutes

<ben> I have made the request to generate http://www.w3.org/2005/02/16-wai-wcag-minutes ben

This is scribe.perl Revision: 1.111  of Date: 2005/02/12 19:57:54  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: becky
Found Scribe: David
Inferring ScribeNick: David
Found Scribe: becky
Scribes: becky, David

WARNING: No "Topic:" lines found.

Default Present: [Microsoft], Ben, Michael_Cooper, Jenae_Andershonis, Chris, John_Slatin, Alistair_Garrison, David_MacDonald, Becky_Gibson, Don_Evans, Lisa_Seeman
Present: [Microsoft] Ben Michael_Cooper Jenae_Andershonis Chris John_Slatin Alistair_Garrison David_MacDonald Becky_Gibson Don_Evans Lisa_Seeman

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 13.1 66 change chris css fieldset from html john michael modify not open task technique test use wendy

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)