See also: IRC log
bg: think we need to think about what we want
to include in script techniques for next WD
... propose we have 3 levels of scripting techniques 1) no scripting in
baseline; 2) scripts that can enhance access; 3) accessible scripting
<leasa> this sounds good
bg: difference between 2 and 3 are things that help accessibility vs. ways to write scripts acessibly
js: think that's 3 different approaches, but only 2 baselines
<leasa> we can add a cover note
<leasa> maybe that it is beeter not to have scripts in the baseline
<leasa> today
bg: agree, does seem like only 2 baselines
... leave accessible scripts out for the next WD?
js: leave placeholder and include some preliminary description of these techniques?
bg: do people agree we need all 3 categories?
ls: think it might make more sense to merge them - scripts that enhance accessibility should be part of both baselines
bg: so you're saying use scripts that enhance accessibility, but if they don't run, no harm is done
ls: yes, include them even if it's outside of baseline
js: in base baseline, where there is no support for client-side scripting, we might want to suggest use of server-side validation techniques
bc: javascript can be used even if not part of baseline (just not relied upon)
bg: think what we're saying is that anywhere we can, we include advice about script that degrades gracefully
ls: example of server-side validation as fallback - it's still good to also have client-side validation - don't want to reduce accessibility features just because a technology isn't in the baseline
mc: yes, these techniques would be optional in
the base baseline
... do we feel pretty confident on the baseline?
js: are we agreed that we're dealing with 2 baselines and 2 tracks within them or is it back to three?
[group agrees - 2 baselines - 2 tracks]
resolution: assume 2 baselines and 2 tracks for script techniques
mc: matt and becky, what do we need to do to script techinques?
mm: most of those things implicitly falls into
one of those categories - not a bright line between the two in some cases
... still have a list of bugs and issues against current draft to work
through
mc: are there additional techniques to be
proposed? want to have a good set of draft techniques for the face to
face.
... what other general decisions do we need to make about script techs?
bg: one thing is if we allow scripts in a baseline, do we still need to say don't use javascript URIs in hrefs?
mc: optional in baseline that includes scripts, but can't do it in the base baseline
bg: in some applications, you can't degrade gracefully
mc: might be good excercise to take script techniques and sort them into the two baselines
bg: we do need to go through to make sure that now that script can be part of a baseline, guidelines cover all the issues around what people might do with script
mm: suggest dividing on general techniques around scripting and "if javascript is required"
js: think we may have fundamenatally different
assumptions about accessibility practice
... may be a need to have a conversation about those two assumptions
mm: may not be as different as you think - talking about "unobtrusive javascript" in some cases, then other approach is where javascript is the only way to achieve certain functionality
bg: agree that it's important that we handle script techniques that way - here's how you use javascript and degrade gracefully - here's how you use it if you rely on javascript
<scribe> ACTION: becky and matt to review SC and identify script issues related to each baseline assumption [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action01]
js: what I had in mind was something like the
discussion we just had for scripting techs, but for the techniques documents
in general
... near-term goal is new draft of techniques at end of June, question is
what is most important to include in these new drafts
... one goal is to come as close as we can to a last call draft - more
specifically, we're aiming at giving web community a clear understadning
about what it is we're actually planning to do
... question is, what has to be in techniques documents to accomplish
that?
mc: this is in terms of content and not structure, right?
js: yes, primarily content
mc: example might be to include the techniques
proposed as a result of the issue summaries
... another one is let's really feel good about script techniques
dm: focus is on General, HTML, CSS and Script?
js: I have a question about general, but
certainly the other 3 (we haven't resolved relationship between general and
the guide)
... at f2f, one possibility was that the guide doc would replace general
techniques, another was that general does live as a separate document on par
with HTML and CSS. We've not had a real discussion on that and I think it
makes a difference about how we go about doing the work
<scribe> ACTION: john and david to make recommendation about how guide doc and general techniques relate [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action02]
wc: we talked about format of guide doc as an agenda item for the face to face - wondering if we should wait until F2F?
js: propose that we're in agreement about HTML, CSS and Scripting techniques and that the general techniques and guide doc need to be further addressed at the F2F
<scribe> ACTION: john to initiate additional work from subgroup on format of guide docs [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action03]
mc: there have been techniques issue reviews for guidelines which have resulted in various reccomendations, should we include them?
wc: think as much cleanup as we can do, the better - a lot of the reviews have been moving toward that
<Michael> resolution: Focus on HTML, CSS, Script techniques for next round of drafts
<Michael> resolution: Have at least placeholders for the techniques proposals arising out of guideline reviews
<scribe> ACTION: wendy look into time to create questionnaires [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action04]
dm: any resolution about how much baseline information is included yet?
mc: have been operating under the 3 baselines assumption for some time now
dm: does there need to be a recommendation on format?
wc: important to have a mock-up by the f2f - for guideline 1.1 work, I've been rewriting some techniques to include baseline info - would be helpful to have some mockups to discuss at f2f
dm: might want to do mockups while we do issue reviews
resolution: next techniques drafts will include baseline information
mc: need action items for people to create mockups
wc: part of what I was doing was looking at
initial information that MC, BG and BC generated
... part of what needs to happen in reviews is to look at that info and
addresss issues, suggest ways to address places where things don't match
up
<David> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0010.html
<Michael> ACTION: ben create mockup of baseline in techniques [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action05]
<scribe> ACTION: matt propose how to include baseline in scripting techniques [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action06]
mc: john yvette and I worked on 2.4
major thing is clarify dif betwn 1.4 & 2.3 because they both had structure techniques, 1.4 is structure for its own sake 2.4 is mostly navigation
mc: went over sc regarding that
... that delt with most techniques issues,
<wendy> Linear reading order of tables
js: resolution is that proposal to move this technique with the sc on reading order
<wendy> reading order SC may move from 2.4 to 1.3. this technique should move with that SC. there are issues. hold off discussion until know where it goes.
<Michael> #layouttables_linearize
<wendy> Link groups
<Michael> #linkgroups
js: we also refined sc on this
<Michael> #linkgroups_tabindex
<wendy> resolution: drop technique "tabindex to skip link groups (future)"
technique to skip groups needs work
<Michael> #linkgroups_skip
mc: keepers are skipping links and identiying link groups
bc: hide link groups makes no sense
wc: we are not making skip links visible
... on wai
<Michael> #linkgroups_hide
bc: should retitle task , hiding the spip link
wc: all of these should be the same
technique
... propose merging 3 techniques into one
bc: but hiding skip link is optional and skip link necessary to meet sc
wc: task is what maps to sc
js: let's put on agenda next week, is it promising enough to put into the f2f
<Michael> #link_structure
mc: zap that above
... hiding ASCII mapped repeating
<Michael> #asciiart
mc: need to do something with sc, put in 1.1 not 2.4, it's wendy's problem
<Michael> #frame-title
mc: issue 1117,i don't think the comment is
confusing,
... test cases have to be worked on as well
... the problem is title attribute has different reasons for use
... at best optional
wc: I have question relating to 1.1, comment is some titles needed my concern, when we use an image in a link, is that 1.1
js: I don't think of frames as non text content
bc: its a box around text
wc: i'm confused because I run into stuf that is in 1.3, 2.4 etc....made me question other things in 1.1
s/2w/wc
js: do we need this techniques
mc: it's in 1.0 and useful to have it there to know that we dropped it
<Michael> #frame-longdesc
wc: do we need a separate appendix, of has been techniques
js: propose that we not recommend this tachnique and propose an appendix of dead techniques
bc: what about reapair techniuqes many reasons to deprecate things
<wendy> two appendicies: 1. fallback/repair - still using although not happy about 2. deprecated - don't need to do anymore/don't recommend
js: distinction between reapair and fully dead techniques
<wendy> http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#fallback-techniques
mc: tab order in forms
js: still need it
mc: need to remap
<wendy> ACTION: michael create 2nd appendix for deprecated techniques and move deprecated techs there. [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action07]
mc: access key
<wendy> ACTION: someone write rationale for each deprecated technique to explain why deprecating. [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action08]
mc: tab spaces,
... don't think you can do that. just one tab space
bc: if in forms, links mode virtual tab space
mc: quick decision not possible
<Michael> #form_tabindex
wc: tab order important but don't use tabindex
mc: if technique is kept it needs work
links sparation, character between links
bc: now we';ve go authors looking in various places for similar information
<Michael> #separate-links
mc: flag it
flag it applies to separation between links
wc: links to gl 1.3
<wendy> #css-fallback - maps to baseline and/or 1.3
mc: defn of technology and technique
js: recommend we adopt same defn of tehnology ---consistent defn across wcag docs
bc: we don't have a defn appendix, do we link to gl or make our own
js: let's link to theirs
bc: we may need to define words later as tech
docs evolve
... could write xslt that pulls from GL
js: can we add to that?
wc: in 1.0 if term used in technique doc we compied it
js: makes sense
<wendy> resolution: if a term that is defined in wcag 2.0 is used in a techniques document, that definition is copied into the techniques glossary. definitions that are unique to techs docs are defined in techs docs.
<wendy> ACTION: ben generate glossaries in techs documents [recorded in http://www.w3.org/2005/05/25-wai-wcag-minutes.html#action09]
<wendy> resolution: define "technique" as "a method or body of methods that may be used to satisfy the success criteria defined in WCAG 2.0"