See also: IRC log
1. published drafts of gateway, html, css last friday
2. working on test suites
jw what might conformance profiles look like? not sure that we need them or that they will solve any problems.
jw i worked through the guidelines and identified assumptions that were made about the type of content involved.
jw that resulted in 8 properties that are assumed at various points in the guidelines.
jw user interaction, non-text content, multimedia, etc. (http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0518.html)
jw gave examples of content using these characteristics.
jw could use this analysis to clarify the assumptions being made in certain criteria (i.e., when to apply the criteria)
jw might be useful to have slightly different tests based on the characteristics of the content.
examples based on these characteristics: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0521.html
asw What does the example mean?
asw is javascript considered non-text?
jw it has graphics in it, so it has non-text
jw think we could make success criteria clearer so wouldn't need conformance profiles.
rf it seems that some people are trying to apply this to flash as well (since only accessible on windows/pc). got me thinking about how to address this more globally.
rf perhaps a diminished status for conformance in addition to the 3 levels that are there. you could meet all of the criteria to meet AAA, but this one thing could prevent you from claiming AAA.
rf perhaps have A-
rf that would say that what you developed is accessible to users using certain user agents/assistive technologies
al in some instances, some criteria are not applicable.
al javascript is one example, acronyms is nother.
al today's guidelines are written with the assumption that the content is a public site to be used by anyone. for intranets/corporate networks, it is a very different culture and set of requirements.
al need to take into account business decisionws
<Zakim> Michael_Cooper, you wanted to go back to separating digital divide re disabilities vs. digital divide re hardware/UA/AT
mc in the past we deliberately confounded them b/c accessibility was related to lack of technology. less the case today, but still the case.
rf there is a conflation between universal design and accessibility for people with disabilities. there is overlap, but there are two issues.
rf by not separating them, you discourage authors to try.
rf there are handhelds without javascript as well.
rf each level could have a minus and that would signify that while the resource is accessible w/disabilities if they have the right technology, it is not necessarily accessible using all technologies (all platforms or all user agents).
rf would be a blanket. people could make AAA claim
jw confusion between the profile idea and the issues surrounding principle 4.
jw don't think that we have a proposal that connects the 2
jw at level 1 under 4.2, set minimum requirements for the support that has to exist for the author to rely on particular technologies.
jw issues: how refer to UAAG, how make level 1 criterion, etc.
jw level 1 would be what is technically necessary
m3m re: "- level" - we need less conformance levels, not more.
m3m the point of what we are doing is to point out the requirements for accessibility.
al it has nothing to do with lowering the bar, but that the bar doesn't make sense in all cases.
ack
<scribe> ACTION: jason rework proposal (in a couple weeks)
<scribe> ACTION: robert look at jason's proposals and if so inspired, propose another method to handle
richard's response: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0607.html
martin's response: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0603.html
asw programmatic objects, such as scripts, applets, and plug-ins
wac's proposal: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0602.html
asw people don't think PDF is a programmatic object, but it requires a plug-in
http://www.w3.org/WAI/EO/Drafts/sketchpad/wcag20-intro
slh gives summary about WAI site design and purpose of overview.
gv looks like overview should be separate document, but also might be good to have some version of it (or some part of it) in WCAG 2.0.
slh a challenging question. if we decide to keep them separate and have less in 2.0, could do more to make people aware of intro document.
slh advantages of separate document: it chunks things/helps with progressive disclosure
slh on the other hand, no matter how much effort we make to point people to the effort, some people will have wcag 2.0 and nothing else. there is a balance.
slh lean towards separate
gv gateway: we've talked about core techniques, general, etc. each suggests a different role.
gv what does it look like to you?
slh was involved in some of the ttf discussions with formatting of gateway
slh WCAG 1.0 had a gateway that did not have content. core had general techniques. if take the current path that combines them, important not to call that gateway.
slh someone who knows WCAG 1.0 thinks "gateway doesn't have content"
slh if change function, good to change terminology.
js suggestion about organization of overview: instead of begin about differences, begin w/more direct desription of 2.0 and follow with differences.
js wasn't aware that there was a WCAG 1.0 GAteway.
wac it was called "Techniques for WCAG 1.0" and provided gateway functionality but not called gateway.
js message Proposal: purpose and approach for Gateway - http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0557.html
js perhaps need a document like the Core Techniques for WCAG 1.0 that is more along the lines of design strategies.
<Zakim> wendy, you wanted to ask "diagram of relationships between chunks. general gateway issues/john's proposal/overview"
khs useful to have it organized like this, why doesn't it just say checklist and techniques? gateway seems confusing rather than clarifying.
khs having 2 gateway docs is confusing
gv can't be an HTML checklist because you can't have an individual technology checklist
slh recommends "general techniques" if it includes content and pointers
slh would be helpful to clarify that not going to have technology-specific checklists.
slh the diagram is partly made up to have something to talk about
gv HTML is never used alone (always use jpg and other formats)
gv can't use css on its own
gv because checklists are not normative, seeing them as being a checklist engine to specify which technologies are being used.
wac how do test suites fits into?
gv css test suite is a series of html pages.
discussion about test suites. chris' latest proposal.
gv that is not a test suite, that is an example
gv these are not used to test pages, they are used to test tools.
<Zakim> shawn, you wanted to ask about "General Techniques" and "Checklist Generator"... and what we'll have for Nov WG releases, e.g. anything for checklists?
gv include all pieces in the diagram whether they exist or not.
gv the checklists into the test suites
gv if there is a checklist generator, it combines the four separate checklist "blocks" (from shawn's diagram)
gv test suites must include teh good and bad (to test both false negatives and positives)
mc the test suites are tied to the techniques and techniques are should be tied to checklist
gv checklists should suffice by self
slh checklists do not yet exist?
gv many of the checklist points exist in the techniques, but the checklists do not yet exist.
gv appreciate feedback about how to present all the information w/out totally overwhelming people. if dynamic, don't have to display all at once.
gv there are many options (techniques) that are possible to satisfy criteria
bc we'll have to look at the techniques and determine which are required at which levels and how to integrate. working on initial prototype for a checklist.
bc as it is, have a lot of techniques loosely related to success criteria.
gv also, a lot of advice that doesn't link direclty back to guidelines.
gv a disadvantage about the checklist generator is that there is a lot of techniques that people may miss (if it disappears as a user selects/deselects options for generating checklist)