Minutes from AUWG Face-to-face, 26-27 Sep 03
Attendance
jt Jutta Treviranus
jr Jan Richards
gp Greg Pisocky
wac Wendy Chisholm
ln Liddy Nevile
mm Matt May
tb Tim Boland
cmn Charles McCathieNevile
pj Phill Jenkins
Minutes
Success criteria proposals
jt: goal of these proposals is to clearly separate success criteria (objective measures) from usability tests (addional tests that one could do).
jr: discusses 22 July draft. "Typical author" statements are going to be separated out from success criteria.
jt: Also a "usability override" - trying to influence the author to do the right thing.
jt: In some cases, ATAG is asking the tool to influence the author (who is using the tool). Therefore there are two types of requirements in ATAG: one is "you must do X" the other is "you must influence the author (using the tool) to do Y." However, we want to give the authoring tool developer leeway in how they do this. The tool can not force the author to do anything. Show us that typical authors are convinced of doing this then you have satisfied this requirement.
ln: How much of the process is handed over to the tool. If you put tools into the authoring process, then we are saying "how do we determine if the tools are doing the right thing."
jt: Here we are saying, how intuitive is it to do the right thing. We can't force tool developers to do anything.
ln: This is a subjective test - "typical author."
jr: Proposed text directly following Guideline 4.
jr: 1st sentence: Instead of "the other requirements" say something more specific like "the other 3 guidelines"
Checkpoint 4.1
jr: Success Criterion #1, JR's proposal:
jr: 1. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them must be available to the author at all times during authoring and, at most, one level down in the user interface (e.g. in the first level of a drop-down menu).
Discussion of TB's comments
jr: "the functions that you implmented to meet 3.1, 3.2, 3.3"
tb: Means have already satisfied 3.1, 3.2, 3.3 before this.
jt: Yes, have already met those and this says, "is it easy to find."
jr: edits proposal
AGREED: define what mean by "at all times" (to do)
AGREED: replace "at most one level down" with (@@see Jan's edits)
gp: Is the issue of alerting the author that it hasn't been set? i.e., are they on? If not, the author should be made aware.
jt: Should we add something? (if they are not on, tell the author that they are on)
gp: We've heard from users that they want an "opt-out" policy: accessibility features are on by default and when the author turns them off they have to be alerted to the consequences.
jt: It would simplify things if we said, "it has to be on by default." That strategy - if people turn them off, alert them to the consequences - is good. That would make our job easier. There is push-back that it must be on. Is that likely to cause any objections?
jr: In terms of this meeting, integrate that idea?
AGREED: we should, thus 1 changes to "Functions that meet ... must be enabled by default." and 2 changes to "If the author chooses to disable these functions..." (see jan's notes for complete text)
jr: If "enable" must be near the surface, does that mean that "disable" feature is also near the surface of the UI? Thus, do we want to require how close to the surface it is?
jt: There is enable but there is also the use of the features.
jr: A common strategy in UI is a checkbox in dialog boxes that say, "Don't warn me again." We don't want to see, "provide alt-text" and below it a checkbox, "don't warn me again." Should we explicitly warn against this?
jt: If we constrain the choice of the authoring tool developer too much, we'll get push back.
jr: Does #2 overstep? Is it ok to inform user of thier choice?
jr: This seems ok. We are giving them a choice. We are giving the author a choice.
jr: Do you see these warnings as being very specific? i.e., "You will reduce the number of users of your content...." or "If you turn this off...." or "You will reduce chances of meeting WCAG..."
jr: More general prefered, "You will reduce the number of users..."
jr: Configuration of these done in same place as non-accessibility configuration.
jt: Just configuration?
jr: #4 also relates.
jt: Should include operation (not just configuration) should be easy.
jr: That's covered in checkpoint 4.3. comparison of 4.1 and 4.3: 4.1 = easily available, 4.3 = integrated. Very similar.
ln: One is p1 other p2
jt: p1 - be able to use it and easy to use, p2 doesn't look foreign. Need success criteria for the "find or use" we have focused on "activate."
jr: Remove "use" and let that be covered by 4.3.
jt: That's a p1.
ln: 4.1 is saying, "always be able to find them and activate them." That is different from use, which is 4.3.
jt: 4.3 is that they don't look foreign. If they are easier to use than rest of interface, then that doesn't satisfy it either.
ln: How measure easy to use?
jr: What about a highly technical tool, one that is difficult to use. Thus, won't be able to meet 4.1.
jt: Want to avoid something that is easy to find but impossible to use.
jr: If tool X subcontracts someone to make them a checker, but you can find it easily in the interface. Let them get A. Perhaps this is a separate checkpoint? Clearly available and easy to use are 2 separate things. Also space between easy to use and naturally integrated.
AGREED: it is sounding like 3 separate ideas. Thus, new checkpoint to be proposed. 4.1 - accessible techniques given highest priority, 4.2 - easy to find, 4.3 - easy to use, 4.4 - naturally integrated.
jt: Discussion of priorities. Perhaps new 4.2 is p1, 4.3 is p2, and 4.4 is p3?
AGREED: [4.1 is now 4.2, from here on out will use 4.2 to refer to the new proposal]
jr: Concern that 4.2 is too much about configuration. Move some of criteria from 4.2 to 4.4 (naturally integrated).
jr: on by default, turn off tell author, something about easy to turn back on?
jt: how do we do this - if turning off is easy and turning on is easy ..what happens?
jr: if author has disabled functions, ...
jr: sending file to everyone....
jr: action on 4.2
jt: success criteria changed
jr: some things run in the background..others only when requested eg spell checker background things should be enabled by default and others should be clearly available...
pj: background things should be called active processes...on-going processes...background confusing..
gp: what about states - process on/off ..
jr: looking at 4.2 .."always clearly available to the author" PJ said not all functions will be enabled - eg documentation...spell checking in background and specific. If there is a one-off process, it needs to be 'clearly available' what is clearly available?
jt: what term? on-going process, continuously active? eg spell checker that underlines mistakes..vs one that does a user activated 'spell check'
ln: is activation important
jt: continuously active - on by default
jr: success criteria for 4.2 edited...The checkpoint about informing the author of the consequences of turing off the continuously active processes needs some wording in the techniques to explain what this might mean.
pj: can this information be in the user guide?
jt: it should be a consequence of de-activating it. 'are you sure you want to delete this' type of comment.
jr: the information does not need to be part of the dialogue but needs to be visible..
jt: let's put it in techniques
jt: for user initiated? activated? processes -
jr: "initiated"
jr: What does 'being available" mean? eg you can't check during saving process...so we need to define 'at all times' as well.
jr: editing text....same number of steps as other functions??? other comparable functions?
jt: 'other high priority' functions, commonly used functions
mm: what about a list of functions, on the menu??? has an accelerator key?
jt: could we say high priority functions and define it
gp: screen real estate is precious
jt: could there be a top-level menu for accessibility?
wac: somewhere between SAVE and VALIDATE, SPELL CHECK..? that gives a range
tb: has wording for success criteria for relating these functions to other authoring functions...
pj: needs to be on one of the top two levels but
jt: what if it is in a dialogue box?
jr: only top-level makes sense...
jt: 4.2 done - lunch?
Checkpoint 4.3
jt: new checkpoint 4.3 continuing with the four things but asking how to determine 'easy to use'
wac: integration and ease of use - which is higher?
jr: easier to integrate it so it gets a higher priority?
wac: integration into the tool is more likely to be integration into the authoring process?
gp: intuitive or integrated?
jt: what is the connection between same look and feel and easy to use - which has greater priority? are their competitive? which is most likely to be achieved? what does priority mean?
jt: so what is 'easy to use'
gp: making a connection to what is at fault, making repair tools available, ...
ln: how do we relate the user's skills to this part of the tool?
wac: make it 'as easy to use as the high priority functions of the tool generally? 4.3 is saying 'it shouldn't be hard to do accessibility?'.
jr: but is that degree of automation
jt: do we know where to fix, do we know what to fix, do we know how to fix it?
wac: is the difference between 4.3 and 4.4 that one is about the process and the other about how the tool provides the help you need. What is the spirit of this bit - that accessibility checking should not be harder.
ln: does Excel and Word offer an example...
wac: if we have 4.3 as proposed, does it add anything that is not already part of the whole document?
jr: one of the problems is that we are getting bits that may not be testable.
jr: the meaning of 'look and feel' ----the difference between 4.3 and 4.4 ...
ACTION : JT task for WAC and JT to work on later - wording of 4.3
jt: for now, take 4.3 as complete, and work with 4.4
WCAG Issues
wac: meet together on October 9 on teleconf?
jt: clashes with another meeting...
jr: 20th Oct at regular ATAG time?
wac: combined WCAG/ATAG meeting to be held at 4.00pm on Oct 24th
Usability Override
jt: Notion that you could meet the criteria one way but do a usability test to show that you meet the spirit. Is there agreement that this is an acceptable strategy?
ln: Still a success criteria but undertaken a different way.
jr: Don't let them off the hook
jr: Pass it as help for you but you still have to do other things. Here is something you can do if you really care about accessibility
ln: So what is the reason we are doing this?
jr: The original idea was what if you do not meet the original criteria but you meet the spirit of the check point.
ln: Is the rule you have to do it our way or at least
jr: The criteria are you must do it this way. The techniques are you can do it this way.
ln: we'll accomodate by allowing usability testing. Is usability testing such an exact science that you can do that?
jt: We are going to set up specific criteria - at least 50% have done such a thing...
ln: But the testing is not an exact thing.
jt: The issue is you could do some of those things and miss the spirit of the checkpoint. You could literally meet the success criteria and still not meet the goal. But there may be an author who comes up with a way of doing it that we did not think of. They would not be compliant even though the approach worked.
ln: Why would you do that for technical people?
jt: We're not telling people how to do it. We're doing a usability test that randomly selected subjects, sat in front of the application would automatically select the accessibility path.
jr: If they take WCAG which is done in a very you need this, this this, and they test it and it passes and they didn't do this things it fails. Let's work on this a little bit and see what happens,
gp: Why penalize someone if they achieved the desired results in a fashion the standard did not anticipate?
jr: If people who are familiar with the tool and they would know where to look for an item then that would work even if it were buried 10 layers deep.
Checkpoint 4.2
jr: 4.2 Ensure that accessibility prompting etc.. are always clearly available to the author.
jr: Usability Study "Override";
jr: 6. When prompted to find them, typical authors of the tool are able to locate accessibility related prompting, checking, repair functions and documentation from several representative states of the tool to a comparable degree in terms of speed and efficiency as other non-accessibility related "high priority" functions.
jt: Is it that they can find it, or they are inclined to use it.
ln: In effect you have a higher level criteria. When people are asked to author content they are asked to demonstrate...
jr: We don't want to have usability overrides for each check point. The heart of the matter is not at the checkpoint level. Is it at the guideline level.
jt: There's no way you could do an override on "2" because it's a tool.
USABILITY STUDY OVERRIDE FOR GUIDELINE 4
jr: If found to be true would negate having to comply with guidline 4
jr: Typical users of the tool without external prompting should be able to complete a task involving X% of the content tasks supported by the tool X% of the users successfully use Y% of the accessibility functions of the tool. The output of X% of the users conform to WCAG.
ln: It strikes me that we have a bunch of garage developers we have a problem that they don't know how to define this.
jr: got to the board: Basically we are trying to produce WCAG compliant content
jt: It's generally accessible content as part of the standard authoring practice.
jr: Now and in the future, users are likely to get WCAG compliant. When it comes down to it, we're still testing for guidline 4. The goal is to have accessible content come out the back.
ln: Out the back of that tool...
jr: Out of the back of that tool over a wide range of situations.
mm: If they failed it, they are not going to conform to ATAG.
ln: THey would not be able to advertise those features that do not conform.
mm: Do we want this to be a standard to conform to a la WCAG or do we want this to be a diagnostic. I can take everything but this part and integrate it into my functional spec.
ln: So you're angling against this usability override.
mm: Yes. It sounds... this is how this software gets developed.
ln: I recall something from my usability days that you had to integrate that into the whole process.
mm: If you go into the functional spec then you can plunk this down on the desk and say, "If you don't do this... then Europe won't buy."
ln: The only way to do this with any success was to tie these things to functional specs. I eventually became convinced that this was not the best way to do this. People who have very large complicated products wouldn't do it that way. Simpler products would.
jr: THe other thing is you have to go through Guideline 3 which is a pretty big bar to go over.
ln: THis is like prior recognition. We'll give you prior recognition because you've done all these others.
mm: I think Bob and Phil should look at this.
jr: Yeah, of course.
mm: Maybe it's jus tthe word override for me.
ln: Is it an alternative success criteria, alternative to 4?
jr: To all the other success criteria.
mm: We should talk to Bob and Phil and John Henry
ACTION : Jutta and Wendy are going to look at success criteria for 4.x
ACTION : Add Liddy Nevile to acknowledgements.
ln: And what about meta data. If there's an authoring tool that doesn't produce meta data it strikes me it's pretty useless.
Saturday
How ATAG and WCAG reference each other
jr: Scope of the documents, basically
wac: Where WCAG is at. Web Content Accessibility Guidelines. Sept. 27 a new draft was published. 2003/09/reorg4/4-combined.html Still playing with required, best practice, measure and additional notes. Problem is core and extended. Any sentence, norm or inform, core extended, req. best pract, -- "matrix hell" and we're trying to figure out how to get out of it.
cmn: ATAG point of view, Pri 1, 2, 3
wac: Several proposals on Wed's call. Limited problem is some of the best practices actually provide needed information that supports the checkpoint. Provide as much info and encourgage movement to next step. Too much and they won't use it.
Guideline 4 how we talk about non W3C techs.
jr: Techs are used according to spec. No longer saying only use W3C specs. Saying use techs according to specs. For markup, pass validity tests, use accessibility features, use structureal elements and attributs. Depracated features are to be avoided - must be reworded. This is how we're dealing with that issue.
jr: I notice you don't define accessiblity . You do define features. It's clear to me.
wac: It's going to depend on the technology.
jt: Ther are these multiple proposals. What direction do you think we're going.
wac: Hard to tell. Right now both opionions seem to have equal strength as far as including everything or not. Are you talking about the structue of the document?
jt: Yes, the structure.
wac: I don't know
wac: What we have are --- none of those are technology statements. At the next level we have the techniques
jt: Tech Gtwy relates to best pracs and addl notes in what way? Do BPs and addl notes relate to every single check point?
wac: No
jt: Tech gateway a navigational tool or techniques.
wac: Curretnly intended both.
wac: Techniques is separate from the core document. Ideally what we would like to do is work with working groups
jr: And for non W3C
wac: The org that produced the tech would create the document and W3C woulod link to the technique document.
jr: So ATAG would say, only use technologies for which the orgnasation has provided a link to the W3C
cmn: Does not have to be the producing org. Only use the trechnology for which there is a published technique for each WCAG checkpoint. If whaqt you have to do is nmonstrous and horrendous hacking go for it. If it works good. If however you have a tech thatn no one knows how to do it it won't pass.
wac: concern. Takde for example GIFs. There is not a techniques documents for GIFs. So is the implication don't publish gifs.
cmn: Telling peopl not to produce some kind of format won't fly.
jr: ATAG you would meet ATAG for a particular format. For SVG or produced something else
gp: These things are defined in context of a process. The raw materials may not be accessible but when assembled then the opportunity has to be taken to make the final product accessi ble.
jr: When should you use this guideline document.
wac: Sounds to me that you should change the scope of ATAG. User agent access guidelines took an interesting approach.
jt: Guideline is intended if you have a choice then at least support the format that is the most accessible. That's what we're stating. It is part of the process.
wac: Most of the formats that are working on accessiblity ha ve statements that say they are working onthe accessibility of these formats.
jr: If you have to decide between FLASH and SVG Flash just isn't ther. At some point you have to have a techniques doc.
cmn: I think the basic approach that advocates to be accessible you have to have a W3C WCAG techniques document ....People pick up a particular tool for a particular job as part of their workflow won't cafre, but the workflow could conform.
jr: We could put as many things into one package.
jt: And there is the other scenario as well where one tool supports multiple formats.
jr: So do we agree. You have to have a techniques document and where does it come from?
wac: The concern is you could have menaingless techniques docs. I don't want to get into a situation whre WCAG would have to certify them
jr: Produce a format provide WCAG, ATAG, and UAG techniques.
jr: So who is authorized to produce these docs.
cmn: In a serious environment qualified people will produce the documents.
jt: WCAG endorsed means WCAG is vetting
cmn: WCAG is vetting some high profile SVG, HTML, etc.
jr: Ist WCAG, then next multi level
cmn: Preffer WCAG endorsed if one is available.
jt: Dependent on endorsement...
wac: Not likely.. I don't think we can endorse anything. We have to remain vendor neutral.
cmn: Recommending a particualr technology. We agree tech meets requirements.
jr: What can we say here? This is not a checkpoint
wac: This is a category two.
jt: If you have a choice choose the accessible one.
wac: XAG ? XAG becomes a recommendation that ATAG, UAG, and WCAG all build off of.
cmn: You don't have to be an XML format to conform to XAG
jt: Somebody who whips out something they call a techniques docuemnt cannot claim to have a WCAG techniques document.
cmn: SMIL example. No way to create techniques since no one owns it.
wac: WCAG could write techniques for SMIL.
cmn: Let's say Adobe decides they don't care about techniques docuemtn that should not stoop another entity to create one sucha as an Adobe users group.
jr: Has to be published..
jt: List in some place where you could publish WCAG compliant content.
cmn: Could make sense to say use something that conforms to XAG.
jr: That could be a technique. Here we just say use formats for which it's possible to create WCAG conforming.
wac: Why would Acrobat produce anything other than PDF.
cmn: You have to leave room fdor innovaqtion.
cmn: Use formats which say which have published techniques where there exist published techniques for conformance to WCAG
jr: Is conformance the proper word?
cmn: "Support creation of?"... I think we do want support for published techniques. Somewhere these things must be published.
jr: Use formats thaqt support the creation of?
jt: Objections, you had before Anyone could put up a techniques docu
cmn: I don't think there is a problem that would allow people to produce techniques doucument willy nilly. Ther will be
wac: Don't have to have WCAG techniques, but a statement that indiates some other way to demonstrate accessiblity
cmn: I don't think we should accept something that does not conform to WCAG.
jr: began editing the success criteria.
jr: Documentation of how to meet each applicable WCAG checkpoint is on the web.
jr: If WCAG has produced a techniques document for the format, use it. If standards org has produced the techniques document for the format, use it. Produce your own and publish it to a permanent public URL
ln: I think you are really saying publish it so other people can look at it and see where your criterai are.
cmn: Recommended that 1 and 3 stay in place and 3 and 4 move to techniques.
jr: made some additional edits to Authoring Tools Accessibility GUidelines 2.0 document. success criteria for 2.1 Ensure that markup which the tool automatically generates is valid for the language the tool is generating [Priority 1].
wac: One of the things we're wresting with is depraceted markp and ... Used the movie embed example. Exceptions allowed for backward compatibility...
jr: Change 2.2 to a priority 1. And changed the language to read, "Give priority to formats that enable the creation of WCAG conormant content." The priority level was changed form a [2] to a [1].
ln: The Success criteria language for Number 1 needs to be changed.
jr: The language was changed by Jan to read:
jr: 1. "In order to give priority to a format: That format must have a published techniques document for metting each WCAG checkpoint."
jr: 2. "For a given format, with multiple techniques documents for meeting WCAG give prefernce to ones published by the WCAG-GL."
jr: then altered some notes. Relative priority checkpoints.
jt: Do we want to put in here that for a choice of docuemnts the one that has a WCAG document should be given priority.
cmn: So let's use an example. Flash and SVG. Flash has edge on deployment. W3C we write SVG and not Flash. Let's assume Flash becomes phenomenally successful beyond W3Cs wildest dreams, it would be a backwards step to force people to use SVG.
jt: What do we want to do now?
wac: I would like to look at another example to see how ATAG references WCAG techniques.
WCAG coordination
jr: Checkpoint 2.5: Ensure that when the tool automatically generates content it conforms to WCAG.
jr: Document refers to WCAG A-AAA. That's changed?
wac: Yes, we now have Core and Extended. It's been proposed that core checkpoints is level A, core and extended is AA, and core, extended and best practices is AAA.
ln: We talked yesterday about metadata. I have a problem with the statement of "Product X conforms at Level Double-A to ATAG2.0 with respect to WCAG 2.0." We'd have a problem representing that in Dublin Core. We'd say "this resource conforms to (standard)".
cmn: If you don't understand the ATAG 2 conformance scheme, you'd get WCAG 1 or 2. If you're looking for ATAG, you may dumb down the bit about WCAG levels.
ln: I think you'll find that ATAG would disappear, and find that "(product) conforms to WCAG 1". May be important to discuss metadata. Somewhere along the line, WCAG should be requiring metadata.
wac: Concern about that among some is that some organizations are reluctant to use metadata to make conformance claims.
ln: It's been a long fight in Dublin Core to get people to believe that there may be an image and text marked separately, and we don't want to go back on that.
jt: This label would only apply if the authoring tool were a content authoring tool.
wac: Why would you require the metadata?
ln: For discovery and transformation.
jt: Back to complex qualifiers (relative priority) other concerns?
wac: My concern is, in WCAG, Core and Extended are generally agreed upon. If we kept those two...
jr: Maybe meeting Core is P1, and Extended is P3?
mm: Concerned that authors can't make AAA content above a certain level of complexity, and so can't expect tool vendors to try for ATAG AAA.
cmn: I'm working with a vendor who plans on making a product that conforms AAA.
wac: I understand what Jan is saying.
cmn: Adobe has accessibility guidelines for PDF. You could make a claim that a tool conforms to ATAG 2 with respect to the Adobe accessibility guidelines, and those guidelines say "we only define one level, and it applies to P2."
jr: We always want to have WCAG in between.
wac: You could remove WCAG, when we talk about outside techniques.
jr: We say "check what WCAG says to check," and WCAG refers to the relevant document. There's still a reference.
jr: For WCAG 1, this is straightforward. For WCAG 2, we state that all WCAG 2 checkpoints apply to ATAG 2 Checkpoints 2.5, 2.6, 3.1-3.3, 3.8.
jt: This is broken now that WCAG 2 no longer has multiple priorities per checkpoint.
jr: Why does WCAG want to refer to ATAG?
wac: Don't know.
jr: Might say in the introduction...
jt: It would be good to have in WCAG that the best way to make WCAG-conforming content would be to use an ATAG-conforming tool.
cmn: I don't think WCAG has any dependency on ATAG.
wac: When authoring tool developers are looking at what they need to do, is there any advice we should be giving to tool developers. ATAG and WCAG are going to have techniques. One of our primary audiences should be authoring tool developers.
jt: ATAG developers should do it through the lens of ATAG.
wac: Our understanding is that tool developers are a primary audience of WCAG, because most authors won't be referring to WCAG themselves. Therefore, tool developers become an important audience. What can we do to make it easier for them to use? What are the relationships we need to help them get where they need to go?
cmn: Relations are complex at techniques level. Beyond that, making it easy to read is a general requirement. Can't think of anything specific.
wac: Our current structure is that we have very atomic techniques. Those checklist items are going to be referred to from the ATAG techniques. Maybe it's just that the checklist item is the most important link.
jt: Great to have a reference point.
jt: Is it still an issue that we're doing A-AAA and WCAG 2 is doing Core-Extended? Should we harmonize?
mm: If they've broken that linkage in WCAG, the issue is moot.
cmn: Asking WCAG 2 to provide a mapping of their priorities into a 1-2-3 system is probably something we'd like them to accept.
jr: Changing document to reflect current WCAG 2 draft
jt: Should we just make it 2 relative priorities?
wac: Can you say in ATAG, item x is priority 1 for core, priority 3 for extended?
cmn: Could say that we'll remap this when WCAG is in PR?
jr: That's what we're saying.
jt: That deals with relative priority.
wac: This could cause WCAG group to seriously consider their priorities. Could cause Extended to be broken up into 2 groups, which could be a good thing. Good test of our conformance structure.
jt: Do you think having ATAG with A-AAA is a problem for WAI?
wac: Only problem is that it would be really unlikely for tool developers to implement extended items if it's P3. But I think that's a WCAG issue.
jr: UA does A-AAA. Are there issues with this?
mm: No.
wac: What are the P3 items in ATAG?
jr: 1.1, for recommended elements of software acc. guidelines. 2.5, 2.6, 3.1, 3.2, 3.3 are Relative. 3.5, 3.6, 3.9 are P3. 4.4 is undecided, P2 or P3.
cmn: If you applied UAAG because it has P1-P2-P3, how do you match it to the priority scheme?
jt: We're planning on getting a submission from IBM of the Software Accessibility Guidelines.
cmn: Technical Note has no status.
jt: But it's referenceable. We've brought it up in CG.
cmn: May want to get a better line that this is an acceptable process.
jt: Reason we decided this was the complexity of the requirements. IBM's guidelines are more complete than 508, and if companies endorse that as a set, it simplifies the process for tool developers.
cmn: Non-OS-specific?
jt: Yes. In any case, we're not mapping it to UAAG.
wac: Only 3 priority 3s. Could shift them into Core and Extended scheme?
cmn: What's the difference between Core and Extended?
wac: Core can be applied to all content, and affects a large proportion of users.
jr: We classify the categories as essential, important, beneficial. In what direction would we collapse them?
cmn: Of the P2s, only 4.4 would go into extended. Would probably cause more pain than joy in the marketplace.
wac: Other question was about scope. Not much question or debate there. ATutor: is it WCAG or ATAG?
jt: Things like synchronous content, like chat systems.
wac: May need a joint techniques document between WCAG and ATAG, to point out "these are ATAG techniques, these are WCAG techniques".
jr: Give me an example technique for that document.
wac: I don't know that there would be any techniques. Just a shell that points users off to one place or another.
wac: Only concern: would we only do it for HTML and CSS? Techniques would be different for SVG.
wac: Maybe gateway techniques documents for Web applications, multimedia, etc. We've had requests for conformance profiles specific to applications documents.
jr: For 1.1, how do we handle pointers into UAAG?
jt: We say "applicable software accessibility guidelines". That's WCAG for Web apps, UAAG for user agents.
jr: "Ensure that the authoring interface follows applicable software accessibility guidelines (Software Accessibility Guidelines, UAAG, WCAG)."
jt: Do we need to refer to UAAG if we refer to SAG?
jr: Are we missing things if we refer only to SAG? Yes.
wac: We added descriptive text to UAAG. It's possible to punt and refer to our WCAG content, because we're referring to UAAG.
Semantic Web
cmn: Semantic Web Activity developed a set of preliminary ideas for how the SW can help accessibility. http://www.w3.org/2001/sw/Europe/reports/w3c_note_sw_accessibility#L2730
cmn: We did this against ATAG 1.
jt: Is this how ATAG 1 can support SW?
cmn: How SW can support ATAG.
cmn: For images and media, we think SW is very interesting. If you have an image on the Web, you can use Dublin Core, describe the image, and users can get information about the image, search on contents, etc.
cmn: Using the same approach, you can build dictionary support: this word means x, etc. Can create a global dictionary system.
cmn: EARL is already implemented in several tools. Its use case is recording accessibility evaluations. If you take a testing tool and say, what are the problems I've found?, you can take the test results and hand it to another tool to do the repair work. We've started to take EARL input and use it to fix things.
jt: A lot of these are what we're trying to address in AccMD (accessibility metadata) process.
cmn: We're developing tools, have these vocabularies. These are fairly interoperable ways to deal with this stuff. If everything is a legacy app, then by being RDF, new apps can go between different applications and kinds of data.
jt: Where does that relationship reside?
cmn: Where you put the data you collect?
jt: Yes, the relationships.
cmn: Short answer, anywhere you like. In practice, there are a couple approaches: Annotea-like systems, where you have a service that stores the data. In discussing EARL, when you have a Web page, and take it offline, how do you differentiate it from the page you started with? There are some techniques: pull out the metadata, change that as you change the document, and republish it wherever it was. It's easier if it's inside the document. In some cases, it's easier to say "this is a copy of x". A tool will know, or can be told, that it's a copy of something else.
cmn: There's stuff in support for WCAG in this paper that describes site-mapping and relationships between documents. Generating a site map can help with overall site navigation. That data can be generated from metadata. Also schema annotation: you can note that XHTML provides techniques for some accessibility feature, that XHTML conforms to some set of requirements like XAG.
jt: How far can you take the metadata in nested groupings?
cmn: As far as you like. The question is how far is it useful to take it.
jt: First level of metadata isn't as useful as second or third to look at trends, etc.
cmn: In schema annotation bit, we say tools can explain to users what a certain bit of metadata is.
jr: Is it best scattered through ATAG techniques, or in its own section? Here's how SW can help?
ln: For people trying to use ATAG, it's better of going in ATAG.
jr: Not in another document, another section.
ln: Still hard to know where everything is.
cmn: There's still information on finding tools.
jr: People don't read techniques from start to finish. Mentioning annotation, there's a lot in that.
cmn: My approach would be to take specific techniques and suggest using this stuff. If people want to read more, send them off to SW tool documentation.
jt: At what stage is Annotea?
cmn: Protocol, several servers and clients. With WAInu, we built some EARL stuff into that, which stores EARL in Annotea.
jr: You take content from a rich format to something that doesn't have as much, but then you can take the data and put it in RDF. So the user goes in and changes the content. How do all these pointers stay up to date? Sophisticated management tool?
cmn: Yes. Partly implementation details, but some important things to do like keep track of links to given documents. Saying there used to be an image there, or that there is a movie version, etc.
jr: How much of that do we want to recommend as being accessibility requirements?
jt: In IMS, it's pointing to alternatives to achieving the same learning goal.
ln: Isn't the point that if a tool doesn't know about these things, it can go find out about it?
cmn: Fairly heavily oriented towards things on the Web. It loses a lot of its potential in describing paper documents.
jr: Or partially complete documents on a hard drive. You can say lots of metadata about that, but how much of is useful for accesibility purposes? People may be disinclined to do it because it's time-consuming to recreate it.
cmn: The document being edited on a hard drive: if you're not publishing, the issue is moot. People store their data several ways, and tracking it may be a sensible thing to do.
cmn: Jim Ley is a JavaScript/SW developer. He has image annotation tools, wrote a collaborative SVG whiteboard, and allows metadata to be attached to that.
cmn: What is going to be the most useful to AU to work up, or are there any things we should stop talking about?
jr: A system that could track all forms of alternatives, but whether that's a real research project or not...
cmn: That should be a reasonably short-term thing. A lot of this is related to what happens to Dublin Core for accessibility.
wac: You talk about using the tool to cajole the human to do things. A lot of the tests the human has to do are human tests, though the evaluation tool can hint to the human. How does ATAG state that there are things the human needs to do?
jr: We say it's good not to do more than you should.
wac: EARL is/should be a technique for that. WCAG deals with real-time information only with audio and video. We don't talk about other real-time interactivity.
jr: And it's not exactly real-time, but has been produced earlier, took time to add captions, etc.
wac: We do talk about webcams, etc. Just wondering about the WCAG component.
cmn: We use tools for IRC, including a tool called Chumpbot. It allows someone to put comments on a link. Being able to include images and descriptions seems like a useful feature.
jr: SW is about creating relationships between things. So does this come down to AI? Figuring out the bigger picture?
cmn: AI on the cheap. Rather than having intelligence, deriving information logically. Building systems that are good enough for a small task, and widescale compatible so systems can find the data they're looking for right now. RDF doesn't define the shape of a system, so if you want to add to it, you can.
jt: This would be useful in tool evaluation. Relationship between different features, etc.
cmn: One of the early SW projects was ATAG evaluations.
jt: It's a way of aggregating the data.
cmn: But you can build it in very small pieces. Is the group doing tool evaluations?
jt: Tim is working on a test suite. But evaluation has always been a difficulty.
ln: Where is it most useful for this work to go on? Part of me wonders how much of this should go on in EO.
cmn: Lobbing stuff into ATAG is one approach. Coming to AU meetings and looking at some features is another. Sending a note when we're discussing image annotation for AU to join in is a possibility. A thought would be to do some work in ER. Already some SW-savvy people there. Don't know how much crossover exists between AU and ER, but that could be the forum where people get involved.
jt: If ER became ER of content and ER of tools, then we can do that. For a while, ER was thinking about testing the tools themselves.
wac: What would ER do as a part of that? Creating an AERT for tools? A test suite?
jt: Yes.
jr: That's in our area.
jr: If ER did an extension of AERT that covered tools, we could work with that.
cmn: I have a tool that could be helpful in creating test suites that output EARL. It's on the Web.
wac: Interested more on AU thoughts on ERT WG. We're discussing a new charter.
Metadata
jr: Liddy, you think there should be a minimum requirement for accessibility to have metadata.
jt: As Charles pointed out, we can recommend metadata and point out how it helps.
cmn: WCAG 1 does require you to produce metadata, but doesn't say what.
jt: If we rethought WCAG/ATAG/UAAG, we are in essence aiming at the same thing.
ln: If you look at what people are trying to do, I think there's a shift toward...
jr: UD?
ln: No, UD is just a part of the story. An audit of US Web sites, and would you believe it, people used >8th grade language. We're going to have these design exercises happening more and more often to the point where it isn't accessibility. Profiles, etc.
cmn: An approach to getting these things in is to say what certain techniques will and will not work for which users. Marking up movies as not useful for mobile phones.
jt: The message is that accessibility is transformability, substitution, flexibility. The pieces of WCAG that don't work or get pushback is when they are seen as a static thing.
cmn: Maybe going further into this equivalences thing Jan mentioned. How to structure multiple collections out of a single collection.
ln: I do the same search every six weeks. Don't know that I want it. I get to roughly what I want. What if I were to collect my searches, and next time I search, I could get to that? There's a dichotomy between that and putting up a resource description. I find it hard to understand how to get there from the classic Dublin Core position.
cmn: Is what you're talking about a dynamic profile matching? Someone said "this is the profile for all people with one leg," and someone with one leg decides they'd like to get something different, so they want to store more data on top of that?
ln: Related to the modality. Mathematicians understand graphs well, and non-mathematicians tend not to. But you learn to read graphs, and want to say that you can understand things.
cmn: So what do tools need to be doing, and is there something that needs to be done in coordination with describing uses?
jt: We're stuck in these three guideline areas, and it's holding us back. We also don't tackle AT head on.
ln: Does the model of how things interact change the world around it? Does it need to be more axes? Theory behind it was that we'd come up with the universal resource and all would be well. Now we look to services, etc.
cmn: So, would it be useful to be working on techniques to putting stuff together, maybe in UAWG or xtech or ER, how people should interact with content?
ln: Would it help if we looked at the problem without regarding user agent, authoring tool, content?
mm: Good topic for RDIG teleconference.
cmn: I agree that the split we have based on creating universally accessible document is not the only and may not be the best approach to achieving accessibility.
mm: Lots of people are thinking about the Grand Unified Theory of accessibility that we're all talking about. Ian thinks it's XAG, and I disagree, but there should be something there at the core that we can describe.
jr: Is this constructive?
jt: I think this is. There are a lot of things that need to be addressed. We need to examine this. But it doesn't help ATAG.
wac: You have, as Liddy said, users, contexts, services and devices, but the documents are split up among stakeholders. The question is what we're not addressing.
jr: There are people who are content developers. There isn't really context to those people.
cmn: How far away is ATAG 2 from being a viable last call? May want to get ATAG 2 out and then look at restructuring WAI?
mm: Sounds like there's interest in a workshop on the future of WAI. Other groups have said things similar, and want Jon Gunderson to move in that direction.
wac: The future of WCAG is resting on good assistive technologies. We don't want authors of content to make up for limitations of ATs. But we need to educate users. Also DI, i18n, talk of usability group. Also talk of a coordination group across domains. We need a roadmap for WAI.
ln: May be a good time to rethink.
Next face-to-face
mm: CSUN?
jt: We're too busy to meet there.
jt: ATIA in Orlando, January?
mm: Interop WG may be meeting there.
jt: If we don't overlap, we could have good input from them.
ln: Costa Rica? Mexico?
cmn: Puerto Rico?
jt: Savannah, GA?
ln: If looking at Australia/NZ, can plan ahead.
mm: I can pursue ATIA.
jt: We'll also pursue other things.
Work schedule
jt: Need to finalize on the issues we've opened up: New checkpoint 4.x. Finalize success criteria.
jr: Proposed text needs to be accepted.
jt: Major work on techniques. Clarify ATAG-WCAG references and ATAG-SAG references. Evaluation techniques stuff, including test suite.
jr: Not a lot of daylight between techniques and eval techniques.