WCAG Techniques Task Force Weekly Telecon

Review requirements

http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050503.html

mc: talked about this a couple weeks ago and made a few changes - not all the way there, but getting closer
... may need to make this a F2F topic

tb: intro talks about technology and techniques, but neither term is defined. should we provide a definition of what a technique is?
... technique maps to a SC. "maps" isn't a very strong word, may not be clear that a tech satisfies a SC
... so definition of technique in that context might be important

mc: also relates to added definitions for sufficient, optional and not recommended

bc: a tech doesn't always satisfy a SC, may be multiple techniques

michael reads definition of sufficient

tb: may also need definition for technologies
... is there a template for a technique?

mc: yes, techniques DTD and the other is a web form people can use to submit proposed techniques

tb: is a "task" a testable statement?

mc: we defined testable statement for test cases, but not for techniques/tasks - maybe we should
... in this draft, added definitions of sufficient, optional, not recommended, positive/negative test cases
... added a little bit about baseline

but still need to expand on that

bc: guide doc? does that fit in WCAG 2 requirements or here - seems to be some overlap

mc: do we know if guide doc and general techniques will be seperate?

bc: no decision, but drafts we did when combined were very long

dm: seem like two different issues

mc: so you're saying we need to create reqs for guide doc and figure out where to put them?

bc: yes

mc: think it makes sense to put them in requirements for those in WCAG 2 reqs
... one thing we have to be careful of is if we consider guide doc optional, we wouldn't have it in requirements, if essential, it would. my understanding is that the guide doc is currently considered to be essential

tb: ... in authoring tools, have been some questions about who reviews and approves techniques

mc: haven't said anything about who authorizes techniques or what our process for reviewing them is yet

dm: I think what we're saying is that we've tested the techs we've written and if you want to do something else, that's fine, but w3c published techs should be higher quality

mc: in principle, any technique to conform to WCAG is a WCAG technique
... I think though, that we suggest that other people developing techniques work to a similar set of reqs, but we have no authority to do anything beyond suggest that
... sounds like we've got some other issues on our plate, does that answer the question?
... issues I captured were added def for technique and technology, clarification on relationship of techs to SC, a question about testable statements for techniques, impact of baseline and reqs. for guide doc

were there other issues?

bc: checklists section needs rework based on simplification of checklists we're heading toward

tb: contradictions around technique for each success criterion and checklists that address each SC?

mc: do people agree we should add a definition for technique and technology?

<scribe> ACTION: tim to work on proposals for these definitions

dm: have we resolved the issue around mapping techs to SC vs. more general guidelines?

mc: have been operating under the assumption that they should map to SC

bg: agree

dm: sometimes difficult to map

mc: so far, when we've had issues mapping, there hasn't been a priliferation of SC in the guidelines. think mapping is a useful tool to encourage WG to solidify SC.

dm: does highlight how some of our techs are disengaged from the guidelines

mc: relates to whole end to end thing we did a year ago - are you wanting us to leave this as an open issue?

dm: not entirely sure we'll be able to map each technique to a SC successfully, but would like it to

<scribe> ACTION: michael - include an ednote about whether techs can map to more general guidelines and principles

mc: about relationship to meeting SC, I did add some info about AND and OR under the "relation to WCAG 2.0" section

reads bullets 2 and 3 at http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050503.html#relations-to-gl

bg: haven't been doing this yet

mc: does that address the issue Tim raised?

tb: my issue was that the technique convey info about how the employment of a tech would satisfy the SC -- that could be made clearer

mc: maybe something about "meet the reqs of a SC"

tb: for example, how does use of a technique accomplish programmatic relationships in content?

mc: propose that tim and I work on a proposal to address

<scribe> ACTION: tim and michael to work on a proposal to make it clearer how a technique satisfies a SC

mc: testable statements for techniques - thoughts?
... my own view is that techniques should be testable, but test files are more amenable to testable statements
... not sure how to make a testable statement for technques that isn't the union of our existing techniques and test cases

bc: at one point, we talked about techniques titles/tasks as true false statements, does that address this?

cr: didn't we decide to leave the testable statements to tests?

bg: if you add testable statements to techs, you have to do lots of "if you do this" and "if you have that" kind of stuff - difficult to word

mc: not sure, leaning toward leaving testable statements to tests, but you're right that there are issues

tb: have to have some way to identify that a technique has been completed

mc: now, we've got tests, which make techniques testable, which make the guidelines testable
... testable doesn't have to mean testable on code inspection - think outcome testing can be valid and in script techs, that may be more appropriate than in others

dm: reason a task was there in the first place was to make it testable - is that right?

tb: I think that's the correct sense

<scribe> scribe: David

dm: task has been an annoying thing because it is redundant. We could fix the title and dump the task

test

bc: said the above, let's strike the task and fix the title

cr: so the title would be the technique???

<Michael> ACTION: editors remove <short-name> from technique and make technique title what is now <task>, remove that element altogether

cr: fix above so the title would be the task???

bc: ie using orderedl list in HTML, the techniques ould describe that

mc: good idea but we need to deal with the tesable statement issue
... do we want to declare a testable statement?

cr: I'm wondering could we combine the techniques test cases, and map,, like a big data base, put them all together in one document??

mc: othing preventing us to do that, xml allows that possibility, and our id's allow that

cr: output format, not input

mc: should not be a requirement but we can easily do that, ugly but beautiful
... baseline, propose we put it off to the face to face

bc: baseline is a good tart and we can cross reference it

mc: propose yes we need requiremtns and they belong a WCAG level so let's propose to working group

bc: wording implies we would find it there

mc: can ben post a short email to group on that

bc: sure

<Michael> ACTION: ben talk with editors about req for guide doc in WCAG req

mc: checklist, neet to rework checklist, how to go about it????

bc: maybe not too much work, because checklist are SC. we would just describe that
... I can take a stab at that

<Michael> ACTION: ben propose updated checklists section of requirements

mc: Checklists must meet all SC, but Techniques only meet SC possible in tech ? need to harmonize

<Michael> ACTION: michael clarify techniques for some sc but checklists must meet all sc

Begin planning FtF, possibly breaking up to work on issues

mc: f2f planning. meeting in brussels, week of june 13-16
... who can make it? Becky, Ben in, David and Chris out

Christophe_Strobb will be there, john, Yvette (perhaps) Wendy

<Christophe_Strobb> Christophe Strobbe

mc: need to nail down requirements in f2f, baseline impact, tie it all together at f2f, issue summarries for any guidelines not covered
... want good draft of html, css and script,

dm: does css, html go together.

mc: will put it on agenda

mc: what are we going to do to make the f2f task focues

dm: gt lots of homework beforehand

mc: yup, need to get a lot of homework done
... people at home should have hwk done too
... people at home do clear homework
... does breakup subgroups of 2 make sense?

dm: yup

mc: task groups should cross fertilize not do stuff that can be done by email or phone

bg: andi will probably be there

mc: might see Takayuki?

Continue review of 1.1, 2.4, 4.2

mc: let's dive into 1.3, the agenda say 1.1 that's a typo

<ben> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0360.html

dm: 4.2 issues summary - GL is state of flux; additional meetings ongoing with other WG members
... not many open issues
... looked at techniques mapping

bc: mapping doc just pulls info from the techs themselves

dm: doesn't think 12.10 is mapped correctly
... interpretted mapping incorrectly - David read as 12.1 but it really is 12.10 - so mapping IS correct
... 12.5 frame sources - doesn't think that applies to 4.2 since doesn't think of frames as programmatic objects

bm: reason for map was probably due to using technologies access features

bc: (prev. comment by bc also) has to do with putting just an image in a frame

mc: if link frame directly to image there is no way to provide alt text -
... can see why progammatic object is confusing - really interested in objects without access. features

dm: didn't make that distinction - was really thinking about programmatic object; think of 4.2 dealing with non HTML techs

bc: there is no UAAG compliant UA that deals with images only

dm: wording of programmatic object implies one thing; frames seems like a broken part of HTML

mc: images can be thought of as non HTML; but WCAG2.0 is trying to be non tech specific

bc: suggest map 14.5 to GL 1.1 rather than 4.2

mc: back to 12.10 - this is really baseline related

dm: will a web page be more accessible if we leave this tech. out? (not providing link to access. viewer)

mc: with the link might be more likely to take advantage of access. I generally won't download something in order to view a document

dm: so, do we need to dump tech 12.10 becuz of where we are going with our baseline - we are assuming the user has the techch
... do other standards have this req. other than 508?

mc: think it is picked up on inconsistently

dm: for my website if people give me a pdf to post I will also add a link to download pdf viewer

mc: seems like every Canadian govt. has that link to download pdf reader

dm: propose removing tech. 12.10
... thinks 12.2 maps to 4.2
... as tech not supported tech it depends on baseline outcome

<ben> ACTION: editors map HTML 14.5 to guideline 1.1

dm: suggest remove the editiorial note from 12.2

mc: baseline says that for set of techs in the baseline access features are already supported- thus don't need a fallback
... for techs outside of the baseline need to provide fallbacks under GL 1.1

dm: everything has to be avail in text

mc: only if outside of baseline

dm: but has to be text for everything?

mc: think Wendy is addressing this issue - don't think we are forcing text only
... ex: if flash is in baseline and you've made the flash access we don't req. text alternative
... say java outside baseling and flash in baseline - have to have a fallback for the java object but the fallback could be flash since it IS in the baseline

dm: still concerned about people creating an unreasonable baseline

bc: that is why we need to provide guidance on reasonable baseline and assume policy makers will enforce
... think 12.2 could go away entirely but might need new techniques to cover for specific baselines

dm: can agree to remove the technique

bg: rec. is to remove 12.2??

mc: 1.1 plus baseline seems to clarify 12.2 so perhaps it can go

dm: have to think of interplay of what people will actually do and what we think they will do

mc: propose remapping 12.2 to 1.1 to force us to address this during 1.1 disussion

<ben> ACTION: editors map HTML 12.2 to guideline 1.1

dm: 12.3 alt content for programmatic content - suggest deleting it since covered by tech 12.4

mc: seems it has already been remapped to 1.1 in Feb. 11 draft
... so probably need to update the mapping
... have issues with these techs beyond where they belong

dm: thought the whole section 12 should be mapped to 4.2
... fail to see distinction between 12.3 and 12.4

mc: I think bc analyzed how 12.4 was supposed to work and that text in object element is not a valid tech
... so maybe 12.4 needs to be removed and 12.3 reworked

dm: suggest dlink tech as repair tech for 12.4
... but dlink usage has sort of flopped - people don't understand what it is

mc: take dm comments about 12.4 and apply to 12.3 and remove 12.4
... someone posted to list about object content being a fallback when object tech. not support - not as an alternative

bc: somewhat ambiguous in HTML spec - issues with alternatives
... AT's should be smart enough to query for alternative info regardless of techs installed

mc: problem is that IE doesn't preserve that text for an object in the DOM - most ATs are built to support IE

bc: aren't AT's looking at the source code?

mc: no, IE based ATs are looking at the DOM and text for object isn't in the DOM
... may have media player present even if you can't perceive it - need to be able to deal with the object as if player is not available

dm: very frustrating to have to still rely on dlinks or other older techs
... maybe we should say "until user agents..." <giggle>

mc: perhaps address through baseline
... best tech is text desciption outside of <object> tag but in same HTML doc

dm: I don't care if it is in another doc - just don't like the title "dlink" - people don't know that that means

mc: if I see a dlink I know site is "accessibility nerd" site

dm: no one really knows what dlink is (except WCAG WG people)

mc: dm to turn this dicussion into proposal

dm: suggest deprecate 12.5 and 12.6

mc: that is baseline dependent

<ben> ACTION: david to turn discussions on 4.2 techs issues into proposals

dm: 12.7-12.9 are all embed techniques so will leave them in

mc: will be not recommended in "future" baseline

dm: don't see any css techs for 4.2
... css techs 5.5, 1.1, 1.2 and 5.2 are currently mapped to 4.2 but don't think they should be

bg, bc, mc: don't see these as a good mapping either

mc: perhaps wc used 4.2 as default mapping
... where would we map these CSS techs?

<ben> ACTION: editors remove mappings from CSS techniques that map to guideline 4.2

dm: do we want to continue to suggest relative font sizes?

mc: yes although it shouldn't be req. in future baseline

dm: javascript 2.1 - this is an anti tech

mc: suggest keep in "graphical" baseline

dm: 2.2 dynamic content generation

mc: 2.1 is Javascript URIs - 2.2 is docuemnt.write and innerHTML
... thinks there is a way to do this in the present day baseline - so need a tech for that

bg: but can't use document.write in XHTML

mc: so should separate document.write from innerHTML

bg: is innerHTML a DOM API or IE only?

mc: thinks it is a JS type implementation

bg: correction to minutes- JS tech 2.1 applies to "base" baseline not "graphical" baseline as prev. recorded