Avi Arditti, Doyle B, Lee Roberts, Roberto Scano, John Slatin, Gian
ACTION: Jason write list of issues to investigate, as place to start, in reaction to Roger Gimson's comments
Al: PF group is interested in identifying where things should be a function of Protocols and Formats. We've been looking at the handshake between DIWG and Multi-modal interaction group. Cooperation could be good for producing accessible content. We want to work with you to be sure specs are cleaned up to address these issues.
Gregg: The DIWG constraints are imposed by the UA; the WCAG constraints are imposed by user choice of UA to accommodate needs of user. DIWG may not worry about full-keyboard plus audio only (i.e., blind users). We may be able to contribute interesting use cases.
Roger: We haven't done a good survey of WCAG2 to provide feedback. From my review, there are a lot of good things that any device independent solution should be able to conform to. Jason marked the items that seem most relevant to DI, and that is great. One of the differences is that WCAG objectives is to produce author guidelines for creating content. DI not only illustrates the problems of achieving delivery to different devices, but also looking at added technology that would improve the output. WCAG2 looks great, and I don't see any sources of disagreement except for problems of aligning use of terminology.
Gregg: We may want to produce a combined guideline document sometime in the future. Having two documents that overlap by 98% but use different terminology is confusing.
Roger: DIWG doesn't intend to produce guidelines for authors, since the underlying techniques aren't there for them to do a good job even if they wanted to. To be able to adapt a presentation for delivery to a device, you need to know something about the device capabilities. Even with CC/PP, there is no technology to make device capabilities accessible to code that would do the adaptation.
Gregg: There is work going on for Universal Remote Consoles for creating interface need descriptions where a device or service would describe what it can do or what information it needs. UA would then build an interface to satisfy these constraints. This may be useful information for DIWG.
Roger: There is a deep difference in where adaptation is considered to take place. DI thinks of adaptation happening on the server rather than on the client. That puts a different emphasis on the technical requirements for the adaptation server side. One thing we are struggling with is separating the principles from the implementation where adaptation might take place.When we get down to looking at details, there will be a difference in what might be done locally in a phone UA and what might be done on a server or some intermediary on the network. There will be technical issues in trying to encompass the wide range of delivery techniques.
Gregg: WCAG wrestles with the same issue, with the solution provided at client, server, or an intermediary. We try to specify what to do without specifying how it needs to be done. If you do it on the server, the server might adapt content for the largest PDAs and ignore the rest. For accessibility, they might not support any relevant devices.
Jason: We are trying to write guidelines and checkpoints that are independent of where conformance happens, but when it comes to evaluating conformance, there is an issue of how server side solutions affect conformance scheme, when are two verions of the content equivalent for conformance, and whether there must be a single version of the content that satisfies all the accessibility requirements. All these sorts of problems are up for discussion. Cynthia and Wendy have been reviewing the Authoring Scenarios for specific WCAG issues.
Wendy: In general, our biggest question is whether DIWG plans to create a techniques document for examples of how to do the things described in the authoring scenarios.
Roger: The answer is yes. We are working through preliminary documents to identify new pieces of technology that would be required. We are trying to frame the problem. We will be holding an authoring techniques worksthop in 2 weeks time, then plan to produce a techniques document to capture at least some of the techniques currently used or proposed.
Cynthia: We are developing an XML document (searchable repository) of techniques that could be viewed in a variety of ways. We have a schema, and Wendy and Matt have been working on putting the HTML techniques into the repository. You may want to use the same mechanism to aid people searching for techniques.
Wendy: One advantage of schema is that each technique links to a checkpoint and guideline in WCAG and we could add similar links to DIWG principles. This could be a W3C-wide repository. We are also talking to the SVG group about this.
Roger. Sound like a great idea. DIWG, Rotan and Steve have just started pulling together some scenarios for DI to be sure we are covering the range of problems we need to address. Is there some way to pool the scenarios?
Gregg: Could almost be a case study. If they are in the same format, people can search for different combinations of constraints. Hopefully we can also lay out solutions.
Rotan: In the Authoring Scenarios document, sections 4.3.1 and 4.3.2, there are some examples of scenarios that need to be addressed by authors. These human-accessible scenarios help people under the issues of DI, the impact of the environment, the effect of constraints from the device, etc. We want to collect descriptions of these scenarios. WCAG should become familiar with the cast we are creating for these scenarios. We are trying to create a collection of descriptions that are meaningful not only to technical people like us but also to people creating services for the web.
Device Independence Scenario Repository
Cynthia: We hadn't done that. We talked about who the users are and use-case scenarios, but never made it explicit. I like the authoring scenarios. Making it explicit makes it easier to frame the issues. In our group we have a wide range of backgrounds, so not everyone is familiar with all the user needs.
Matt: When developing the Techniques DTD, I made it as generic as possible. It could be a suitable base for this.
Charles: There is a user scenario document by EOWG. DIWG is aware of this, since you use a scenario from it. Cynthia, are scenarios not only user but author scenarios?
Cynthia: I was thinking of user scenarios. I think there are a few missing for accessibility.
Gregg: It would be good to show the parallelism. "The constraints met by Angela are the same constraints for Tom, who is deaf or blind or has low vision." A lot of times, the scenario described is solved in a way that satisfies other scenarios.
Cynthia: In addition to having these published for others, it is useful for us to be able to say "With the rewrite, I'm trying to address Susan's scenario."
Jason: Al Gilman has been advocating a systematic selection of these, and it hasn't really happened. DIWG has made a good start in that direction.
Gregg: The easiest scenario to develop is Solomon's trap, in which you include 4 or 5 things to make the content device independent, but the combination doesn't satisfy the needs of any user. It contains partial solutions to several different sets of constraints, but no complete solution to any one set of constraints. The scenarios get you away from that trap.
Jason: Areas of collaboration we have identified: Terminology between the documents. The authoring techniques as new technologies move into place, and in the application of existing and emerging technologies. Discussion around the role of client/server/intermediary on the application of content and the effect this has on guidelines and principles.
Gregg: DIWG talks about access as one or more interaction modalities. DI is being able to operate with constraints. But no place is there a definition of what the contraints would be. Scenarios get at that, but not explicitly. For example, DIT2 requires the ability to be accessed by any mechanism. Does this mean if it is accessible by 2 devices, it is accessible? Or any other conceivable device? What is the definition of conceivable? There is a critical piece that isn't defined. Trying to define by example requires an infinite number of examples. Being independent means works with different agents. Is there some limitation on what combintations of constraints should be in the universe I have to cover. e.g. olafactory-only interface probably isn't required. Sometimes people think content is DI because it works with 2 or 3 devices.
Roger: You've spotted where the principles go so far and then stop. We don't have the understanding yet to be able to produce a fuller, more complete, exhaustive descriptions of what the constriants are going to be. The principles are aspirations, which is one reason why we haven't taken that working draft further. The work going on in DI and other groups to explore the issues will lead us to be better version of the principles. It is a hard problem, but crops up in some very practical situations. CSS Media Types - wondering about the difference between Aural media type vss speech CSS, which leads to a deep issue about what the modalities are and how you combine them to create a full interaction. Whether modalities are there for device limitations or user limitations, this is one way to find common ground that might let us expand on the principles.
CSS question (Member only link)
Gregg: It would be interesting to have a group that explores the question of the dimensions of interface.
Jason: The WCAG2 draft breaks up the requirements on content into perception, navigation, comprehension, etc. It sets requirements to satisfy a range of constraints that satisfy the needs of the user/device. It would be useful to have first the scenarios and discussion of what the constraints are, to make sure we covered the significant possibilities. Our aim is to ensure that all WCAG2's assumptions are documented somewhere.
Jason: Question about use of mailing lists for collaboration?
Wendy: It sounds like that will work fine
Jason: It could be a place for more general discussions.
Roger: It would be useful if we at least gather lists of names of people interested in shared issues. For example, if we are going to take the user scenarios forward and share them, would be good to identify people interested in working on that topic. Initially I would propose that we try to identify the topics for collaboration. If we augment this with links to existing related work in the groups, that might lead to people signing up for those topics.
Charles: 1) One scenario for multi-modality is using 2 UAs at once. 2) Concrete proposal for action: read EO document about user scenarios. WCAG should be more familiar with it.
Jason: Agree that we should compile a list of topics and identify those interested in working on them.
Rotan: Regarding the scenarios repository, the collection is made up of individual records to describe devices, users, and usage scenarios. This would be successful if it had 100 or more such records. You can contribute individual records without having to provide an entire scenario. Someone else can construct the scenario. Repository brings together issues. This could simulate debate on how successfully we address the issues raised.
Jason: On the relationship between the terminology used by the two groups. WAI has a glossary project of definitions relevant to Accessibility-related guidelines. it is being developed via the xtech mailing list, to harmonize definitions across the WAI groups, and only to contain definitions used in those guidelines. But it is an important avenue for discussion of definitions to work out a common usage. WAI has stewardship of that project. Within WCAG, there has been some discussion of concepts and terminology to promote clarity and to be sure the document is comprehensible to as wide an audience as possible.
Roger: If there is some way we can augment the glossary (not necessary in the document), then we can extract definitions from the common sources for a document-specific glossary.
Wendy: The gossary question may need to go to W3C management if it is to become a W3C-wide resource, which seems like a good idea.
Rotan: I can build software to programmatical modify the HTML document so it contains forward links, as an example.
Al: WCAG should look for surprises for DIWG assumptions about devices and constraints. For instance, the person with disabilities may use a UA with more capabilities that you expected.
Jason: Do Wendy and Cynthia gave any comments on the role of WCAG's server side techniques work?
Cynthia: There is definitely overlap between server side techniques and DIWG work. A lot of our techniques for supporting multiple tailored versions will be the same as DIWG techniques except the output format might be ???.
Jason: We've introduced issues where there is overlap bewteen the groups. I will take an action to draw up the list of topics for collaboration between the groups. We can always arrange other teleconferences on an as-needed basis.
Roger: Can I highlight 4 topics for collaboration: 1) User scenarios and
Rotan's repository 2) general set of authoring scenarios. Not just the DI
document but are there other authoring scenarios we should encompass form
other groups. 3) terminology and the possibility of sharing the glossary 4)
authoring techniques, and leveraging WCAG work in this area.
$Date: 2002/09/12 23:40:41 $ Loretta Guarino Reid