See also: IRC log
discussion - how much code should we include in scripting techniques? didn't seem to be a lot of support for david's proposal, although not much discussion on the list.
becky is working on an example that should be out today.
seems to be consensus that examples are good. clarify that "these are examples, not the only way it can be done."
for scripting, write functional outcomes that tie back to success criteria.
want to find a way forward to keep scripting at high priority since "selling point" for wcag 2.0 (addresses web apps).
<Becky> http://www.quirksmode.org/dom/error.html
re: functional outcomes - a menu should be operable by keyboard (2.4), all items should be read (1.1), items in appropriate order (x.y)
discussion about providing techniques that only work in firefox 1.5 and ie 6 - advanced accessibility, but concerns that usable by small audience (future techniques).
if we do include future techniques, need to set expectations correctly.
going back to idea about "functional outcomes" - even if not providing complete techniques/worked examples, need some snippets of the pieces that we know how to do.
e.g., various ways of providing menus.
<scribe> ACTION: becky start discussion of javascript url protocol on the list [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action01]
resolution: scripting techniques assume basic level of javascript understanding and do not try to teach the basics of javascript.
prioritize on those things that are most frequently asked about. maybe if we cover only the top 5 - 10 issues/questions, we're 80% or more of the way to Last Call.
where we know things are broken address, even if we don't know the answers, maybe encourage someone else to do so.
resolution: we will include code in scripting techniques
top priorities for scripting:
drop down menus - http://www.brothercake.com/dropdown/
form validation
show/hide
list at http://www.webaim.org/techniques/javascript/
focus - setting it automatically either in form control when page load, or auto move when fill it out
focus - moving to a non-form element (e.g., have a left menu that's javscript, moving focus to right navigation panel. ala in an email product)
understanding when content has changed
and can get to the change
difference between visual focus and screenr eader focus
complete keyboard and mouse support - e.g., can open a menu w/a keybaord, as soon as tab "into" it closes b/c menu item no longer receiving focus
pop-ups
some discussion on list re: help text
relates to "knowing content is there" issue
<scribe> ACTION: wendy add this list to plan for scripting techniques [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action02]
if javascript not in baseline, refer to html techniques (note instead of grid)?
when using complex javascript on other technologies (e.g., svg 1.2 - input on a set of lines and turn into an editing field), lack of semantics.
is "relies upon" necessary? need "usable without"
discuss how to categorize techs for each technology
"not applicable"
which was primary related to CSS
"works in"
e.g., this tech only works if the following techs are in your baseline
instead of table, simplify to 2 bullets?
1. if script in baseline, sufficient for SCx
2. if not, refer to technique xyz
javascript available and enabled...
javascript available and disabled...optional technique...
is enabled part of baseline assumption?
if not technique to refer to, state that
or "requires server-side valiation"
title: baseline implications
<scribe> ACTION: becky include this idea in upcoming mock-up [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action03]
add to agenda for next week - 2 issues re: becy's proposal 1. baseline 2. testing
skipping since tim's not here
andrew disagreed: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0330.html
some agreement with andrew's statement, it's a user agent repair test
modify test - ok to do as long a have for and id?
a test associated with a repair technique?
move existing html tech into "repair" category
test 57 allows implicit association
this test contradicts 57
add it as a UA issue? include it at the technique level?
current html techs, "don't use label implicitly" and is marked as deprecated.
intention, this tech to be deprecated. now saying it's ok, as long as use for and id. therefore, both tech and test case need to be fixed.
can do this w/out for and id?
just put input in label?
some user agents have a problem with that
test 186 - label can contain input but also have for and id?
should be a repair technique that explains the user agent problems
tech 15.2 (30 june 2005 draft) - move to repair techs. reference using for/id as solution.
the practice is valid html (label in input). issue is that screen readers don't always recognize.
remove test 186?
then in 57 - say ok, but not recommended?
<scribe> ACTION: chris review discussion on test 57, make proposal re: 57 and 186 [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action04]
<scribe> ACTION: michael make edit and send w/rest of proposed revised structure of html techs [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action05]
test 187 - david suggested to keep it
some push back on the list
andrew said it's a valid technique
lisa had questions
related to "required" mark - way to associate that w/form control
while ago, proposal for "no more than one label per control" not in the current draft. believe that we rejected the technique. therefore, reject the test?
as long as it's legal html, no reason to limit?
testing showed it was legal, unpredictable about which label "you get" (read by screen reader?)
<Christophe> it's legal: www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#edef-LABEL
"forms mode" in general, seems to be an issue. only get info from labels and inputs, no other info (issue we've seen w/wbs forms)
resolution: reject test 187
test 188, test 189
test 189 - similar issues to 187
?
concern that there are some things could do to increase accessibility that would fail this test (related to descriptions or additional information about form controls, e.g., characteristics such as "required")
current wording: Test 189 - label must describe its associated control.
perhaps: text of the label directly relates to the associated control OR text of label is associated with the control OR "conceptually relate"
be careful about using "must" in the text of the test - ala john's suggestion
<scribe> ACTION: david propose wording of test 189 [recorded in http://www.w3.org/2005/08/10-wai-wcag-minutes.html#action06]
is alt-text considered?
addressed in test 188
http://www.w3.org/WAI/GL/2003/12/wttf.html
minor edits made to clarify a couple things. edits made as we discussed.
resolution: TTF work statement ready for thursday's discussion