Held at HP Labs in Bristol, England.
Check out Ian's photos from the meeting and Kynn's photos from the meeting.
Introductions around the table
(No minutes available yet)
LS: I realized that the diversity of devices creates a lot of problems - generic solution impossible? perhaps best you could do is accessible if not usable.
Tom: Brainstorming sessions worked to highlight some difficulties
CT: When will voice really happen?
Kaz: I am very interested in multi-modal and multi-channel. We need to develop these activities. We don't know where/when/if convergence will happen. We need a lot of experience.
DD: Need to retarget content (not just change presentation) is real. so some content providers will have to rework content to make it optimal for the target device. spectrum of complexity from mom and dad to huge publishers. authoring tool: what you see is what everyone gets. need multiple views of docs.
GV necessary to repurpose the content for all sites? would some sites would not be able to make it transform gracefully w/out designing.
IJ i sensed from the last breakout session that people were not speaking the same language. e.g. we were talking about modalities. i thought all would understand functionality is separate from hardware. not so. they expected that their metaphor would apply to others. we didn't make much progress. one point was that you might not be able to produce a site that works everywhere b/c it is lowest common denominator. people were working w/different abstractions.
CS we had agreement in our group. it would be a good thing to abstract a way in the same way that HTML did (for document arguing). "navigate" taken from hands of author to user agent. what are the other verbs. what markup needed? "intent" markup language. "verb" markup language. Lots of thoughts on interactivity.
WC: In our breakout group we talked about intent, task-based, e.g., if the task is "I want the balance of my account." The interactions would take place in perhaps different sequences. .and authoring tool would help tailor content.
Claus: at oracle we can generate multiple views from a database. WAP folks have device that is web-enabled different than pc. WAP are not interested in PCs, they are interested in WAP phones. presentation on digital tv: outcome was that the concern is not multi-device but device made to fit particular model. one for europe, one for u.s., etc. different formats. you get what the provider provides not what you want.
CMN highlight was arriving. there is a desire to produce stuff once. some people think you can. there are some people who think it can't be done.
WC what about accessibility?
CMN gaols are similar. those who nay-sayer are large content produceres. they want control of presentation. how important is presentation in accessibility?
GR
Mark: i'm optimistic. in the history there are changes that unseat the way we do things. many of the markup languages we are using need to be redeisgned perfect opportunity to make sure that accessibility requirements action item for this group: guidelines for accessibility of authors and autohring tools. there are no accessibility guidelines for markup language.
DD there is the start of that. XML Accessibility guidelines.
Mark: needs to be across devices.
JW it's on the agenda for tomorrow.
KB saw good and bad. bad is b/c i am cynical. good: there is a greater perception that need for general solution that is not just accessibility. those who care about devices care about similar things. there is a shift in the way the web is being perceived. what we've talked about for years is being applied to others. cynical: we gloss over "can it be done?" scenario. to what extent can we do what we hope. ? easy to think that people who don't think about it "right" are "wrong." can not make decisions just based on philosophy. many of the answers i heard were that "tools are the answer." easy for us to pin hopes on hypothetical tool. even if not need or won't be market success, it will solve our problems. may set up unrealistic expectations. may need to solve problems but puttin goff. keep in mind: authoring will be change in way we think. it makes the authoring process more complex. advantage of web so far is that anyone can put up content.
GV when putting it off to tools, user side tools? or gateway? or proxy?
KB all of them. authoring, user, server, etc.
GV we need to talk about tools that exist now or know that are in development. i agree. if there is a capability that we can think of to get built, we should identify. we have increasing load on authors.
GR: Better tools are only part of the solution Education is even more important. Teach people to design for N interfaces. I think UIML merits our attention. tools meaningless w/out education. standardization for reasonable expectations from users. Onus is not only on author but on tool vendor to provide more detailed styling.
LS: The most exciting thing for me at the workshop was a clear call for tools (I'm a tool builder). what was called for seemed implementable. It's good to be able to go to funding sources and say that "I have observed consensus in large diverse groups calling for these tools." W3C Certification for authors is also a good idea. Needed by authoring community - need for international legitimization of authors. I think that making content for different tools and making that content accessible (for that tool) are different questions.
Katie: I walked away from workshop optimistic. I am also excited about UIML. I saw the television and telephone industries represented looking to w3c for the kind of consistency w3c has been able to achieive. Though people here for common communication goals, these goals help us.
WL: "Where does a 600-pound gorilla sit? Anywhere he wants to." .I found about 8 600-pound gorillas at the workshop. Telephone people, TV people (push and shove). The marketplace was an even larger gorilla. Analogy: train to arrival of airplanes.
* Ian is lost in different metaphors of club-bearing beasts.
Optimization for a delivery point gets ridiculous when taken to the extreme (the individual). People concerned about separation of content from presentation. what about simulators? "they don't care" if they can't build a simulator for every phone incompetent or indifferent. Incompetent, indifferent, or both. notion of tools: must be something that simulates each device. our guidelines say, "try it" if you can't, then how do you do it?
WC an american phone will not work in europe, vice versa and that simulation is required in some instances. as devices propagate, not possible to buy all and test on.
Cynthia: I came away enthusiastic (also about UIML) from the meeting. it's difficult to do single-authoring of content (tailored to a medium) but I think it's easier to single-author behavior and UI. I think that putting too much on the back of tools is a red herring. building UIs in HTML is very difficult (not appropriate based on original intent of language). we can simplify the authoring model. I think that we can simplify the authoring model with appropriate markup. you can get a lot closer to device-independence.
IJ agree w/DD and others: need for specialization. people want to build optimally across devices. someone asked, "Is one-time authoring doomed" is "text king" for all users. we have heavy emphasis on text. we may need to reconsider. apps rather than pages. is separation and presentation truly possible? what do we mean by that? are mantras good ideas but look too closely they break down? what you see is what they get: not only view how content rendered but validating.
Wendy: One idea very relevant for this group: Different types of content (portal v. small site, for example). I heard a lot of requests from people that W3C needs to publish a roadmap. I'm concerned about the separation of content/presentation/interaction. Talked to Jonathan Chetwynd over the weekend. Talked about capturing "humanness" in dialog between author and user. "don't let philosophy keep us in a box."
DB: I'm not sure what we're talking about when we talk about "content". What is Web content? What about radio? What is the scope of "content" for the Web Content Accessibility Guidelines Working Group.
* Ian quips that we need to define "Web", "Content", "Accessibility", and "Guidelines" .
Gregg: Were most people at the workshop talking about markup? Cynthia: People were talking about "markup" for applications.
GV: Device-independence is a basic-precept for accessibility.
Cynthia: I heard at this meeting lots of discussion about different "devices" (phones, PDAs, etc.) as opposed to "without a keyboard, mouse, and for use with screen reader".
GV: Why is voice-browsing different from what we're talking about?
WC: Different interaction style.
CS making docs vs. apps accessible.
GV seems to me that making it accessible on small screen is same as using magnification. that we're working on similar problems. they were talking about markup vs apps. as web moves more towards apps we're going to have to look at device independence, serving diff info, where web underlines implications for our work. need to derive principles. servering presentation.
JW I think the sentiment that CS raised, that we hope that it will be better to develop tech based on XML will avoid incompatibility problems of HTML. widely shared sentiment. will provide opportunity to extend interactive opportunity. authoring mode ua and au may be merged. there will be a transformation. it needs to be controlled by user. we need to make sure that guidelines don't constrain architecture but how the transformations can take place and under whose control.
JW tools are being developed that have converged authoring content and authoring lanagues. can we maintain a distinction between content development and language developemnt. ? Is it appropriate for us to address language issues? Main document? Separate document?
DD: 1) Relevance of XML Accessibility GUidelines to WCAG. Eventually, tools that let you create content and tools that let you create languages will merge. trend pushing us in the direction of including XML Guidelines in WCAG. however, for a time, I think that people will be creating languages by hand. I think there's an audience for a short, simple document. I don't think we should include them in WCAG. Would be more effective separate. content guidelines will be used by authoring tools. XML Guidelines will be used by people creating schemas, etc. by hand.
WL: I second that.
* Mark talks about UIML. you can't use UIML by itself. like XML. you have to add a vocabulary. set of abstractions for java interfaces, other for WML, others for HTML. we are workin gon abstractions across devices. it's an opportunity to capture intentions for authors. what is the info that is required? other aspect: naturally separates interaction, behavior, and content. the separation is key to allow mapping. converters for UIML-> WML, Java, HTML, VoiceXML, Palm the XML access guidelines are good start. what is the experience for the end user? back track: what abstractions do youw ant to cover? in HTML can't figure out navigation. in UIML you can create a vocabulary that requires navigation area highlight. item 2, point 3. is right idea, but "etc." needs to be thought about. it's things like the navigation part.
DD navigatable stuff is in guideline 4. UIML seems to be a great platform for creating user interface does w3c home page qualify as an interface? are we talking about docs or apps? the web is not going to be completely interface focused. how will UIML help make this document more accessible? (this document = a type of document you do easily in HTML) relationship to XForm. constraints that prevent it from using UIML technology. (also linking, schemas, style sheets) I see UIML as more meta than XForms, but similar. this is something we need to talk about in another forum in W3C.
Mark: a) What do you do with pages that have no interaction? You can represent them in UIML. .You might was to create additional vocabulary on top of HTML (e.g., navbar).
DD: Like "class" in HTML. or XML Schemas. Why different from schemas in general?
Mark: UIML might just have the role of an intermediate language, from which would be generated device/platform-specific end formats. As a meta-language, allows addition of abstractions, and thus can benefit accessibility. b) Relationship to other w3c technologies. - Highly compatible with xml/xslt - Works with html + css. - Designed to avoid scripting. - Uses namespaces.
Think of UIML as a language for composing, and then for mapping to something concrete.
Loretta: When you define abstractions in UIML, what properties can you specify?
Mark: Anything you want. (it's a meta-language)
Loretta: We need guidance in developing vocabularies. anything come out of the workshop for different paradigms?
Wendy: Why did several people mention UIML in their summaries of the workshop?
CS right now, repurposing documented oriented paradigm for apps. can't do XSLT on javascript. describe what trying to build then translate to variety of platforms that could support, especially very interactive paradigms like WAP.
Mark: We tried to get rid of a lot of scripting and replace with markup. .we see patterns in scripting that can be captured in markup.
GR: Scripts bane of a lot of users' existence.
WL: It brought out for me: - the notion of content developers / standards developers / language developers comes into play. tension between synthesis and analysis (do you standardize a priori or a posteriori) UIML designers wanted to create something that would become a de facto standard. .RDF seemed like it would be great. But now bogged down in syntax issues. I like distinction between content, style, behavior, interaction.
DD: Everything people like about UIML is also present in XForms. I think that people are underestimating the work going on to make xforms work with the whole xml suite. what XForms is doing and I'm not sure it's done in UIML is the definition of the actual UI abstraction (data types, data constraints) UIML is meta in that it has few semantics attached to UI. Seems like a lot of the work needs to be donein the mapping.
Mark: XForms is important, but you will need a language above it (and HTML). things in XForms that require us to enhance UIML. needs to be superset.
Jason: Question - What requirements do we need to account for in Guidelines 2 (separation of content/presentation) 5 (device-independence) in light of XForms work, UIML work.
Loretta: (re: replacement of scripting by abstractions). -Have these abstractions been defined somewhere?
Mark: We have integrated some categories of things in the language. (e.g., a behaviors section).
* Ian notes CSS behaviors work And action sheets
Lisa: How much guidance into use of UIML is provided?
Mark: Nothing built-in (since meta language) but vocabularies should indicate best practice. ways to capture that. ways to capture the best practices. to make it likely.
* Ian notes that wcag could create a schema for user interface and content elements that would capture good practice.
WAC: Is XML a separate document? Is it even addressed by the WG? Is it within WCAG?
* Wendy is trying to bring discussion back from UIML to xml access note.
Jason: I think that there are two issues (and UIML linked in this sense): -How should WCAG address extensibility of markup languages?
Jason: In Guideline 2, we distinguish content and presentation. In Guideline 5, device-independence. Q: Reviewing G2 and G5, any revisions required in light of XForms work?
GV: We need to look at all of what people are doing (even if proprietary) and see whether what we are doing now would provide guidance for how they should be done.
WC: What issues do people want to address now? I think we're clouding the issues right now.
DD: Is WCAG WG going to work on language design document, or who?
Kynn: Q of guidelines for language design and guidelines for language usage. .I think that in practice, it's better to distinguish. (cases of authors who are language developers rare). we need to address what is happening. in a word processor as word can define styles and in effect extending styles.
K: Big distance currently between Web developers and XML Developers. w/diff in mindset it will make WCAG harder if we include it. we're looking at two different documents.
IJ who feels should be separate?
Wendy does taxonomy of options: Option 1) Keep XML Accessibility document separate from WCAG / Integrate it => Strong majority desires to keep them separate. Option 2) Language development guidelines as a set of techniques for WCAG 2.0.
GR: I support two documents. However, I want documents to address usability as well as usability. I think that there's an artificial separation of the issues. So second document, but not focused only on accessibility.
CMN: I think that two documents should be developed separately: WCAG WG should focus on what makes Web content accessible and should ignore for now what that language should provide. Instead, request the PFWG work on question of what makes a language accessible.
WAC: Who wants the WCAG WG to work on general language accessibility document. ?
DD: I think that PF isn't moving forward with it and that WCAG should work on it.
* About 8 people think that WCAG WG needs to develop guidelines for people creating languages.
LS: I disagree with the idea of separating content guidelines from language design guidlines. I think of it as set theory, where sets overlap people might not realize they are in overlapping area and may miss requirements. if you split the documents, you will lose communication. even someone who considers themselves a pure "author" will be doing things like creating CSS classes and that will overlap with language design principles.
JW agree w/lisa. don't think lisa and kynn's points conflict. which working group - don't fits in PF charter. could be joint item. should guidelines be based on same guidelines set (as WCAG) to develop a language, you need to be sure that language will allow one to satisfy WCAG. possible to develop as a checklist.
CMN: Who in this WG thinks they want to work on a document?
Proposal: a) WCAG should concentrate for now on content. (though I recognize blurred distinction between creating a language and creating content in that language). b) We should request that PF get into gear on this document.
Tom: As interaction paradigms get more complex, authoring guidelines will need to show examples. people will always be thinking about content when they are designing a language. talking about the model of the document (e.g., navigation structures) is blurry and could fall in either. I think that the documents should be separate for usability of the document by language designers.
DD: Depending on how the WCAG 2.0 guidelines turn out to be, it might be possible to consider XML stuff as techniques. But things like "provide a conformance statement related to accessibility" don't fit easily as techniques in wcag principles. if the wcag principles can't be adapted, keep xml stuff in a separate document.
GV: We first drew a line between page/application. That is passe. We then drew a line between server and client. That line blurred now. We may have tools coming along that help people create markup languages. We need to think about, with that trend, a potential blurring between the use and creation of markup languages. need to ensure that we don't design short-sighted guidelines and we need to consider blurring lines.
GV: We can create subgroups to do work.
JW think getting closer to consensus.
CS draft see how hard it is. technology specific module for markup language design
CMN: I think we should leave this as a future work item and focus now on content.
CT: can UIML incorporate accessibility features. be so generalized they will not understand. if you put off lang creation guidelines,
(Lisa) then will see
DD agree. if we're missing this opportunity we'll miss it later. also resources not here. propose: PF will adapt current doc to WCAG 2.0 layout so we can move in parallel so not dead in water.
CT why is WCAG 2.0 so important?
tom: let's stop pontificating and move on to real world. don't swept under table. creating new lagnuages is important. people will emulate big companies. we need to get message across early, rather than lose impact when approaches distributed. (when approaches distributed means : smaller orgs emulate mistakes of big orgs)
CMN why we want WCAG is that ATAG relies on WCAG. hard to apply to multimedia. Proposed:
DD: If we can restart XML guidelines with new organization (based on new principles in WCAG 2.0).
Jason: One problem I have with the proposal - need to have work on this document carried out in public.
Resolved: Amendment to point one - PF work on document needs to be kickstarted, using WCAG framework, done in public.
DD: A public working draft will be available to WCAG WG.
Gregory: Dissent since I think that accessibility and usability and language design needs to be in one document.
DD: Why not add I18N and how to do accessible web sites, etc. in one document.
Action Ian and Wendy: Go work on a document on accessibility of languages (larger than just DTDs, for example).
Lunch
Meeting resumes at 13:50.
28 September 2000 Draft of WCAG 2.0
WAC: Anyone have any particular issues with changes? Isssue 18
Question: How do you define "necessary"?
IJ: Two comments - Eric Hansen comments about alternatives and text equivalents for them. - New UA terminology so I will be tracking this discussion and WCAG should review in last call.
Kynn: Our level of granularity is arbitrary (anyway). I think we might want to consider breaking this out again into different groups: graphical, auditory, multimedia.
Lisa: "Conceptual text equivalent".
Jason: Providing textual equivalents is a way of satisfying the underlying requirement that content be displayable in three modes. need to emphasize not that a text equivalent is necessary for everything, but that content available in three modes.
Tom: Definition of "text equivalent" is hazy. need to let people know that description may not be enough.
Wendy: The idea of "content" is interesting. in questioning the division into separate checkpoints, I can see some advantages, but also some drawbacks (e.g., when it's difficult to categorize a particular medium).
CS: I think 1.1 as written is pretty close. I like the fact that it covers multiple modalities. I would make an editorial change to activate it.
IJ overriding warning: i am here with UA in mind. like jason's idea that there is an underlying goal that content when rendered is available in three modes. due to current technology, text as input is best way to ensure happens. 1. how can i ensure this? 2. how equivalent is alternative. html implementation issue: alt/longdesc. way go about providing most effective message separate from being in text. is 1.1 about quality of message or that text is most effective way today. expose underlying goal? "use text for this reason" would like to see: encoded of equivalency relationships in markup. this is identified as equivalent, then i can do neat things w/it. definition of text equivalent: "text content" is one or more text elements (definition in UAAG) put this info in definitions. thing that must be rendered in differnet modes. some combo of text.
KB: I have some problems with 1.1: a) "Every component" phrase is problematic. It doesn't allow for the idea of a graphic with a text label underneath it. If you provide alt text for the thing underneath it, you would get the same thing twice.
* Ian notes that UAAG would help with that if equivalency relationship identifiable.
b) I don't think that thinking of things in terms of components is close enough to "functionality". I think it's more important to convey the functionality of the page than of the components. c) "Rendered as text" is odd. Lynx will render an image as [IMAGE]. if we say "rendering", we need to say what we mean. d) If we say std charset, we need to say which one.
Dick Brown: I don't think we should specify a text equivalent for components but for a functional whole.
WAC: One of the goals is that the checkpoints can stand on their own.
Tom: The dfn of "text equivalent" as Ian proposed would be a good addition. But people are still missing the point. in any case, don't say "text equivalent or some other description". That is confusing. impress more on people to not provide descriptions, but provide functional equivalents.
Jason: Useful for the changes in the UAAG 1.0 be incorporated into the discussion of the WCAG 2.0 1.1 prose. I think that the essential requirement (flowing from G2) is not made explicit enough. equivalence relationship must be provided explicitly. warning flag about the scope of text equivalents - be careful about letting authors choose when they can eliminate lower-level equivalents in the name of top-level equivalents.
WL: You need explanation and rationale in this document. But use links and separate explanation out of documnet. pay some attention to tersification.
WAC summarizing: a) Seems like "as necessary" should be dropped. b) Clarify that we mean "function" not "description". I don't think 1.1 applies to applications, but not Web pages. "Guideline 1. Design content that can be presented visually, auditorily or tactually, according to the needs and preferences of the user."
WAC: Therefore, you could say: - For documents, provide .
IJ: What are the characteristics of an application?
ij: not obvious to say what what. other distinction: that w/chrome vs what the author provides. most of requirements doesn't matter. content = images, text,
IJ: In UAAG, we split along three lines: content, user interface, and APIs.
CS: Content + Interface = Application
Tom: Need for people to consider context in which they are providing equivalents.
Jason: a) I don't think the distinction between content and application is useful here. it doesn't matter where a non-text component comes from (whether part of the UI or not). It still needs an equivalent. b) For interactivity, the UI part (input components) must be device independent. There might be lower-level issues of detail regarding how you write an equivalent that is part of the UI. c) There's an issue of timing relationships. I don't think we need to complicate 1.1 by distinguishing content and application. d) We need to be very clear why we're discussing this.
Kynn: I think that the distinction between content, applications, interactions, etc. is going to be something we could spend a lot of time on for no purpose. there's a continuum. we can probably s/content/content and application/g.
GR: The separation of content and interaction and behavior and interaction and structure artificial.
IJ: That seems contrary to the positive reaction to UIML this morning!
GR: I mean content as message, not as "stuff" that comes over the wire.
Katie: I think that it is important to make the distinction to the reader that they must be clear that the requirements apply to all.
CS: I think that in many cases, content and UI have same requirements. we need to ensure that we don't place undue burdens of UI developers on page developers.
WL attempt to define "content" resolved by saying "we use it diff ways in diff places and in use with sep w/structure, 'stuff". restrict to one or another is not possible. in this case, content includes interface
DC: We have a definition for content. Can we just work on expanding definition? (e.g. adding "applications").
IJ we've worked on in UA. we had requests to clearly separate user interface and content. does WCAG point to UAAG for user interface?
IJ: Perhaps WCAG should point to UAAG for user interface reqs (just as UAAG points back to WCAG for content reuqirements).
Jason: 1) I think G1 rationale is clear. 2) I think 1.1 has some stylistic problems. 3) I think that 1.1 applies to UI requirements. We could distinguish them, noting the lines are blurred at times.
Tom: I'm against the "every component" part. (need to define component?) Maybe we should use the term "presentation".
WAC: We are talking about "message", not components.
IJ: Does anyone disagree with this view?
JW: I do. It forces authors to make decisions I don't think they should be making. .I don't want to re-open that issue. I'd rather keep the requirement that every component has an equivalent in text. I do agree that there's an issue of terminology. Does component mean "every frame of a visual presentation" or "every 1/10th of a second of an auditory presentation". I don't think so. We need to clarify through definitions.
JW: I think the word "content" has an unfortunate equivocation in the guidelines: I think that we we mean by content is the meaning that is intended to be conveyed.
WAC: I want to submit a proposal.
Action WG: Since we will not reach consensus today, I invite everyone to submit a proposal for what they want 1.1 to say.
LS: We should do this in an accumulative way, rather than ignoring what others have written.
JW: I think that anyone who wishes to raise an issue must either back it with a proposal or say what kind of change would satisfy the individual.
Action WAC: Respond to Wendy's proposal for 1.1.
* some discussion about the need for WCAG 2.0
CS: I tried to use wcag 1.0 for a major portal site. WCAG 2.0 is addressing real feedback from real developers.
DB: I'll back her up on this.
Tom: Note that Bobby will point you to 1.1 if you don't use the "alt" attribute.
LS: For someone with a cognitive disability, you will read as little as possible. Even when you think you are reading every word, you may not. When I think I have the point of the sentence, I may not. .I think that 1.1 contains a bunch of concepts, and I missed some. In other words: front load the requirements.
LS: I think that requirements should be written in short chunks (e.g., This requirement has two parts: (a) (b) .)
Break
WAC: 1) Generating content 2) XSL and XSLT 3) Issue harvesting.
JW: We've reversed the order for tomorrow's agenda.
WL: The problem with Ghettos. Exclusion, adaptations. The overall pattern of inclusion becomes extremely important for the person who is to be included. For self-respect, but also safety and even life.
GR: On the ability of individuals with disabilities to author. the WCAG must be accessible (as LS was talking about - requirements must not be for technophiles only). tear down barriers to ignorance by providing those who have been disenfranchised in the past with a voice for expressing their needs and requirements.
WAC: At the workshop, I heard a lot of this: "If I know the capabilities of a device, I can create content that's optimized for that device. What if I know the abilities of a person."
GR: You can't generalize. When you generate content, you need to ensure that the message is available redundantly.
WL: Inclusion is not just for the included. It's for society.
JW: Are you moving onto the generated content issue?
WL: The idea that there is a text only page that does the same thing is a cop-out and needs to be challenged. one reason that it's a bad choice of options is the ghetto reason. But that does not mean you can't have on-the-fly generation of content.
GR: A majority of users don't have access to the latest technology. In developing strategies (not just WCAG but in UAAG as well).
GR: Tablin is a good tool since can be run as a proxy. This allows people with older technologies to access information.
GR: I think we will always have to support older software.
Tom: I don't think we should say that "text only sites cannot work". It can be done when done properly.
* Ian refers to text-only brain dump
CS: About on the fly generation: - With database generation, it's possible to do better than graceful transformation (the details about URI of resource are not important). Is second URI ghettoization? Is stale content a ghetto?
(Yes)
GR: Also stale features.
CS: Some screen readers don't handle scripts. But there were some examples where we tried to create a server-side solution that didn't work and required client-side scripting to achieve the task.
CS: I would hate to not implement that feature for millions of users because I can't come up with a non-script solution.
DD: On the topic of user profile related to device profile - privacy! You may not want to tell the world in general that you are in a wheelchair, for example. that's what cc/pp concentrates on device profiles.
DD: For proxies like tablin, they're great tools but require deployment testing. It's hard to make them really workable without a real deployment campaigns.
DB: Are you opposed to people being able to personalize content delivery?
GR: notion of page goes out the window. The site has to be accessible. (conformance w.r.t. site, not page)
LS: I'm in the middle of testing a tool that I just built. this tool does a series of substitutions on HTML (the original page) to create a text-only site that has a similar feel to the graphical (jazzy) site. You aren't affecting the original page. The idea is that businesses might find this more palatable. the tool automatically alerts page author when no substitution is available for some bit of content. web developers may like this kind of tool since it doesn't require knowing guidelines, etc.
ij should the checkpoints be understandable to an 8 year old? someone who can read. we expect a certain audience.
lisa: remove barriers due to accessibility due to disability.
ij: it's fuzzy. we recognize that in WCAG 1.0.
lisa: then write a checkpoint.
ij: struck me earlier that breaking into smaller pieces. more in line with database driven pages, do people feel that the goal be on demand in a form that is accessible? it doesn't matter if content contains extra info, but as long as i can access to some info. if it is available at some point it is ok. expand requirement (or clarify) in conformance claim "the scope of claim is this whole site" perhaps wcag 1.0 work as is.
IJ: And therefore (if my assumption that "content must be available at some point from the server") wcag 1.0 doesn't need changing, but the conformance claim needs to make this clear.
JW: I think there's an issue here that I don't think was brought out. there's a question regarding conformance claims that needs to be considered - can they apply when there are multiple versions of the same content available to the client availble after some negotiation. Can the claim apply to all that's available? second part that I don't think has been considered yet: if people are personalizing their experience in relation to particular web content through profiles (and they receive a particular version of that content), then the versions available to other people with other preferences would be different.
JW: But people must be able to have access to versions available to other people.
IJ tries to summarize: 1) User must have access to all content. 2) User may wish to set preferences and get or not get certain types of content.
JW: I think we should add this to the issues list: (consider this example). SUppose I configure my UA for preferences for text-only. And someone else has set preferences for other types of content. Do I have entitled to be notified that there is other content available?
* Ian notes that this issue is covered in UA Guidelines, but upstream not covered explicitly.
Tom: Proposal - if content is updated in one place, then must be updated in another place (where possible).
ij: UA covers this to some extent. when the UA says "don't render, notify when modified." we have notification requirements. propose requirement: author must not prohibit access to content types unless specifically requested by user. On the UA guidelines: We have notification requirements - when something is available but has not been rendered due to user preferences, let the user know that some alternative is available.
IJ: Adds to requirement - you need to provide an equivalent.
GR: Lynx lets you represent what it can't handle.
DB: It seems that implicit in this is support for very old browsers.
Action WAC: Add this issue to the issues list.
JW: Reformulate requirement: a server should not reformulate content to eliminate some components unless in response to user preferences.
JW: I think the notification issue is an important one (and applies to wcag as well as uaag). simply providing an alternative version is not a substitute for making the primary version accessible.
JW hands over chairing duties to WAC
Kynn: 1) Who here has worked with XML? (show of hands) 2) How many people have worked with xslt? (show of fewer hands)
KB: Basic proposal is: a) Definitive "source" is some xml documnet b) Use xslt to create views
KB: Some coordination issues must be dealt with (for linking between views).
DB: I support the "database" backend idea. it's definitely needed. I hope that we make it publicly available how you can create views of a document.
DB: Need to tell people that when they do authoring practice P, they satisfy N guidelines.
WAC: This lets Bobby grab source and do interesting things with it.
CMN: You might run up against some copyright issues. (but unlikely unless there is misrepresentation in usage)
WAC: Conformance issue - the all-inclusive view is the one you conform to.
KB: Whenever we're talking about audiences, we need to document our assumptions about our audiences.
* WAC reminds people to review WCAG 2.0 requirements document to see if expecations are met.
ADJOURNED for the day
JW planning, going to last call. what time frame? what needs to be done?
IJ in terms of the process, the working group has to document that this is ready to go to last call.
CS what is the quality of the last call?
IJ the WG has fulfilled the charter. they are "done." they may not know everything.
JW with the existing draft. we've worked on several months. several open issues. techniques has not been worked on. which techniques have first?
WAC: There are currently 17 open isuses.
WAC: How do we want to organize? Subgroups for techniques?
WAC: How quickly do we want to more forward? Is 6 months realistic?
WL: I think that the guidelines/techniques split is applicable in the present.
IJ not supposed to go to last call w/open issues.
WL I'm talking about a call for help.
DD That's a public working draft.
IJ to whom?
DD IG, other WGs.
WL We're close to that almost now.
DD status should explain.
DB what are supposed to accomplish w/this version? how do we know when we're finished? we still need to figure out what content is.
claus: if we put it out in public, if everyone is as confused as we are, will we cause more confusion.
CMN a public working draft is, "this is what we're up to." the value is to give people an idea of what's coming. incremental development and exposure a good thing.
GR: Reality check necessary.
Tom: I think that there needs to be some editorial work on guidelines, but I think the techniques require more work.
LS: Techniques need a lot more practical examples.
WAC: What are our long range plans? What are the steps we take to get there? We need to release to the public so they can look at the document.
WAC: I think that the major goal for the next draft should be to expose the flow of the document. (even if the flow is not the final one).
JW: Three levels (guidelines, checkpoints, techniques). If the first two groups are roughly ok, then that's enough to tell the public where we are. I think that that's as far as we need to go to get out a public draft.
CT: I'd like to get clarity on a couple of points: a) What we discussed yesterday has large implications for the UA group. when we publish a wcag 2.0 we will already require a uaag 2.0. b) What does "public draft" mean? How much feedback does that usually generate?
IJ: Sometimes we do a "first call".
Cynthia: For a public draft, I think we need an HTML techniques document as well (to match wcag 1.0 content).
JW proposal: Public WD in six weeks plus HTML Techniques document. (includes checklists).
One minute round-about
WL: The techniques requirement seems too stringent; can just be a place-holder.
CMN: I think we should at least map all of the html techs material we have to a new form.
DB: I think we need a better understanding of how this all fits.
Katie: Ok with proposal.
GR: Ok with proposal. Point to open issues.
JW: I'd like to have html techniques + one other module to illustrate how the thing is supposed to work.
Max: I agree with GR.
DD: I'd like to see a specific section that explains why we are moving from 14-6 guidelines.
Action CMN: Write a short paragraph explaining this change to fewer guidelines.
KK: I'd like to see more device-independent / specific information in techniques.
Action KK: Review public draft and comment on how device info can be / should be incorporated.
Tom: In publishing techniques, encourage people to submit techniques without strictly conforming to the structure of the document.
ISSUE: Should we ask the public to submit techniques.
Andie: I think we should resolve issues w.r.t. the reqs document before we publish.
Sally: I agree with CMN
Loretta: I'd like to have a draft of the PDF techniques in the first public release.
Action Loretta: Produce a draft of PDF techniques!
LS: (Not related to public draft) I think that we should have a subgroup dedicated to techniques. People in the field.
WAC: What about techniques for WCAG 1.0? We still have material to develop for WCAG 1.0? How different will they be?
WAC: When do we want to publish next release of WCAG 1.0 techniques.
IJ: I'd like to see a mapping of wcag 1.0 checkpoints to wcag 2.0 checkpoints in the draft ("where did this checkpoint go?")
Action Wendy: Do mapping.
CMN: Sounds like reqs are a) An introduction explaining work b) A mapping of wcag 1.0 -> wcag 2.0 checkpoints. c) To have existing techniques modeled in new structure. we should publish pending satisfaction of these reqs.
CMN: We need a clear mechanism for submitting techniques. For example, any proposed technique has to indicate which checkpoints it is for in both 1.0 and 2.0
GR: We should include CSS techniques doc in first public release to ensure people understand separation of structure/style.
CS: I like the idea of a date to shoot for.
WAC on collecting techniques: a) I think that part of the process needs to be a stringent testing process. Not just which checkpoint it applies to, but exactly how well it works on which browsers and which ones it doesn't work on. (i.e., document level of support)
JW: I don't think that testing needs to be an absolute requirement for inclusion.
Tom: I think that people need to test techniques in combination, not just isolation.
CMN: I think that testing in every browser is unrealistic. Instead, when you submit a technique, you submit a test case. And we track them.
GR: For test suites, the first step is a boilerplate (where to send comments, implementation details, where to find archived comments).
Action Katie and GR: Submit a proposal to WG about how test suites will be organized. Deadline 20 October.
WAC: We may not incorporate in first draft, but we will include forward pointers to that work.
LS: I think we need test cases for bidi text. I wrote to I18N WG to ask how to do this. They said "do it like this" but the solution doesn't work on current browsers.
Action LS: Submit bidi test-cases in light of Katie/GR proposal for test suites
Katie: My original thought was to set up a test suite and people could send me comments.
Action CMN: Ensure that Katie can publish at the w3c web site.
JW: Proposed - every technique shall be accompanied by a coded example to serve as a test case to determine whether the technique is supported.
WAC: This is combining two topics: a) Contents of first public working draft. WCAG 2.0 guidelines will point to existing techniques. b) Katie and GR will submit a proposal for collecting techniques. We may do some handwaving about how that works in the first public WD.
Modification to CMN action: Work with Katie on DATABASE for techniques and publication.
WAC: We may not have priorities in first public draft.
WAC: What country? Continent? Host?
CMN: W3C Plenary session in February.
Refer to announcement from Wendy
Action Wendy: After this discussion, send email to chairs list about WCAG WG's interest in plenary
Resolved: - First choice for next meeting is last week of Feb at all-WG meeting. - Second choice: alongside CSUN (around 20 march) (It's also Claus' birthday!)
JW: I think that any meetings would be held after CSUN. For the following meeting: - Proposed: meeting after WWW10 in Hong Kong.
Max: We haven't had a WAI meeting in Asia yet, so I think such a meeting would be a very good idea.
JW: I could manage either CSUN or Hong Kong.
Wendy notes plan to meet in Australia in Nov 2001./ (e.g., to sort out PR comments and take vacation).
IJ: I have concerns about meeting after WWW10.
WC: We met before meetings in Amsterdam. I think it went well, so we should meet before WWW10/W3C AC meeting
Max: If we meet in Japan, we could have more japanese participation (from disability community as well as mobile).
Resolved: Next meeting feb/mar. Following meeting may in asia.
WAC: Tentative goal: Nov 2001 Proposed Rec.
DD: I note that AC meeting 2001 is in Sophia. (France)
Break
Q: Can you identify the checkpoints that apply to your technology?
Q: Do you have techs for those checkpoints?
Q: :How would you handle "until user agent" clauses?
Claus: What is scope of "until user agents"?
WAC: That's the open issue.
Kynn: Our goal is to eliminate until user agent clauses.
break into 3 groups (PDF, SVG, server-side) discuss until lunch.
lunch
Jan Richards and Marjolein have joined.
CMN: A handful of things we thought were issues.
Action CMN: Post SVG techniques to the list.
Issues: - Redundancies: 2.3, 2.4, and 2.5 (structuring information) are all the same.
IJ: (General comment about levels of abstraction in requirements - heads up that more or less abstract requirements in three different WAI guidelines. Perhaps the WG should try to establish criteria early on for determining whether a checkpoint is sufficiently or overly abstract.) - How do you link between SVG techniques and other techniques?
IJ: Why type of split is anticipated?
CMN: I think a similar type of split as in most recent draft. The question is where the techniques will reside.
CMN: There are some checkpoints for which there may be general techniques (in core document) and in specific modules (e.g., css) that apply to the SVG module. Issue of linking them together. - Design AT technology-compatible user interfaces.
IJ: UA Guidelines talk about communication requirements (APIs, but not compatibiliy through the UI).
- Issue: What happens in the case like SVG where there are not legacy user agents. How do we deal with that in general?
Loretta: We weren't sure how some requirements fit into WCAG. Most relevant to PDF 1.3, though some relevant to later versions. it's clear that there are some different issues for PDF. "Expansion key control. Provide an "expansion key attribute" for abbreviations.
IJ: In wcag 1.0 checkpoint 4.2 (in 2.0, checkpoint 3.9)
Loretta: This is a new attribute available in PDF 1.4
DD: Techniques should be for specific versions of PDF
WL: Same for any techniques module. - If you have alt text attached to an element, should searches include text.
IJ what screen reader renders may be different from what is on the screen. searches will render in that view.
IJ: Search on alt content covered by UAAG 1.0 Refer, e.g., to 29 Sep draft http://www.w3.org/WAI/UA/WD-UAAG10-20000929/ checkpoint 7.5
DD: I think that the PDF techniques document needs to (a) be specific to a particular version (b) link to the PDF specs.
DD: You don't author PDF by hand; you have to author through a tool. The relationship to the authoring tool will be stronger.
Action Katie/Loretta: Send PDF techniques to the list.
Action CS: Send server-side techs to the list. - Using browser-sniffing is a technique that could be used for many of the checkpoints. Not clear whether that's the right solution. - New Guideline: When multiple interfaces are provided, the mechanism for switching between interfaces must be accessible. .it must be easy to restore defaults.
GV: When different versions of content are available, ensure that the user has access to alternative versions.
IJ: Issue of notification covered yesterday. (don't prevent access to content, but allow filtering)
CS: Some exceptions to proper markup - to support older browsers, you may need to send invalid or deprecated markup. ISSUE.
DB: What if you have content available but not necessarily for display by the content provider (e.g., in a database)? ISSUE
CS: We talked about interface requirements (e.g., high contrast) rather than human physical conditions in protocols.
Action CMN: Look up "constraint-based CSS".
(Jason points to comments on multiple versions http://lists.w3.org/Archives/Public/w3c-wai-gl/2000OctDec/0022.html)
CS Proposals: 1) Guidelines should not be date-dependent. 2) Techniques should be dated. 3) Techniques should be updated on a regular schedule 4) Responsibility for keeping them up-to-date rests with whom? 5) For backwards compatibility, think of browsers in terms of modality not specific versions. .if we do this, does a lot of guideline 6 become redundant or moot?
DB: It's not clear when you claim conformance that you are claiming conformance for certain user agents. ISSUE
IJ: Two comments: - Techniques are dated by virtue of the techniques document being dated. - Open issue in general at W3C about post-Recommendation support for specifications, notably after a WG closes (this is in discussion in the Advisory Board).
WC: Note that we have co-editors for different documents.
ij: dated because in a dated document. open issue at w3c how specs are to be maintained across lives of diff working groups.
JW thank you for your contributions and a lively discussion. it's late here so I'm going to bed.
GV thank you jason for all hours of the night participation.
Issues: - Priority schemes in WCAG 2.0 and impact on ATAG. - Timelines and development plans. if wcag 2.0 contains the same reqs as wcag 1.0, we can probably tell developers that if they conform to wcag 2.0 then you conform to wcag 1.0
IJ: Issue for WCAG requirements - Include a statement about how conformance to wcag 2.0 and conformance to wcag 1.0 relate (or don't relate).
Jan Richards: We'd like to move towards automatic validation of accessibility where possible.
DB: There are some difficulties in automatic validation of some requirements (e.g., don't rely on color alone to convey important information).
CMN: WCAG 1.0 wasn't written explicitly with authoring tools in mind. WCAG 2.0 probably won't make (or shouldn't make) this same assumption and that may affect the requirements.
Marjolein: Allaire tools allow you to edit content and provide support around what is essentially hand-authoring.
WAC: How would wcag change to enlarge audience? Should we even attempt to do this for this version ?
cmn not sure what requirement is. if make wcag requirements now, meet wcag1 requirements. smallest set of tasks to give them. re: how to write the guideliens: responsibility of AU WG to bear in mind what means for authoring tools. from device indie workshop, when you create a spec have an idea of how it will work in tools. important to know how it will be applied. places in WCAG: answer is "ask the author tool can't do it" but it should be an AU WG responsibility.
GR don't give false impression that we are limiting the # of tasks.
tom: will ATAG ever say that it should highlight things it can't figure out itself?
cmn ATAG currently requires that you provide a way of checking. minimum is that you prompt the author. already recognition that there are cases to get conformance, must ask the author questions.
tom: where's the division?
cmn: atag issue not collective.
db: w/in ATAG, the goals are stated as 1. accessible to author 2. create accessible content by default. the by default is WCAG.
lgr for pdf, it is clear that many are only the authoring tool developer. tool must enable the author to do them. helpful to classify those? should this info be attached to the technique somehow? ISSUE.
cmn in ATAG, for a WCAG checkpoint, will say
jr there are 6 relative checkpoints that reference all of WCAG. exponential issue. (authoring tool techs for each wcag techniques)
asw (have an authoring tool technique for each web content techniques)
WC that's what AERT is but for Eval and repair tools.
WC: I get a lot of feedback that the granularity of the current priority scheme doesn't quite work. If people can't get 100% of all P2 checkpoints, they may not do any. How do we create gradations? Or do we just go ahead and say "You must do all of them."
GR: I hear people say that Level-A conformance is not worth anything. I think that users who are supposed to benefit from WAI activity would feel betrayed by a point scheme.
Kynn: I respectfully disagree with GR. picking and choosing is done by someone else, even with A/Double-A/Triple-A rating. choice not made by end-users with disabilities. since conformance based on priority levels, creates an unnatural way of thinking about the problem. There is definitely a dis-incentive to meet triple A. not enough granularity. "all or nothing" I haven't come up with a good counter-proposal yet.
ij: in UA have discussed various conformance schemes. a year ago: conformance based on checklist. that was opposed b/c of comparison of conformance claims. i don't know what this checkpoint map means, there is not a label i can use to understand. A, AA, AAA may not be effective labels either. simplicity in making claims, simplicity in comparing claims is another. we have "applicability provisions" there serve as "flexibility points." e.g., if you do video you have to do these X checkpoints, if not, no worries. WCAG may seem to be "all or nothing" but applicability is built in. e.g. i may only have to do 3 checkpoints. i think there is finer granularity but it may not be apparent.
gv we've been looking at this for 12 years. it turns out that you can't use a point system.
* Ian notes that he forgot to mention the impact matrix! That's where I tripped up.
GV: Point/percentage system tends to leave out certain disabilities. you can have a site that is 90% but not accessible. there are problems. we need to study them.
GV: You end up having to have sets of checkpointsw. is it b/c they don't want to, or technical barriers. we need to study the issue. i don't know how to solve it. the disincentive is, "i will only do things that i get credit for or have to do."
GV: There was a nice study of performance v. best-to-fix. In each case, when people moved to performance-based guidelines, results not as good as best-to-fix.
GV: There may be one piece of what we're discussing that's a problem. We have definitions for P[1-3] and try to map these to reality. there's some hedging in assignment of priorities. .Perhaps (but slippery slope) we need to look at whether P1 and P2 are absolutely important, but watch for what's important but not practical today.
GV: Having a priority 2.5 is really dangerous. .we can add conditional clauses or escape clauses for practical concerns.
GV: We're hearing more and more about legacy. e.g., archives that can't be modified. An issue of considering them accessible if accessible materials available on request.
* Ian notes that this is no different from current situation: -If alternative accessible content available, then that's part of the total accessible. - If not, then not accessible.
CS: Authors require that requirements must take into account the real world.
Tom: You could group checkpoints by functionality (e.g., you satisfy the navigation checkpoints P2).
CMN: From ATAG's point of view, we don't care about WCAG's conformance statement. However, if you change from three levels of priorities, we'll need to rewrite ATAG. If the priority definitions are to be shifted, we need to know.
CMN: I think that the priority schemes are well-defined. reference point when sydney olympic site went to court: issue was not whether it conformed but whether it was accessible. in court, the question is not Level A/Double-A but rather whether it discriminates. Laws that I know of do not require conformance, but say rather that "conform to wcag since we think it's a pretty good assurance of accessibility".
WAC propsals: 1) I propose that we collect issues about priority issues we have for wcag 1.0 (misassigned priorities, etc.). 2) In our first public draft of wcag 2.0 that we keep at three levels. Some problems may be alleviated by the fact that we have fewer checkpoints. 3) Once we have a draft with priorities, we do some usability tests to solve issues that have been raised. s/first public draft/second public draft/
WAC: It's not realistic for us to assign priorities before November. first public draft will not have priorities assigned.
GV: I'm concerned about releasing a draft without priorities. People are looking for continuity. I think it would be better to extrapolate priorities from wcag 1.0 -> wcag 2.0. Tell people that we have brought them forward for continuity and that the wg is revisiting them.
GV: Whether a requirement bothers someone will depend less on its presence in the document and more on its priority.
WAC: I propose that we inherit priorities and for those that are not in wcag 1.0, don't assign new priorities.
GV: Ok.
WL: I'd rather delay the publication of the draft rather than have the priorities be arbitrarily mapped.
WAC: I think it's ok for the first pass. I think we need to track priority issues and address by next face-to-face.
DB: our guidelines are being used. do we really know what it means that people are achieving single A conformance? .I think that usability testing is crucial.
DB: I like Tom's idea for grouping in the Level AA realm.
* straw poll about the proposal to inherit priorities from wcag 1.0 and to reassess priorities, but to maintain current scheme, a disclaimer that priorities are up in the air, that usability is crucial.
* no objections to this proposal.
CMN: So, for ATAG's purposes, this implies that as far as we know, the priority scheme will remain about the same.
GV: I have a request for ATAG: - Document how easy or hard it is to implement wcag checkpoints in authoring tools.
Action CMN: Take this requirement to the ATAG WG - provide an annotated wcag 2.0 with information about facility of implementing requirements in tools.
JR: Some conformance options: hybrid solution a good idea - a) All P1 must be met. b) Some percentage system for P2 and P3 would be good. -substractive mechanism [scribe didn't understand the details.]
Loretta: I think it's good to push decision-making to the WG and take burden away from authors. I don't think that we will have an easy time making photoshop accessible to the blind. We need to address some issues surrounding human operation and limitations.
KB: I also like the idea of conformance based on some categorization. I also agree that it might be useful to separate disability types.
* Ian notes that this has been tried and was not effective due to cross-disability issues.
KB: Accessibility has to have a person in the equation. "This is accessible" loses something since communication is required.
CS: I like Tom's idea of grouping based on functionality. I think technology sorting makes applicability more explicit. he just agreed w/himself. :)
IJ: There's a content=type grouping today. Other types of groupings are possible. I would note that UA keeps the content-type grouping.
Tom: Should testing be part of conformance? (issue of automatic verification of test claims, however).
Break
DB interesting to categorize by disability. when someone do compliance check remind them of who they are neglecting.
WL let's let someone else do that. a disability organization or someone. i would like to have tom take an action itme to specify of priority 2 items that are prerequistie for some p1s.
Action TOM: specify which p2 items are prerequisites for p1s.
CS I like chunking things. it makes it easier to fit features into release cycles.
GR would this be satisifed by the impact matrix?
DB not sure.
CS maybe. to help break up work items, yes. but a cost benefit, the cost is great between 1 and 2. an immediary step between 1 and 2 migth be good. or move more to p1.
cmn don't think we are making the development plan for business. these are the user requirements. people will implement in different orders. the more we complicate, the harder it is to figure them out. i don't think we want to provide more ways of saying that (more logos and levels). microsoft suggested that we have 2 levels (p1/p3 - 1 for access, 3 for ?), others felt only have 1.
KB we need to set up what people expect to use as an implementation plan. choose one of 3 options minimizes additional steps they may take. we don't say use as many as can. that can lead to confusion. to too high of a bar. we're not saying this is how you use it, but how conform to claims.
WAC: Show of hands for who wants to discuss conformance/priorities? are there other topics before we close at 5pm?
Katie: Gregg, when you were saying something about legacy systems (old ones) not having to be adapted unless asked for, is that a request to put that in the document?
GV: Two points: a) To echo a previous point, I agree that nothing is blanket accessible. .we're not declaring something to be accessible, we're saying that if you don't do some things, you will create barriers. b) Is it ok to provide alternatives on request? we may not have define this since this may be an issue for policymakers. I'm not sure that this is our problem - to talk about how to get around a regulation.
Katie: That's what gave people in the US a heart attack - the old 508 didn't account for this old legacy content. c) Don't just think about the laws, think about the courts.
* GV leaves
Tom: I think that a tutorial would be useful for input as you design, not after the fact.
IJ: I think that's the role of the tool.
WAC: Not clear what's EO and what's for WCAG.
GR: I don't think it's our role (or EO's role) to guide regulatory bodies in theoretical decisions. I'm troubled by the idea that you could claim accessibility by promising to make something available that's accessible on request. People with disabilities may not have any idea that they can access alternative versions.
IJ: Does "I'd like to search through all of your archives" count as a request ?
CS: a) With conformance, I still like the idea of breaking the requirements into smaller chunks. If you can give people small achievable goals, people will do them. b) The use of testing that is not code-level (e.g., can be used with a screen reader) will help in meeting legal requirements ("it has to be accessible to this or that person"). we only provide means for testing some coding standards. Some ideas for chunking: a) Content type (current status) b) Functionality c) A fourth level (since A seems too little, AA too much).
IJ: There is no ideal chunking. .The WG will always have to make arbitrary decision. We need feedback on the levels chosen for WCAG 1.0. There will always be people who don't want to satisfy any requirement.
Kynn: Proposal to send a questionnaire to the HTML WG.
Action Kynn and Marshall to write a questionnaire and submit to the WG.
Tom: I think that W3C should sanction some navigation bar markup/formatting for known beneficial navigation.
SH: Short point on conformance - I like the addition of another level, but don't like grouping by disability level.
Loretta: Thanks to everyone!
KB: I think it's important to remember in the future that we're all here to get something done. What we're doing will eventually have the result of increasing accessibility and we need to continue to focus on that.
DB: I think that categorization by disability has risks, but we need to keep a human face on the guidelines. Make people realize that people are impacted.
Marjolein: I think ftf meetings are productive and It's good to see faces.
IJ: UA GUidelines to last call.
Action WAC/WL: Review UA Guidelines 1.0 and coordinate on behalf of this WG.
WAC: I look forward to next face-to-face. Please don't forget your action items! Please keep up the momentum.
Adjourned
$Date: 2000/11/08 08:27:11 $ Wendy Chisholm