JW not only issues with techniques, but how to track issues.
GR I have XHTML checks to add to WC's draft, but they are trapped in my out box.
Refer to http://www.w3.org/WAI/GL/2000/05/wcag-techs.html
JW This document shows that the approach we discussed last week is a good one.
WC at WWW9 authoring for mobile computing was a major theme. There is the need for an authoring philosophy and authoring tools so that authors don't go insane trying to create content for everyone. People want to derive multiple presentations from one source.
JW also Internationalization group. do they have guidelines?
GR one of the other issues at www9 was the intersection of accessibility, usability and internationalization. There was a guy at Helen Petrie's workshop on Monday that said that an issue that many authoring tools that output Japanese use HTML 3.2. They also used summarizers for content on mobile phones. There is a convergence with mobile.
JW And the relationship between mobile, accessibility, and internationalization should become stronger as these continue to converge. The accessibility community has an important role here. We can contribute to the common understanding of how one can author to meet these various requirements. The process of abstraction could be a benefit as it might identify authoring strategies that meet these various needs. This also gets at the processing model I discussed in my e-mail from yesterday. One could group techniques per technology and bring together those technologies that will be used in combination, e.g. HTML and CSS, or XML and XSL. The process of transformation is under user control either by virtue of the user having a style sheet and receiving the markup on the client and applying the cascade or a transforming proxy server. The overriding principal is that the content must be formatted or transformed to meet the requirements of the user and the device the user is employing. One role for the guidelines could be to specify the processing requirements - from source to destination.
GR are you suggesting a processing module or process and interoperable?
JW something along those lines. there would be a general understanding of the way in which the material can be processed to meet access requirements as well as other requirements. Source content with semantics in the markup that gets transformed into formatted output. It might go through intermediaries (FO's), but regardless of how done it is under the user's control.
WC so how move forward?
JW think it would be at the guidelines level.
WC do you want to draft something?
@@JW draft a comment about how the technologies fit together.
JW you had tried to apply checkpoints to every technology when in fact some are complimentary.
WC any way to create general principles instead of documenting all permutations?
CMN I would like to continue the exercise of generalizing the guidelines.
JW GV is working on. Also, last week we discussed 3 levels of information. High level guidance, technology-specific checkpoints, then technology-specific techniques.
WC next steps then? should i continue working on other checkpoints? The generalized checkpoints worked very well.
JW yes.
WC other technologies? MathML?
CMN would like to. Try to work with Marja.
@@CMN and MK checkpoints for MathML.
WC interested in DOM.
JW anyone want to attempt DOM?
CMN way you would use DOM in languages, like SVG-animation.
JW there are some that pertain to user interfaces, perhaps those should be considered in relation to DOM and Forms.
WC scripting and changing the DOM.
JW if there is a client-side programming languge, and manipulating document content, the same requirements apply to applets. By the way, we need to work on our terminology to distinguish the 3 levels effectively.
GR I'm not sure what we're doing breaking out into technology-specific modules. You can't use XML without XSL. Should we demonstrate the technologies rather than hard and fast modularization. I tried to be as forward and backwards looking as possible. We can't deal with these in isolation.
CMN one approach in ATAG-TECHS we have some techniques that are specific to a language or a type of tool others are very general. It gets to the point that to manage it we need to look at the underlying structure of the document.
JW yes, that's what we're trying to achieve here as well. It is important to have a concept of how the content will be processed after it is created. Some techniques will cover a range of technologies others will be very specific to one or another. I thoughts that's what we were moving to aim towards.
GR It seems impossible to discuss HTML without discussing style sheets.
CMN that's jason's proposal.
JW yes, that would be a serious mistake. we have to discuss them in combination. other issues with checklist?
WC summarizes issues with issue tracking.
@@JW take issues of ETA to WAI-CG
GR also take mailing list archive.
CMN that is being dealt with next week.
TN and registration process.
CMN that will come later. there is an issue with resources.
@@WC ask Jon Gunderson about UA - can we install it and use it?
CMN has anyone used bugzilla? developed as part of mozilla project. redhat uses it as a way to keep track of stuff in their systems. not sure if it is accessible.
TN i had an outstanding action item to review Techniques navigation and it looks much better.
WC I would like people to check out bugzilla.
@@JW, GR, WC check out bugzilla as potential issue tracking tool.
@@JW search for other issue tracking tools.
WC What do other companies use?
CS proprietary.
DB there are some commercial products.
CMN history behind ETA is that we wanted an issue tracking system. Decided that none of the available software was very great.
DB does Linux ship with something?
CMN might be bugzilla.
JW when we set up a system do we try to compile a list of oustanding issues or start from scratch and ask people to submit new issues.
WC there are 17 open issues for techniques, most of them are still very open. issues for guidelines are mostly dealth with.
JW can we close some of them on the list.
WC sounds good. also need to address cognitive and learning disabilities.
JW we will have a teleconference devoted just to this topic. we are working on scheduling that.
CS Another issue that I would like to address, "What are the minimum requirements for browsers?"
JW earlier we addressed the issue of device-independent guidelines and relation to mobile, I18N, etc. That is an interesting place to address those assumptions. To ask those other communities their thoughts.
CS Another piece of it is the prohibition against scripting.
WC no prohibition.
CS there are instances where it takes a lot of work and duplication of work to make scripts accessible on script-capable and script-incapable browsers.
CMN this gets to Greg Gay's point. We should figure out what is the thing that we believe is out there as the deployed browser and make that explicit. Then we can say, "this is why we do or don't say provide a substitute for forms." There was a time when forms were not readable and we needed to supply a phone number.
CS the other problem is the "until user agents" clause. How many user agents have to for this to be satisfied.
CMN yep.
CS JW, your point about goals of the guidelines, perhaps i haven't read the introductory material, I don't think all of the assumptions have been stated.
JW it says, "this is inteded to make content as broadly accessible as possible. focusing on people with disabilities, but there is a secondary goal for making the guidelines applicable for authoring for a variety of devices."
@@WC send issues from techniques doc open issues to the list.
$Date: 2000/11/08 08:30:15 $ Wendy Chisholm