See also: IRC log
<jslatin> that should keep us off the streets and out of trouble for a couple hours
<jslatin> zakim's giving me a hard time, hang on...
<ben> scribe: Ben
bg: from baseline discussion, how do we organize techs. to provide baseline info?
bg: wanted to come up with a list of techniques for diff. categories, one of them was for no script at all
(techs that worked with or without scripting). Now that we're removing requirement for alternatives to script, we needed a category for scripts that improve the accessibility of the site without harming access.
third category was if you are using script in your baseline, then here's how to do it so it meets UAAG and is directly accessible
bg: do these categories make sense?
Jim Ley posted some comments to list in response to proposed techniques. We also need to work on mapping for most of these techniques.
wc: am wondering how we explain this to people in a document that isn't normative - need to be careful about creating techniques that are more restrictive than guidelines
js: seems to me that if we have a req. like 2.1 (make interface elements keyboard operable), then there are diff. techs for doing that depending on what you're doing. (if you're assuming script or not)
<Tim> Have script techniques been designed with testability in mind?
js: important to map these back to GL and SC so we can say that techniques are for satisfying something in the guidelines and which technique you choose will depend on baseline assumption
bg: maybe some of these are best practices and could live in another doc
mc: I would say the first and third categories are needed for WCAG, some of the second category might not be
js: is that because 2nd category is things that can be done to improve accessibility where first is things that work in the absence of scripting and third is if scripts are used, making them accessible? (so middle category becomes optional)?
bg: I viewed it as third category as more optional, but didn't think those mapped to GL as well
dm: have we decided that we're only going to map back to SC, not to guidelines?
js: think we have to map to SC
wc: interesting question that's come up before. GL usually is the "sprit" of something and SC is more specific. Question is whether we can map to the more general things.
js: think those come under category of advisory techniques
dm: would have to add a bunch of SC to include techniques
wc: seems to me that application/widget related techniques map back to basic set of SC, which are they need a label (1.1), keyboard access (2.1), and role and state info depending on what the widget does. Is anything else missing? 4.2 group is working on role and state.
bg: I also found that a fair number mapped to 2.4 (ex. using onload to set focus to a form element on a page). Some issues with this came up on the list, but technique can be helpful.
js: also an issue with phone number focus issue
bg: yes, some like that, some
... 2.4 L2 SC2 is where I mapped it, thought about 2.5 because it generally applies to errors, but couldn't find a SC that actually maps
wc: is next step to do more work on these techniques?
bg: need feedback about this
direction, guess my next action item would be to propose a
guideline mapping for each of these
... need feedback to know if these are the right types of techniques
js: for me, I don't know enough scripting to be able to give good feedback on details, but outline seems right to me and I liked what wendy said about where SC might be - may all map to 1.1, 2.1 and whatever emerges from 4.2 work and maybe also to some other things like 2.4.
wc: think I'm close to proposing
that 1.1 require at least a label so you know that "within this
window, this is what this is" ... widgets need labels
... also an idea of grouping things into a unit that is functional (ex. date selector widget in Flickr)
<scribe> ACTION: becky to propose guideline mapping [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action01]
<scribe> ACTION: wendy to send email to Derek and Becky for feedback [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action02]
js: one piece of feedback on guide doc was links to tutorials and articles
wc: part of what I heard you saying becky was that we don't need to rewrite these things because they already exist. can we link to external resources and annotate instead of recreating other work
bg: think that's a good idea, wasn't sure if we could do that and what to do about permissions
wc: good question, other question is (from W3C process) do we really want to rely on something that might change.
js: but part of the reason we want techs. to be non-normative is that we can rely on other things and repair links over time and update them. another strategy is to include "date retrieved" info with links to external resources
wc: tim asked about testability - I'd like to see techniques and test suites developed together, needs development
<scribe> scribe: Michael
wc: plan to staggar work based on
what guidelines doing
... concern how much we can do in a given week, given how many techniques some guidelines will have
... hopefully most work is tweaking, though some technique generation will come up
... next FtF week of June 13 in Europe, still working on venue
... Monday town hall, Tue / Wed Techniques, Thur / Fri GL
... close all Bugzilla issues in June
js: what has to change about how TTF works to meet objectives?
wc: recently more work has been
done as proposals, by Mon for Wed call and by Tue for Thur
... look for increase in proposals so calls can just review
... 2 week process, harvest issues in first week (re Techniques & test cases for HTML, CSS, Script), tweak and close second week
... need to close A) requirements and B) testing matrix
js: held off on requirements until we had clearer sense of where we were going with guide doc and structure
mc: also had open action items
js: nervous because work on guide
doc prototypes noted it took longer than anticpated, may have
been new format but may have been tougher task than
... was it in the plan?
wc: idea was guide doc would be
wrapped up in issue summaries
... package guidelines and guide doc as one task type, and techniques and test cases as another task type
js: but does add to time so we need to factor it into plan
wc: first week can be identifying issues, and clarifies issues for guide doc which can be part of second week
js: questions also become part of
agenda for guide doc
... writing "intent" section has been very useful - if I can't state intent, can't expect anyone else to understand it
wc: most of issues with GL 1
related to clarifications for guide doc
... modify placeholders to have at least intent and example
js: and definitions
<wendy> ACTION: john and wendy in future discussions with ppl doing guidelines summaries, draft some of the guide doc content (intent, definitions (clean up if needed or pull in from glossary), examples - minimum) [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action03]
wc: also need to figure out who
is available when so we can schedule around power outages
... for next week need to sort out what techniques relate to guideline 1.1 under discussion
<wendy> ACTION: wendy and michael determine set of techniques and test cases for discussion for the next few weeks (1.3, 2.4, 4.2, 1.1) [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action04]
js: develop "assignment template" so when people assigned a guideline to review, they know what sort of stuff they need to produce
<wendy> ACTION: john draft "assignment templates" by Monday 25 April [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action05]
js: action to follow up on our
discussion of problems with <object> and challenge of
explict, useful, text alternatives
... message to CG list with example and query
... Al Gilman response was that he would respond
... John Gunderson said "just create a link"
js: philosophical discussion
... sounds like repair technique, not ultimately desirable
bc: UAAG needs to be fixed to address
js: Gregg suggested definition for "explicitly associated" that permits explicit text reference within same page
bc: e.g., alt text of image says "description below"
js: IMS site has a potential technique
js: re DHTML roadmap, discussion of making XHTML 2.0 features available in earlier versions of HTML, by using <link> and custom values e.g., rel="navigation" targeting id'd stuff on page
<wendy> summary of discussion from last week re: link/nav technique: http://lists.w3.org/Archives/Public/wai-xtech/2005Apr/0015.html
js: various parties working on the navigation challenge, and global vs. secondary nav
wc: were our concerns raised to CG?
js: not all
... haven't heard anything deeply problematic
bg: user agents will have to make changes to support all this
js: UIUC accessibility extension
might take some of that
... actual behaviour still undetermined
dmd: unclear if roadmap is present day or future
js: it's a road map to get us
somewhere we aren't now
... starts with XHTML 2.0 functionality, works backwards to find ways to incorporate that functionality in earlier versions of HTML back to 4.01, but it's not all fully working yet
... question of recommending techniques that work today and not tomorrow and vice versa
dmd: what's timeline wrt WCAG 2?
bg: working to make sure WCAG 2 doesn't handcuff steps of roadmap
js: if UA builds automatic toc,
how does it know what to call it? need a technique e.g., a
title on list
... no UA support for this now but wouldn't cost much to developers to do
bc: is "role" going to be
required in valid XHTML 2?
... will backward-walking techniques be part of sufficient / necessary for WCAG 2, or just advisory?
js: more advisory for now
bg: don't know if role for navigation is required
bc: if it is GL 4.1 could kick in
bg: roadmap steps in particular not required, but have to check for endpoint
wc: don't see "role" in XHTML 2 draft, but no draft since 2004
js: they've hit a wall
<wendy> ACTION: becky investigate if role for nav will be required in XHTMl 2 [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action06]
mc: connection to dmd test file work?
js: some of that discussion was what went to CG
dmd: big issue of what spec understands as alt vs. what we do
js: that's why it was a CG issue
wc: all of this is related go GL 1.1, so it's all good timing
js: bg had mentioned getting UA to look inside <object> for text alternatives, but CG didn't pick that up
bc: best model is there is a way in UA for user to query the object for "what's there" and "give it to me if I want it"
mcm: world-dominant browser doesn't even allow that right now
js: discussion on guide doc last
thur mainly involved people who had been drafting, so they
... high-level structure is 1: guidelines 2: guide doc 3: techniques, possibility including general techniques 4: checklists 5: test cases
... people with various needs should be able to come in at the right point to meet their needs
... that's a separate conceptual problem from that of structure
... we can satisfy 2.4 to provide different ways to navigate
... for guide doc, we each took different approach in prototypes, that group needs to converge and get the best
... return with more drafts and a template so people with assignments can complete
... feedback on bare outline was most confusing areas were "technology-independent techniques", not solved by calling "general techniques"
... either had no idea what to find or expected code examples
... so need a better label
... thought "understanding this sc" section redundant with "benefits"
... found useful exercise to write sentences beginning with "the intent of this sc is..."
... get guide doc task force (GDTF) to do next round, then send around to reveiwers again
<wendy> ACTION: john send msg to "guide doc task force" (michael, ben, wendy, john) and restart/finish guide doc work [recorded in http://www.w3.org/2005/04/20-wai-wcag-minutes.html#action07]
<wendy> note: this isn't a formal task force....just short hand to identify those folks who were working on guide doc.
<wendy> action 7= john send msg to "guide doc task force" (michael, ben, wendy, john, david) and restart/finish guide doc work
<wendy> ben and michael - thanks for scribing!
<jslatin> wendy, i'll send a WG update to the CG list...
<wendy> thanks, john
<jslatin> welcome! hasta luego
<jslatin> oooh, jaws butchered that spanish.
This is scribe.perl Revision: 1.122 of Date: 2005/03/31 04:43:41 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/your/you're/ Succeeded: s/techniqeus/techniques/ Succeeded: s/lable/label/ Found Scribe: Ben Inferring ScribeNick: ben Found Scribe: Michael Inferring ScribeNick: Michael Scribes: Ben, Michael ScribeNicks: ben, Michael Default Present: Matt, Wendy, Becky_Gibson, Ben, John_Slatin, [IPcaller], Michael_Cooper, Tim_Boland, Dave_MacDonald, ChristopheStrobbe Present: Matt Wendy Becky_Gibson Ben John_Slatin [IPcaller] Michael_Cooper Tim_Boland Dave_MacDonald ChristopheStrobbe Got date from IRC log name: 20 Apr 2005 Guessing minutes URL: http://www.w3.org/2005/04/20-wai-wcag-minutes.html People with action items: becky john msg send wendy WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]