Some issues:
CMN: I've used the guidelines in two situations and found them difficult to apply: graphics and multimedia. For example, in the case of SVG, a lot of the checkpoints (e.g., mark up quotes, etc.) could be generalized into "use the appropriate markup". The other place we've applied them: the Authoring Tool Guidelines (ATAG), which reference WCAG requirements. For authoring tools that are not HTML authoring tools, there are a number of gaps. My question: what can be generalized? This would shrink the guidelines, but push some information into the techniques document.
JW: Goal of this meeting is to produce a first draft of a requirements document for the next version of the guidelines. Wendy will be editor of the reqs document.
RN: I've been doing a lot of macromedia work. One thought I have on the usability of the guidelines is to create sub-checkpoints for more specific information. This would allow us flexibility in changing priorities. There's also a lot of confusion in the "until user agents" clause. I think that this clause should be moved to the end of the checkpoint text (leaving the key information up front). Also, "until user agent" checkpoints should be priority 3.
GV: (Summarizing) Have a general checkpoint, then more specific subcheckpoints?
RN: Yes. Don't assign priority to the "top layer" of checkpoint, but to the subcheckpoints (where there are some).
WL: In the process of making more general, be careful not to increase the density of the document. I'd propose that we not retrofit our ideas to existing guidelines and we start anew.
WC: (Addressing RN's point). The sub-checkpoints sound more like techniques to me. If we have two levels, I think that will confuse people. CMN's suggestion is that many of the current checkpoints should be techniques. Are you suggesting that we prioritize the techniques?
RN: In essence, yes. I think it's difficult to generalize a priority for a sweeping checkpoint.
GV: Beware of the effect of generalizing: ambiguity that may confuse readers.
LK: To handle objects like flash objects:
DC: It's not a new issue that the checkpoints encompass several different scenarios (This was the case a few years ago). The question is: what's our audience? What's our goal? If the goal is to dictate implementation methods, then we should do something like what RN is suggesting. How to design checkpoints that apply cross-technology but that remain specific enough to avoid confusion?
DB: There's a flip side to the issue of applying the guidelines to non-HTML technologies: what about HTML that's not used "on the Web", but rather for user interface components?
CMN: In generalizing the checkpoints, my vision of how it would work:
AG: Agenda question: the question seems to be - how to make the guidelines more usable. RN has said to be more specific to allow quick verification that I've met the requirements. I have a list of unsolved problems:
I think we need to consider which problems can be solved, and if not currently fixable in the guidelines, what W3C can do.
AG: To move forward, network people's talents. People with academic talents should analyze and create a shorter list of more general principles (keeping examples of Web sites that work since they adhere to the principles). More real-life examples and connections to current practice will be useful. At least in theory, I think we can describe life at multiple layers of abstraction, and even if there are more layers, you can pick the area you're interested in, and you would find more easily the techniques or solutions that are more appropriate for your needs. You end up with fewer checkpoints that apply in your particular scenario.
Another idea: a performance axis. Navigation breaks for the visually impaired user when orientation is not there. The idea that the structure is explained in words is one performance axis. This is not the sole criterion for all users. But you can articulate that and test for it by focusing on that performance variable. We may not want to go for a "pass/fail" score, but consider in terms of performance factors. This will help us do checking on a category-by-category basis.
GV: One thing concerning me: this is moving towards a problem Trace is facing in trying to create guidelines for everything. For some devices, you can't talk about them easily. Some things are necessary and some are sufficient. It can turn out that there are different solutions that are sufficient. However, if they are mutually exclusive, then there's nothing that's necessary. This implies that there would be no priority 1 requirement. What concerns me: you're guidelines must be usable without vision, without hearing, and you have nothing left at the guidelines level but high-level performance. As soon as you do this, you run into the problem of the reader having no idea of what to do or when you've done it.
GV: Another strategy: whether we're talking about accessible Web pages or accessible Web sites. Many companies are now serving different content according to the capacities of the client software.
CS: Al said a lot of what I wanted to say. I think we could have high-level checkpoints that look like the themes. Then lower-level checklists that are language specific. This would make the guidelines more modular as well as new technologies evolve.
GC: If the guidelines are too general and require a lot of techniques documents, it becomes more difficult for the reader to consult. We could use a database backend and instantiate the guidelines according to the markup language. Entire paragraphs, sections, or examples, could be dropped or added according to the markup language.
IJ: Live document good idea, but one (full) version needs to be intact over time.
AG: I'm not sure whether the data should be entirely static to best serve the community. The counter-example is IETF's "standard one" (which comes out every 6 months).
DC: Accessibilitly is creative, not methodical. W3C would never come up with techniques for what's required of an accessible user interface. Developers want a checklist, but I feel that this doesn't suffice unless the developers are cognizant of the issues. Give them a fish, or teach them to fish?
JW: (With chair's hat off) I think that there is an important tension between the generality of the guidelines and the checkpoints v. the specificity of the techniques. Obviously, the question is how to organize and manage that tension. Today, the guidelines are a (stable) Recommendation and the techniques are a Note, which carries less weight. So the question is: what are the principles that apply to a particular technology in general v. the access features of a given specification. One way to analyze the problem is to consider the different types of content involved.
KB: One of the main problems I've had with the WAI guidelines has been the lack of awareness of the audience and how we can understand what the audience will want from the guidelines. For WCAG, we have a number of possible audiences (authors, authoring tool developers, user agent developers, etc.). Web designers out there on the front line need to understand the issues, but the WCAG doesn't speak to them. They're not organized in a way that speaks to those readers. I think the documents are great for me, but that doesn't suffice. The approach of having multiple views (by audience) is a good idea, but doesn't answer the question of who the audiences are. People can understand the checkpoints, but have to dig deep into a number of documents to find the answers to their questions.
RN: What about non-W3C technologies (e.g., PDF) Do we have contacts with Adobe?
TN: For PDF, we are working with Adobe and T.V. Raman. We are working on a document about accessible PDF, but not done yet.
RN: I think we need an executive summary that explains what the document is about (not using the word "Abstract"). Another comment is about examples: I think that any examples not link to live sites but be quoted in the techniques document. I agree wholeheartedly with Kynn's comments.
GV: Reminder: this WG writes the reference document and the EO WG is responsible for producing some of the material that's being discussed here. I fear that the document will either become extra-large or extra-generic, which will scare off readers. People don't have the luxury of considering the issues.
MU: From a policy standpoint: The State of North Carolina is looking for ways to improve accessibility (as we move towards e-govt.). We are seeking guidance on how to get this done. WAI guidelines are pretty comprehensive. But there are three audiences: policy makers (and an executive summary would be very useful here), designers (the guidelines fit well here), implementors (and the techniques document is for them). I think you need a balance between generality and specificity.
WC:
CMN:
CS: I've had a difficult time applying the guidelines to our site. A number of checkpoints don't apply. I don't have a resource to verify that what I've done (as techniques) works. I would like to see a general breakout of the concepts. I found it difficult to meet needs of many types of users at the same time. I'd like to see some educational material geared towards developers. What do I do about the fact that I have to support IE3? By breaking the documents into views, with an overall conceptual table of contents, would make it easer for me to understand what I'm trying to do, and then to do it. Also: it would be useful for developers to have a certification body. Who would do this?
AG: Back to the fish metaphor: After you state the general principle, the next layer of expansion is not the code example, but the evaluation techniques. The code examples would all be instances of coding designs. The method for checking the rule is the intermediate layer.
AG: I'm fascinated by the emergence of portals on the Web. The policy folks need a process, not just a specification like we have today.
AG: Cynthia, to get your techniques into the document, just send ideas to the Working Group. You will get feedback. The WAI needs to figure out how to be a catalyst for how this can happen in general.
AG: There was an appeal for a Web site design-level view. I don't think this WG has the resources to answer that question - this probably has to come from designers.
TN: Comments on the current guidelines: I'm nervous about making the document too abstract and slim that it stops being meaningful. I think that HTML is still what most people can relate to. A possible transition: use HTML or some other pseudo-code to illustrate the concepts. For example, what does it mean for pages to transform gracefully?
LK: There is an idea of performance-based testing. User testing has a lot of problems. For the case of the Web, could we come up with some reference user agent (e.g., Lynx-me on steroids). There is subjectivity in this approach, but there are already judgments required in today's guidelines (e.g., applicability of text equivalent). I think we should consider testing with this type of user agent. Concepts become more obvious to people when they see the results, say, with Lynx-me. People may not understand as quickly just reading the guidelines.
WL: On the question of the audience: we're talking a lot about popularizing the guidelines. I think we have to devote our attention to creating something that our audience can use. I think our audience is the popularizers, not the implementors. I think EO should do the work of propagating the word, and this WG should stick to exploring and clarifying the concepts. I think people trained in doing executive summaries might do a better job than this WG.
GR: If we move into modular, general, etc., I think we should take a stab according to the model outlined by Charles: break out concepts, then next layer by markup language. I also support test suites and the ability for people to annotate them (make comments about what doesn't work in a particular setting, or providing better techniques, etc.). This will lead to more realistic techniques.
JW: There are several levels of abstraction being proposed. We might have another type of conformance to a techniques module. If applied, the module would be a sufficient (but not necessary) way of meeting the guidelines at a particular conformance level. Someone might apply the module without having to read the more abstract layers should they not wish to. You could thus (1) apply the guidelines directly or (2) apply the module that would contain "approved" techniques.
JW: To accommodate evolving technologies, we could also modularize the checkpoints (e.g., scripts, forms, etc.)
KB: It sounds as though we're saying that our primary audience is the EO WG. Is this correct? In some ways, we are saying that that WG or some similar body needs to translate our work for the "masses".
GV: I think the answer is that we are not writing it for the EO WG; we're writing it as the definitive document. For other forms of the information, we need to coordinate closely. I think this WG's charge is to produce the definitive document.
KB: If that is our audience, we still need to ensure that we can meet the needs of our audience.
DC: There must be something in this California air that's giving me flashbacks: we've already had to address these issues with Bobby. We got email daily asking us whether a particular site was accessible. People want "yes or no" answers. But I think these are difficult questions to answer without context: with what? to whom? Trust me, I know the answers are not clear cut.
IJ: Why is this document different from the HTML spec? We don't provide too much educational material as this is left to the rest of the world. Why are the WAI Guidelines any different? They may be (e.g., for reasons of policy implications), but can we identify what makes the document different and focus on that?
GV: Other open issues? Please bring them to the table at the front of the room during the break...
/* Break 11:10 am */
GV: Some requirements issues:
GV: Please make comments in under 20 seconds...
CMN: Shorter.
JB: Two documents - one should be shorter, the second longer and more detailed.
GV: How is that different from today's split?
JB: The short one today isn't easy.
KB: I don't mind the length if the audience and goals are well-defined.
IJ: Three pages. Act as executive summary and starting point for more information.
AG: I think this is a design problem we can resolve elsewhere. If we migrate the HTML-specific checkpoints into the subordinate document, you'll get closer to JB's model.
DB: For usability/testability issues, the checklist is a good size.
JG: Clarification: the short easy is because policy or organizational requirements need to be able to point to it. They can't today because it's too complex for them.
RN: Short-term / mid-term / long-term scope of checkpoints need to be considered (variable priority over time).
GR: I think we need two normative documents (one short, one longer). But need techniques according to markup language.
GV: summarizing: one short (normative), one longer (normative), both abstract.
IJ: Warning: increased number of documents increases the risk, that people won't find information.
WC: This is just a usability issue.
AG: GV's summary went beyond length. I think we need to come up with deliverables that are two views : database view and list of documents view.
GV: (Please read minutes to ensure that your comments are correctly captured by the scribe...)
CS: If we have multiple views, we need to be able to print the whole thing or download the whole thing.
GV: Consensus that we need something shorter followed by something longer.
CMN: Spec-reading developers.
CS: Developers, designers, and testers.
MU: Policy, design, and development
KB: Interpreters - people like EO.
DC: Innovators and integrators (those not of the choir).
TN: Govt. depts. who commission accessible sites.
LK: Technically competent lawyers.
WL: Expert witnesses
KB: Educators and authors
GR: We can't be all things to all people. Need to pick our goals, then how we communicate that to specific audiences.
Guido: Managers/executives
WL: Activists
CS: Make it possible to build accessible Web sites.
DC: Full adoption of the guidelines.
KB: Defining what makes a Web site accessible.
CMN: Full adoption should not be our goal entirely. Adoptability is definitely a goal.
GV: Testability, safe harbor. Allow an organization to look at the guidelines and know that they're "safe" by meeting them.
JB: KB's comment would be the core of the requirements document for the deliverable guidelines. (to CS:) There are other conditions for accessibility other than what this document would include (e.g., user agent guidelines).
CS: I'd like to be able to have this document and use notepad and build an accessible Web site...
MU: Must be usable by industry and government.
TN: A blend of approachability and readability across audiences.
GA: Effective communication of accessibility guidelines
WC: Ensuring that tool designers can understand the requirements.
GV: Unambiguous, interpretability.
WL: Provide a reliable destination for links from other WGs (e.g., ATAG). Stable reference material.
JW: Exacting, work from general to particular.
AG: The next revision should have more accuracy or authentication behind the content. Identify more clearly what works and what may not.
LK: Measuring how much the specification is being implemented. Which of our requirements have had a concrete impact.
GV: Note that outside the US, browsers often take 6-9 months to be localized.
DB: At least MS simultaneously ships I18N versions...
JB: In some MS products, there has been a major lag in implementing accessibility features in localized versions. WAI anticipates talking to localization managers in Europe.
Leanne: Also, following AG's comment, "why" something works or doesn't.
CMN: In regard to "being able to do things", I think that this WG needs to specify the requirements that users have. Even if we don't have an answer, we still need to describe the problem and whether the need is being met.
DC: Issue boils down to: "for whom, with what?"
AG: I don't think you can organize what we need to cover into a one-dimensional stack of layers. More like a mass of frog eggs. DC has suggested there are at least two axes: who/what. The other comment on layering: we've talked a lot about a stable description of user needs. I believe that the guidelines (both WCAG and UAAG) has this. To complete the picture you need to look at interacting with the Web as a process. We've given one view: document-based. We've not addressed process as much. Object-oriented is closer to capturing both, but doesn't capture both, so you'll still need two views.
RN: Where do we want to go now? In six months? What are our priorities? If we have this requirements matrix, this would explain where we're going and why.
GV: Reminder: priority levels based on user needs, not "do-ability". Some people have suggested that the priorities be translatable more easily into mangement terms: what's the most important that can be done today (priorities would shift over time). One issue to note: we need to revisit the priorities and whether "do-ability" should enter.
RN: Some organization should create a conformance matrix for Web review.
CMN: Easy navigation among layers. Orientation within a given layer.
GV: And to know that there is another layer.
MU: What are we trying to get out of this dicussion?
GV: We're harvesting thoughts about document structure.
GV: Is there consensus that we should think in terms of layers of abstraction.
AG: I think we have on the floor the right answer: we want to be definitive, we want to be definitive about what's do-able. The question is not where do we layer, but what is the scope of our deliverable.
MU: Yes, aren't we just building a scope statement? If we build a mission statement, then we can address solutions appropriately.
IJ: Refer to XML Activity's requirements process. Not sure how succesful they are. But the process describes how the requirements document evolves over time.
JB: Reqs documents don't get created in one day. Needs to be circulated among other W3C WG's and publicly as well.
GV: Note: no "decisions" made today - proposals from today's meeting will go to the list.
CS: I think we are looking at a gelatinous pool of data. We need to apply different views: audience, backward compatibility, user needs, etc. A static document will not meet all needs and readers need to be able to apply a filter dynamically.
AG: I think that today, we would have consensus on the range of questions we would want to address. I prefer supported views over supported layers.
DC: To answer the original question: no. People are looking for a line in the sand and it is difficult to draw.
TN:
GV: Could simply present different layers by chapter.
GV: The results have to be simple. The Quicktips have saved us on a number of occasions. We need to make the document more comprehensible.
JW: The different layers of the document set need to be linked. The question that hasn't been considered entirely yet: should the layers be independent of one another? Should one be able to read the techniques document on its own without having to read the guidelines? Or vice versa? We need to consider not just the layers but the amount of independence between them. Should a testing layer be readable independent of the guidelines themselves?
/* Lunch 12:30 - 13:20 */
JW: How to make the document most useful to people?
DB: I support the database approach: allow people to filter and search according to their criteria.
WC: One issue: You can't build policy from a dynamic database.
IJ: I don't think this is an issue if you are only talking about a tool to filter out (reduce) information from a fixed set of data published on a particular day.
GR: I think that we should modularize techniques by W3C Activity and related activities (e.g., IETF). Allow people to get other views as well: e.g., implementability. The two "normative" documents should be as static as we can make them (addressing concepts of accessibility). Provide different views through the techniques.
LK: Simple pages are easier to make accessible than complex pages. Pages seem to scale similarly: basic stuff then layout then scripting then multimedia.
DB: The checklist is useful; a tool (e.g., form) for dynamically filtering (e.g., info about tables) would be even more useful.
DC: Why don't we look at the guidelines as we do legislation: the guidelines are like laws and the techniques are regulations (or case law?)?
WC: We don't have a judicial system...
WC: On testability: complexity is a good axis for testing, as well as browser support. I'd like to look at the the US Mint requirements test matrix.
CS: We use a database to store test cases. Individual testers go through and evaluate them. The results are put in a tracking database, they are prioritized, developers fix them. There's a standardized way at MS to turn a spec into a test suite. The checklist is a good place to start, but it's difficult to translate today. If segmented by technology, it would be easier to turn into a test suite.
WC: Note that recently, techniques split into different modules.
CS: There are also server-side techniques that may be used to solve some of the issues. The guidelines don't seem to address server-side solutions at all. Except for content negotiation.
WC: Yes, we need to cover in our tests that these are options.
RN: We do a lot of server-side validation (e.g., for forms). But also, we would use javascript for mouse-overs, etc. Would "form" vs. "dynamic" be a reasonable split?
JW: One way to approach this question: define what information is expected for each guideline and checkpoint. One could develop an XML DTD to express this (along with an XSLT document to transform it). Another issue: the extent to which it should be possible to test (automatically) conformance.
JW: In the layering of the various documents, a specification of test conditions that must be met (e.g., by different markup languages) could be a useful layer.
WL: I think we should not forget to focus on the content, not just the presentation and usability of the document.
MU: Need to consider usability based on readership. E.g., for developers, design for solving specific problems. A shorter version for policy makers.
WL: It should be done. We shouldn't do it.
WC: Need to take back to the ER group that technologies other than HTML not being handled.
RN: Quantitative v. qualitative testing. LK and I were discuss this last night (e.g., appropriateness of alt text).
GA: Need to do usability testing with a suite of tools (e.g., screen reader). Allow people to send URIs to a service to ensure that documents are tested in a real-life situation.
GR: Need to provide a forum for people to propose solutions to problems and ask for comments. This loop would make the techniques stronger. The ERT is HTML-centered (Wendy), but this was a compromise to get this document out the door sooner than later.
JW: Need to coordinate any testing with ER WG.
HB: Are people aware of what we're doing in the EO WG? We have Danish guidelines encompass several components: WAI guidelines, validity testing, usability testing. We have a user group to help with testing, provide some testing services. (Note: no sites that have come to us have fufilled all the criteria).
RN: When dealing with testing, some questions that come up: what user agents do you use? I would personally go with a target market. But with ecommerce, not all user agents handle well. I think that EO should provide snapshots of what pages look like when rendered with different browsers. There's good shock effect in comparing the results.
DC: The Web as a whole isn't very accessible. The guidelines needs to be easy to understand after one pass.
DB: A point brought up by Heather Swayne: the WCAG requirements are also being used by ATAG readers (authors v. authoring tools). I'm not saying that we need to change the guidelines, but people developing authoring tools are having a tough time beyond what authors need to understand.
CS: I think we need to say for conformance on which user agents the author's content is being rendered. This would make it easier for authors to develop and test their content. If we allow authors to say "this content is usable on these 7 browsers", we will go a long way towards getting authors to buy into the guidelines.
WC: I also get this question: "I use front page to create HTML. What do I do?" I don't think this is under our jurisdiction; this is the responsibility of the vendor.
WC Summarizing some requirements:
GR: You need to have "aural snapshots" if you have visual snapshots of how something is supposed to render.
GR: I have a problem with guidelines that refer to specific user agents. Our goal is to show people how to use the accessibility features built into markup languages. It's up to the UA manufacturers to support these features.
DB: If a site is claiming to conform, can it qualify it to be "we conform when used with these user agents".
DB: I think it's unreasonable to have a test for every checkpoint, but I do think every checkpoint has to be testable.
CS: I agree that it's up to the user agent vendor to implement the new standards. However, I think a cutoff point is useful, e.g., to make it easier to have a short test pass.
GV: This is a crucial point - proliferation of browsers and tools we're trying to relate to. W3C, I don't think, will pick and choose specific browsers. One barometer we used: is the page accessible using readily available technology (e.g., lynx, ie, netscape)? In other cases we chose the middle path. But if you do that, you hinder innovation. We need to get authors over the biggest problems, not worrying too much about solving all problems.
IJ: I'm not sure what the cutoff point means. You use the right markup and design to transform gracefully.
CS: Testers want to know what browsers they need to use for the test.
IJ: Which browser does it work on is a business decision, but I don't see how it touches on the guidelines.
DC: The guidelines are progressing as technology evolves. Older browsers aren't expected to support new language features.
WC: I hear that we need a suite of browsers to use for testing. I don't think we need to scope that suite. In the reqs document, we wouldn't put that list anyway. But that we need to facilitate testing would be in the reqs document.
JW: People are discussing testing in two contexts:
I think the former is more important to our requirements document than the latter.
JW: There seems to be broad agreement that where it's possible to have an assertion that would allow to test for conformance, that this should be part of one of the layers of the guidelines.
CMN: I think we're off track a little - the guidelines are mostly about content, but not how the content is rendered (e.g., alternative content). I think that we should provide a test for every checkpoint. If we can't, then we have no business making it a requirement. We could use tests provided by others, but in our work, we need to ensure that tests are possible.
RN: Can we talk about access keys?
JW: Not in this part of the agenda, but in a later discussion (if we have time) to discuss user agent support.
RN: I bring this up since it's a requirement of the guidelines.
MU: I agree with WC's requirements and suggest we move on.
DB: Should conformance claims allow scoping (e.g., with such and such a browser)?
JW: In the current conformance section, the claimaint must declare the scope of the claim.
GV: Cautionary note: if we require a test for every checkpoint, life will be difficult in the realm of cognitive accessibility. There will be places where we say "do what you can". We can't say "do X" because we can't draw that line in sand.
JW: As GV pointed out, testability of some of these requirements is difficult (e.g., using non-text equivalents for text, clear and simple language, etc.). Questions:
GV: Review of email from GV on 19 March. Questions:
GV: Some issues raised by Jonathan Chetwynd (19 March 2000)
GV: Comment from AG: the way we've set up our WGs, some issues may fall through the cracks. Cognitive may be one such issue. If you're goal is to provide content to users with severe cognitive disabilities, then it is not meant to be universally accessible, so where do you go?
MU: In cooperation with North Carolina's dept. of mental retardation, our primary findings have been about navigability. Pulling the content out of most well-designed pages was less of a problem than getting to the Web page. Can a person with CD easily understand how to navigate to the appropriate areas? We need to consider this at a site, not a page, level. Need to talk about "clearest and simplest navigation page". The site becomes accessible, even if the individual pages are not.
/* Charles scribes */
Action MU: Invite interested people to take part in this discussion.
DB We need to frame the issues. So far the emphasis is on graphics not text.
GC This may lead to an attempt to regulate semantics onthe web, which would be a bad thing. Creating portals is a finething, but attempting to regulate the creation of site subsets is not a good idea. An interesting approach could be to research the use of summarisers that may do "semantic degradation", replacing complex terms with simpler ones. This may be outside WAI - perhaps a specialised user agent
DC Couple of comments. Our goal should never be to make content that is equally usable by everybody - that is not achievable and we will always have people who are not catered for and that is the role of assistive technology. One point is we should work at other approaches, new protocols for example. I'd also be reticent to buy into the idea that it is OK for a group to only havfe access to some stuff. I think it is a dangerous precedent. On the other hand in the real world I would not advocate someone trying to make a calligraphy class accessible to me - there is a balancing act here and we need to be careful of both sides of it.
JW What we are adding to the requirements is that there is an issue regarding navigation and finding content. Wehave established the desirability of dealing with the creation of websites appropriate for people with cognitive disabilities in the techniques document.
WL We're sort of ina wouldn't it be nice area. And everyone i have spoken to has no really concrete ideas about what to do. I think it is vain for us to include this in the guidelines, but also absurd for us to just ignore it. We need to figure out how to do this.
JB Bunch of comments:
GA There needs to be a lot of clarification about what is required. SOme issues are good navigability, good clear design. Maybe referring to usability work on clear design is helpful, and benefits everyone in the long run
TN There was a discussion about where navigation bars should be, and the comment was madethat people with Attention Deficit Disorders can get very disoriented by having to make multiple decisions before they get to relevant information.
DB In our guidelines we say "navigation should be clear", but everyone is going to say "of course I used the best I could". That is a slippery one to get into. Someone also mentioned that there are text-to-graphic tools - we should look into these where possible, in the same way as we rely on screen readers.
WC The group has highlighted what we have done for Cognitive disabilities and the argument comes back that the priorities are not strong enough. I don't know how they would feel about the pages vs a site suggestion. There were suggestions that we could use readability tests, word count, as helpful tests. Maybe we need a whole module on design for comprehensibility and use of graphics and so on. This is getting into that kind of area. I'd like to get the designers involved.
JB There are comments on the WAI-IG that have been made and gone unanswered. We are allowing a characterisation of the WG as having ignored cognitive disability. The product of the working group is guidelines, and they are being misrepresented at the moment. WHen that goes unchallenged it undermines what the working group has already done. With regard to scope, I don't think we havea lot of resources to do research - none to do direct research into usability (unless someone hands over a lot of dollars). There's a lot we can do in identifying needs and supporting proposals - talk to Wendy since it's her job.
DC Tim used the example of navigation at the top of the page not helping people with ADD. That is one particular subgroup of the group we are talking about. There are different views - some people are suggesting javascript rollovers help accessibility, others disagree. It is too broad an area and you have to break it down. I don't intend to ignore the issues at all.
GR I think on the GL list the contentions have not gone unchallenged. I think there has to be some action from the GL group.
CMN
JB: I think GR was going towards "come up with something constructive or we are going to walk away". Accessibility for people with cognitive disabilities is not about helping one or two people. If the group feels that the work doesn't specifically cover some group then find a way to solve the problem. A good way would be to bring together people with understanding of the various aspects and work out how to feed it back from there. I get nervous about the idea of thresholds based on numbers of people, since people get cut off for no good reason on that. There is a can of worms called feasibility. It needs to be coralled and dealt with.
GR What I meant by executive action was that a chair needs to pronounce something about how to go on addressing this.
WC (summarising)
WC GR said nobody has come up with strategies that could be included. Anne Pemberton published 4 ideas:
DB Anne said that text is not a universal part of content. I'd like to boil this down. It seems people are suggesting that site owners would have to provide an alternative to text.
WC I don't think that is the implication
DB That's how I interpret it. If that is what they mean you are presenting site owners with an impossible obstacle
WC She clarifies in another email. The need is to have graphics to clarify, not necessarily to completely replace it.
CMN: The feasibility thing is tricky. Our first goal is to find out as much as we can about what problems we face. We have focused on the needs of the end users first. Of the set of possible problems, is there a partial solution? A complete solution? An asymptotic solution? Feasibility in the market/implementation sense is only something we should apply having examined the range of solutions. We can say that it's feasible to solve a particular problem to a certain extent. It must be possible to conform to the guidelines, but it isn't necessary to conform for all content. If we get nobody to implement the guidelines, we have a big problem....
JB: I want to reinforce the approach that we start by looking at the needs of the users and then potential solutions and then trying to make sense of it. I think it is easy to look at particular suggestions and say "this is impossible" but if we can do some additional exploration then we can sort out what makes sense - that's the same way the rest of the document involved.
GV: The perfect synthesis:
Look carefully at what we have - we have a lot. And look at the techniques document, and developing it.
IJ We went over the requirement for images for a long time before the 1.0 was published. I am not sure what is different since that discussion.
CMN: We've had a lot of push-back. People have interpreted the guidelines as saying "Put up a text-only site and you're accessible." That's not the WG's attitude (text-only is not satisfactory). We've arrived at that position by working through issues. What's changed for me: I've realized that 90-something percent of the world relies on graphics as a major way of communicating. A small percentage of that group relies on them heavily.
GV Are there any other points to help us move forward?
MU The group should ask for as much information as possible - what problems people are facing, what information is available?
DC In this area more than any other it is hard for the actual users to give data about what the issues are.
WL There's clearly been nothing show up that requires this to be moved up from P3. There's not been anything that shows it is a valid P3 requirement.
GV In this area there is a lot of stuff that moves forward on broad experience.
IJ As a way of moving forward we should go back and look at the discussion we had already and decide whether we have sidestepped issues, or not got to them.
GV We will be revisiting this as a discussion. I don't know what the result will be.
/* Cookie break */
/* Resume 16:00 */
/* Ian resumes scribe role */
JW: Extensibility (e.g., XML) and its impact on the guidelines. Extensibility also to be built into next version of xhtml. Considerations:
JW: Refer to Daniel Dardailler's guidelines on accessibility of XML document types.
DC: I want to start by reiterating an argument I heard from WC a couple of weeks ago on a teleconference: how is our work now different from what we've already done? Will doing guidelines really serve the purpose?
WL: If the new techniques module includes non-W3C technologies, we should include placeholders for everything we can think of, then solicit contributions from people on the list who have worked in these areas (e.g., Chris Lilley for SVG).
WC: I was mostly concerned with SMIL and CSS (since these have access notes already). I was concerned about duplicating work, which hasn't been the case for the XML guidelines yet. The XML guidelines are different enough that it's not clear how to integrate them into the existing techniques document. Should we have a new guideline for designing languages? There's still a debate within the WAI Team about how to incorporate the access notes into the techniques documents/modules.
WL: The reordering of the first part of the document will solve the problem since it will be abstract enough to handle new technologies.
JW: What are the usage scenarios the most likely to be? This is a difficult question since it's about predicting usage habits. However, if we try to set standards, we can hope to affect usage patterns. Finally, trying to specify,for purposes of access, what a UA needs, will provide better guidance as new markup languages emerge; they should be specified as exactly as possible.
DB: I'm trying to understand what we're trying to get at. Won't the basics remain the same?
JW: Want to come up with guidelines that apply to existing languages (and take advantage of existing accessibility features).
CMN: I think that we can get a long way by looking at the guideline-level requirements and the work that Daniel has done. Between the two, you come up with a fairly good set of initial requirements for a markup language and for Web content. In a more generalized version of the guidelines, it seems to me that you would cover the requirements for many types of content in different markup languages. Perhaps the best approach is to start the two in parallel. If, we can provide a single guidelines, that's great (and less work). We may find, however, that according to the division, it may be better off to separate them.
DC: I don't think we should define accessibility for each new technology. We should ensure that each spec includes accessibility features, and to encourage authors to use them.
WC: We can create guidelines that are general enough for new languages (e.g., allow instances of a new language to conform to WCAG, ensure that authors can associate a text equivalent with non-text content, use standard linking mechanisms, allow grouping, export semantics, accessible ui, etc.).
CS: I'm interested in how we can use content negotiation more to provide accessible content without having to click.
IJ: I want to ensure that content negotiation is flagged as an issue: what's the right way to do this (e.g., do not prevent access to content through content negotiation).
JW: Issue of sending formatting objects to the user, not semantically rich enough to allow repurposing. Related issue: server-side solutions (e.g., server-side transformations). Note that this is different from server-generated HTML to compensate for the lacunae of user agents.
WL: This problem is similar to the PDF, which raises red flags.
IJ:
CMN: Formatting objects are a way of specifying the final formatting of information on the Web. There is a valid use for it: standardize what you feed rendering engines. In browsers today, this is magic and each browser may do something different. The problem arises when you ship rendered content and only rendered content. The basic requirement is that you not get final rendered form as your input. We already have some of that in WCAG 1.0, but we should revisit in a more generalized version of the guidelines. The SVG discussion is related to that: final form SVG may be a viable way to serve content to mobile devices (which have less processing power) - you can set up a proxy to translate, after client-server negotiation, semantically rich content into a final rendering form. The problem is when you don't provide an alternative at the source.
GV: There's the copyright issue: there's precedent in the copyright law that people may have, for purposes of accessibility, copyrighted material rendered as audio or braille. I think that the formatting object issue is an important one. We will be seeing more and more of this, notably with SVG. We need to examine how you can build semantics into the format. We have mobile access on our side. There are companies that want to serve rich content and less rich (e.g., to mobile device users). As we genericize the guidelines, this is an important test case: will they apply to PDF, flash, etc.
CS: It sounds like this is a superset of the issue of graphics. How is this different? What more do you have to do?
JW: With a graphic, the content consists of shapes and surfaces, even if represented vectorially (like with SVG). With formatting objects, you lose information in the transformation. Even if the rich version is only provided alongside the rendered version, it needs to be offered to the user.
CMN:
MU: Being able to transmit data across a variety of platforms is important: it's entirely appropriate for us to say that users must have final control.
RN: Re: server-side creation of pages. I don't see a major issue on this. A lot of high-end middleware pieces generate HTML. The "golden dollar" interactive map will use a variety of renderings (including flash). The big issue we have with PDF is the older information that's out there that was never rendered correctly to begin with. As each new format arises, we can add new techniques for it.
GR: Need to talk more about digital signatures and what the signature is about (e.g., legally binding when reproduced in such and such a manner). Need both fidelity and user control of presentation.
JB: The issue of fidelity of documents was raised recently in the Team.
IJ: I propose a joint meeting (e.g., SVG, PF, DSIG, WCAG).
JB: We've made progress lately in communicating to various communities and getting understanding.
Action IJ: Organize such a meeting.
JW: We need to clarify what semantics / structure needs to be preserved (prior to rendering, and subject to user control). This might be for the requirements document.
GV: Site accessibility v. page accessibility. Includes the topic of database-based sites (or sections of sites). There's always a danger that the user may end up with unusable content if the server guesses wrong what the user wants / can handle.
RN: The US Mint is running a high-end Web site. People are trying, on the marketing side, to go after certain markets. These sites have to be rich and attractive to buyers. This is a whole new market that we need to attract - we need to get these retailers to buy into the guidelines. The government has taken the lead, but ecommerce is a huge market we need to pursue.
CMN: The Web site as a whole serves the information. Whether it comes out as one page or N pages is not relevant, except that there is an additional onus (navigation) when you split into different pages.
TN: In Australia, the tax office has gone a long way to make their dynamically generated site accessible. Without navigation tools, the site was totally unusable.
MU: The State of NC just implemented a system for agencies to do purchasing; the site is very dynamic (due to connectivity issues). Using "visual interdev", the agencies were able to use templates to build the table, and build a long description on the fly. [Visual interdev is an MS product that allows you to generate asp pages.]
GV: Reminder - issue of whether we should distinguish pages from an entire site?
CS: There's a movement in the industry to personalize pages. I think accessibility preferences are just another manifestation of this (e.g., news vs. sport). A lot of issues can be addressed by allowing users to choose what they want and that after that, it's magic how they get content.
KB: Yes, sites will be adapting more and more to the user's hardware and software setup. We'll see a lot of work in adaptive interfaces in the WAP area. If the server knows for sure that I don't need something and it sends something that meets my particular needs, then we need to acknowledge cases when it's ok to send something that's accessible to that individual but may not be accessible to everyone.
JW: Some problems this raises:
RN: Sites are no longer generated by one person.
DB: We need to reconsider words like "as a last resort, use alternative pages". People have been creating pages from databases and this WG needs to consider that fundamental approach.
GR: Kynn's approach (artificial set of criteria) is different from something like CC/PP (refer to W3C Note). I think there are some traps and false issues we need to be careful of.
LK: If you're generating two different pages, it will become more difficult to verify (and test) that two pages are equivalent.
FT: Another reason to separate data at the server level: you just don't know what user agents will be around tomorrow. I'm in favor of starting from a single source and generating based on client capacity.
CMN: You need to ensure that users can find a version that contains everything that they need. You can generate nine versions, and the guidelines already allow this approach. People want personalized content and content providers want to give them this content.
GV: Summarizing
GV: We may need a subgroup to explore this issue in more detail.
WC: We have a timeline that needs work, but here's a schedule:
WC: For those who have not rejoined the WG since the new charter was published, please rejoin.
MU: I'll be glad to review the reqs document.
JW: The WG has recently established a "reviewer role" (an invited expert in the WG particularly interested in a given topic). If you can't participate full time, please participate as a reviewer.
Actions:
WC: When's the next face-to-face? Where (Australia??)
JB: What event can you piggy-back?
GV: Comdex? PC Expo?
RN: Next date for guidelines release? 6 August?
JB: Please note that W3C process should not be used to meet a schedule for a particularly regulatory need.
/* Adjourned 17:35 */