JT: Jutta Treviranus, ATRC, Univ. of Toronto, chair
JR: Jan Richards, ATRC, Univ. of Toronto
DG: Doug Grude, Adobe
LN: Liddy Nevile, Motile Pty. Ltd.
GL: Glen Low, WebCT
MM: Matt May, W3C/WAI, scribe
PJ: Phill Jenkins, IBM
WAC: Wendy Chisholm, W3C/WAI
LGR: Loretta Guarino Reid, Adobe
CV: Carlos Velasco, Fraunhofer Institute
JT: We had an earlier discussion about the presence of icons. Should we decide now?
JR: Suggest the main pointer in TR go to the version without icons, and link to the one with icons.
PJ: Are categories the same between version w/without icons?
JR: We're hoping that version 2.0 will allow sorting on categories.
JR: We've dropped categories.
JR: Without the icons, there is no way to get categories in techniques document. Within ATAG 1 document, we define "authoring tools" and set out categories there.
PJ: I'm concerned. We need to refer to categories whether or not we have icons.
JT: We looked at this, and it turned out that there were few items that were excluded when sorted by category. It didn't filter much out.
JT: So we were trying to publish without, and add the categories as an assistive document for filtering.
JT: Wombat will add techniques, and categories there would have some more benefit.
MM: Version with icons can be seen as an annotated version.
JT: Other issues?
MM: Agreed that this is ready for the public?
PJ: There is a paragraph in noicons version that says: This version of the techniques does not provide guidance on which checkpoint covers which type of tool.
JR: The context is in the techniques themselves.
LN: example code sometimes has ex. instead of e.g. It's not a recognized term.
JR: Need to remove link to evaluation techniques.
MM: Some strange markup issues in list segment
JR: "...does not provide" what?
JT: Need to talk about applicability.
JR: "If you require additional guidance regarding which implementation techniques apply to different tool functionalities, please see the version with icons.
PJ: Could we say why we don't just have one version with icons?
JR: Note under Applicability of Techniques section.
JT: "How this document is organized" needs to be edited.
MM: Suggest the noicons version be the main document, and icons version be "annotated version"
ACTION JR, MM: Make edits in introduction of icons version, and remove link to Eval Techs
ACTION JR, JT, MM: Make relevant changes to Status section to prepare for TR
Do changes to "Status" section include removal of mention of "Wombat"?
JT: Do we need to make changes to the glossary now in the absence of a unified glossary?
JR: I've looked at the glossary.
JT: Strike that sentence?
PJ: I think we lose the linkage to the future version, which is where we want people to be working.
JT: Do we only need one status section, and consider every supporting document to be subsumed?
LN: We should have a sitemap.
Don't link site map in any doc, but does exist on AUWG page.
How about a "Related documents" link in the top toc that points back to AUWG page section?
JR: Users would have been to the home page.
PJ: I don't think many will have been there. They'll have gotten it as a link from a government body, etc.
MM: Could remove headers from chapters like UAAG.
JT: Should we leave the reference to continuing development?
MM: I think we should publish this as a final document, to avoid keeping potential implementers from working on it until the next version.
JT: Should refer to WCAG 1.0 explicitly.
LN: This should be referring to the current status of Wombat.
Phill has to go for 10 minutes - I'll log in when I return.
JT: How can we communicate that work is ongoing with Wombat, but not with this document?
MM: AU home page.
MM: "This is the work of the AUWG. Current document and WG status are available at /WAI/AU."
ACTION JR, MM: Interrelation paragraph on AU home page
ACTION JR, MM: one-page version of ATAG 1 techs
Agreed: default is version without icons, linked to version with icons.
Agreed: ATAG 1 Techniques to TR
WAC: WCAG timeline is 2 more TR drafts, then Last Call within 6 months, and then going for Rec 6 months after that.
WAC: This is what we're aiming for. Pushing for review from several groups. Talked to Device Independence WG, and MM and I met with Richard Ishida from i18n.
We have three levels of normative data, plus "advice". Some talk about collapsing those lists, but general consensus about status quo.
WAC: Some normative criteria point to informative techniques.
WAC: We need to clean that up.
WAC: There's a level below success criteria that is completely technology-specific.
WAC: Added "rules" which were prose describing what to do, but some need success criteria instead.
JT: The main success criteria are meant to be generalizable across technologies?
WAC: Yes. WCAG 1 had some very HTML-specific checkpoints.
WAC: We're trying to ensure that these will work for all content, not just page-based HTML.
JT: Some talk about publishing 2.0 as a 1.1. Is that a rumor?
WAC: There has been a request to publish 1.0 plus errata as 1.1. We have a list of issues with WCAG 1. There's a process being worked on within W3C on how to publish adding errata.
JR: What would the effect of WCAG 1.1 on ATAG?
WAC: I don't think it would be an issue. There won't be any great changes to structure.
JR: If you could do that, it'd be great for us.
WAC: Not a lot of movement on it so far. Will need a lot of discussion.
PJ: WCAG 1.0 Second edition would not affect ATAG 1.0
PJ: a WCAG 1.1 might affect ATAG 1.0
JR: If we have ATAG2 and WCAG 2, that's great. But we have to be concerned with future versions of WCAG and interop.
MM: I think we're looking for ATAG Techniques for WCAG 2.x or x.y that are released along with WCAG
JT: Anything else needed to separate/generalize the guidelines documents?
MM: We need to allow authors to claim that the latest version when we started was x.
JR: Instead of saying "most recent version of WCAG", just say "WCAG".
DG: Also don't want to get too far apart between versions.
JR: If we keep updating the techniques, we can stay up to date.
JT: So we'd need to make authors claim compliance to ATAG versus a given version of WCAG.
PJ: Jutta mentioned "covered 7.2" - meaning what and was that a resolution?
JR: We need to bring in a description of satisfaction and define what that means vis-a-vis different documents.
JR: Wombat ckpt 7.2 makes specific reference to 2.0 and its priority scheme.
JT: The question is how to make 7.2 generic.
JT: Now, we're wondering whether to do that.
JT: There are some concrete examples in the document. We want to avoid making it so vague as to alienate developers.
JT: So, then, what is the normative piece, and do we put normative text in the techniques document?
JR: There's nothing you can run like AERT. There has to be some human judgement.
JT: Do we want to create a guidelines document that is independent of the version of WCAG?
MM: Yes.
JR: Yes.
LN: Yes.
DG: I'm for trying it. I'm not clear as to why, but I see there's a bottleneck.
phill?
Agreed: make document independent of WCAG version.
JT: Consensus that this next working draft will be ATAG 2?
Agreed: next working draft of Wombat will be ATAG 2.0.
PJ: Phill agree's
reviewing JR's issues list of 13 Sep
1: Criteria for non-applicability of a checkpoint should be made more clear.
2: Authoring tool definitions should be looked at to see how repair tools fit in.
3: "minimum" requirements need to be thought of in the context of the evaluation techniques.
4: "advanced" may be too cumbersome
5: "rationale" should encompass most of the "notes" under checkpoints
6: are we going to require some level of checking beyond providing a manual?
JR: Overhead of the document can be trimmed out.
JR: Tier numbering issue from Phill
PJ: Would not recommend grouping them any closer than guidelines (i.e., delete tiers)
JT: Tiers implies hierarchy, but also implies greater importance.
JT: Principles?
PJ: I'm all for making it 4 guidelines, and making more checkpoints under that.
JR: Two principles have only one guideline in them.
PJ: But one has seven.
JR: Looking at the Principles...
JR: Guideline 2 and Guideline 3 are pretty different.
PJ: Both are talking about what the tools should be enabling.
JT: The checkpoints themselves are more similar.
PJ: Terms "enable" vs. "support". Difference is subtle and hard to discern.
PJ: Some of Tier 3 can go into Tier 4 (guide and provide -> integrate)
G6 is more about look and feel than presence; Principle 3 was more about the presence of support than how it was integrated.
JR: Principle 2 would be 7 points, Principle 3 would have 9. They'd be very different.
PJ: Do we need three levels of hierarchy, or can we just say it's based on the principles set out?
MM: Maybe the opposite: 4 Guidelines, with the current construct of guidelines used as description of the parent.
JR: I'd like to see those differences between current guidelines to be called out.
DG: Alter the checkpoints?
JR: The checkpoints are what we're instructing the users to do. We don't want to alter that much.
MM: Maybe if these are grouped with declarative phrases, and allow the checkpoints to give instructive statements.
PJ: I think all this information can go in 1.1.
JR: When I numbered them, I didn't include the tier number. I decided we didn't want to have a x.y.z numbering system.
MM: We have an issue of views. Integrators want to see checkpoints to see how, but business owners want to see principles/guidelines to see why.
JT: I can see the need to simplify and not add another level. But I've had feedback that it's helpful in gaining perspective.
PJ: Can we do it in the intro without dividing checkpoints?
MM: Concerned about separating the checkpoints from the purpose that caused them to be structured that way.
PJ: I still have a problem with adding that level of structure. It adds a level of indirection.
DG: My first thought was that we should call them out as Principles A, B, C, D.
JT: Change the tiers into headers which aren't referenced directly?
DG: I like the idea of the principles grouping, but I'm concerned about the extra level of indirection.
PJ: Can we add a secondary table of contents to point to principle headings?
JR: Tier 4. I had to generalize one guideline into a tier. I'd like to see the guideline elevated, and lose the Tier, since it's contrived.
PJ: It helps differentiate from Tier 1.
JR: Tier 1 is the same issue.
JR: Propose going to 4 guidelines (current tiers) with explanatory text (e.g., the current guidelines) within each.
PJ: I'm okay with that.
JR: I'll draft a new structure for review in a few minutes.
JT: One label that's problematic is "Enable/support accessible content". Too similar?
PJ: Enable the tool to produce accessible content, and support the author in the production of accessible content.
DG: The tool has to ensure that even content it imports is accessible.
JT: Proposal 1: Ensure that the tool produces acecssible content.
JT: Proposal 2: Support the author in producing accessible content.
PJ: 3.5 doesn't fit there. Can it move to Tier/Guideline 4?
PJ: Tier 2 rewording: should be "enabled to produce".
JT: This refers to the tool, not the author. This is doing it without the author's knowledge.
JT: Ensure the tool is designed to produce accessible content.
The working group received a presentation from WebCT.
Loretta Guarino Reid has joined.
JT: Do repair tools count as authoring tools?
LGR: You don't go in and edit the content directly with repair tools.
LGR: In the case of HTML, it would be possible to replace all of the HTML. This would make it an authoring tool.
LGR: What's weird about PDF is that there are tools which let you replace PDF, but I don't know of any tool that will let you create PDF directly.
LGR: Some of the authoring tool guidelines imply that you can make changes at that level.
JT: We do host pieces of AERT that talk about techniques for evaluation and repair.
LGR: Where ATAG takes the list of techniques, and says your tool must support the generation of these techniques, I want to know how to do this in Acrobat. But that's a small piece of ATAG.
See http://www.w3.org/2002/09/18-au-irc#T22-43-04
JT: New Guideline 3 owns checking and evaluating content.
LGR: Maybe authoring tools become authoring and repair tools?
JR: We have systems like WebCT where they don't have a great deal of control over content.
JT: It'd be as if we created a prompting tool. Same dilemma.
LGR: Repair tool input is something which could be output.
JR: And there's something which came before it to create output. Some things in ATAG refer to integration of accessibility into the authoring process.
LGR: I think of ATAG as eliminating the need for repair tools.
JR: So, saying "Dreamweaver + LIFT" is an authoring package would work. But could A-Prompt on its own comply?
LGR: Don't want to be weakening the message that the tool should be producing accessible content in the first place.
JT: "Used for creating web content" could include a wide array of items. It's implicit. Also, a lot of tools are only doing pieces of that.
JR: Can we say that pieces are ATAG-compliant, but that they must make workflow ATAG-compliant?
JR: We don't want to force smaller tools to line up.
JR: ATAG-conformant tools vs. ATAG-conformant process.
JT: Wendy, is AERT being worked on by ER?
WAC: Not by ER, but in WCAG WG. Being integrated into techniques.
WAC: A problem with AERT was that they were trying to interpret. This time, I'd like to WCAG state the assumptions themselves.
JT: We'd need to point to HTML techniques doc, but also work on AERT components that are relevant to ATAG. Do we point to them as techniques, as appendix...?
WAC: I've heard from some ER developers that they'd like one place where they can get both places.
WAC: Could use Matt's techniques DTD/schema.
to generate 3 views: WCAG view, ATAG view, AERT view (combo of relevant pieces from WCAG and ATAG) since ER devs have said they want info in one place.
MM /* overview of WCAG tech dtd */
MM ultimately, if device indie, I18N, ATAG, WCAG...if all using then increases the number of views could generate.
JR: Judy and several of us have been discussing the boundaries of the term authoring tool.
JR: We're now discussing this as a process.
JT: If we evaluate a combination of authoring tool and ER tool, the combinations are endless. We want to say that if your constituent tools satisfy the criteria, you're okay.
JR: Including tools that are benign to that process can be considered part of the ATAG toolchain.
DG: If there's a component that's outside the authoring tool that's not compliant, would that prevent compliance?
JT: We're in fact requiring a functionality (repair).
JR: Can we have ATAG-benign?
ack wendy
WAC: Idea of process is interesting. Guidelines don't teach design, and if we can get users to think like designers, that would help.
WAC: another guideline or something about process?
MM if you say "if you do this as part of tool chain, you can produce somethign ATAG compliant"
JR: I see it this way: as an implementer of a process, you look at the process note to determine whether you have ATAG-compliant or ATAG-benign tools.
JT: In judging applicability, we're trying to identify functionality rather than how to make a tool accessible. What that brings up is the inconsistency that "if you don't have this, you can't comply", but then allow for combinations.
UAAG conformance profiles: http://www.w3.org/TR/2002/WD-UAAG10-20020821/conformance.html#conformance-profiles
JT: Need to talk about ATAG process and ATAG functionality.
JT: How does it deal with direct accessibility vs. access-friendly?
JT: The way that we say this is to judge whether this is applicable based on the functionality of your tool.
JR: If that's a part of your process, that's not a part of your checking.
JT: Needs to be seen in the context of what a tool's process is.
DG: What if a tool says, we're going to have a third party develop a plugin, but we don't have control over what they develop, so can't be sure of complying.
JT: You can spec that out for them.
DG: Photoshop has 120 different plugin vendors, but we don't certify them all.
JR: So we say that if you draw a circle around a given set of tools, you can claim compliance.
MM: Don't we want vendors to take initiative to bind the features into the product rather than giving them an out?
JR: Larger vendors will need to comply to sell to government, etc., so they'll want to integrate it.
JT: We need to define functionality in introduction.
JT: We're targeting developers, and the reality of developers is that they recruit third parties.
JT: Do we need to inform developers that Guideline 1 means making your third-party tools accessible?
JR: I consider that to be all one tool.
JT: This could be a note.
LN: I think we also have an opportunity to spell out that it's an okay way to think about this as a process.
ACTION JR: Text describing toolchains and ATAG as a process
JT: How to alter applicability statement based on the functionality a tool has, and looking at the checkpoints that apply to that functionality.
JT: Extrapolating this, we can say that checking and repair is a functionality, and thus can be excluded. We want to make sure that stays a requirement.
LN: Can we define the tools as "having authoring functionality", and say that if it does this, it should have checking and repair?
JR: And we can say that anything in the existing categories should have checking and repair.
JR: We just need to get watertight categories, which may not be the ones we have here.
LN: I don't know why we've defined this by tools, rather than by functionality.
JR: In ATAG 1, the definition had some wiggle room. For ATAG 2, we can start by defining functionality and make it tighter.
JR: We want to be careful to say that if a tool doesn't have the functionality, it doesn't apply.
CV: Wanted to have short, informational document for people to adopt.
CV: Wanted to be enthusiastic on message.
JT: The primary audience appears to be potential developers of tools, right?
CV: Yes.
JT: There seem to be two potential audiences: the other one being companies attempting to integrate an accessible process.
CV: That's not a target of this document. There's another document for choosing tools.
DG: How are you working this in with the rest of the WAI?
CV: The Note would go within the WAI space, and then we want to approach developers, particularly in Europe, and meet with them.
JT: In executive summary, it's good to ride the coattails of WCAG and say that the only reliable way to support WCAG is to have tools that facilitate it.
CV: I can add that.
JT: We're talking about authoring in this meeting as a process, and explaining how all of the process needs to support accessibility.
JT: Vendors need to ensure that their third-party plugins are accessible as well.
CV: If we go back to authoring as a process, then we have other documents that cover that.
JR: Adding reference to the process may be another selling point here.
JT: It sounds more like...
LN: "Don't be the silly one."
JT: rather than talking about the advantage of being first to market.
JR: We'd like to say that lots of companies are working on it, but that your company can still be a leader.
LN: Other side is that if you don't do it, you'll be left behind.
CV: This paragraph could be moved to the last section.
JT: No, I think it can still be a strong argument.
JT: Reference to ATAG techniques for classes of tools?
CV: Judy wants to use only the most stable documents.
JT: The techniques documents don't get any more stable than Note status.
DG: It's hard to sell this without the effects on users.
DG: It's good to point out that it's just good design.
JT: Pointing out the curb-cut advantages of having an accessible tool, e.g., localization, color management, etc.
CV: Maybe this doesn't fit here.
JT: We can point to a number of documents that make the business case for accessibility.
DG: Some companies haven't gotten to the point of seeing the benefit outside of legal ramifications. There have to be other compelling business cases.
LN: You have to make people feel it's the right thing to do, or the wrong thing not to do it.
JR: Would case studies be compelling?
LN: I think that they need to bundle that into the business case.
JT: Pointing out that sometime most users develop disabilities (via age) can enlighten people.
CV: I'd like to point to How PWDs Use the Web document for that.
DG: Many members of AARP are discovering the benefits of accessibility.
CV: The kinds of things we could add in is endless.
JT: Better than none. We can at least give suggestions.
JT: Implementation status?
CV: Suggestions are welcome for the title of this section.
JT: What is the purpose of this section?
CV: It's to point out implementation details while evaluating one's own tool.
JT: It doesn't read like that.
CV: Yes, we're working on changing that.
JT: Want to point out not just that if you've done x, you're on your way, but more points.
DG: Market testing of the product to see current state, for example.
JT: I think the Review Recommendations section is distracting. The Software Development Process section is more useful.
DG: On l10n, the notion of making sure that in l10n process, you didn't break accessibility.
JT: Organize this section so it says, evaluate your own tool, compare its compliance with several standards, look at software design process and accessibility's place, and look at competitors?
CV: Yes.
JT: Benefits and market overview: needs more curb-cut advantages.
JR: I'm guessing that most manufacturers have already evaluated target market, and they need to look at submarkets or secondary markets.
JT: Add the good design arguments here.
CV: I don't know if the audience really cares about it or now.
JT: I can reduce the cost of development.
JT: Curb-cut advantages for users, for software developers, for design vs. retrofit, and first-mover advantage.
PJ: Maybe they would benefit by putting it out to the public, instead of holding it back.
JT: This is much clearer than in earlier/predecessor documents.
JT: How did WebCT get accessibility into it?
GL: Tried to advocate one on one, and then it picked up internally. Then 508 came along and it lifted it up.
DG: Integrating into training processes helps. Companies are holding classes now.
GL: We have a 1-day training session on accessibility which is always full.
DG: We've had sessions on accessibility with 200 attendees.
JR: sent list to AU
LN: I like the document. It's getting to be usable.
DG: Nothing sticking out. I have a few nits to pick.
JT: It'd be good to add some language for supporting accessibility metadata.
JR: The issue of, when can someone trust that something has been done?
JT: Coverage of dynamic, database-driven content. Do the guidelines generalize well enough?
LN: There's an advantage to being explicit about it.
MM: Housekeeping. Need a document listing patent status, etc.
(Removing elements of Status of This Document)
JR: removing redundant bits of status section - done...
looking at Introduction - place-holders for re-working the text
Table of Contents simplified because tiers have been emoved....
'goals of this document' being amended to include the idea of functionality more specifically
Getting rid of sentence beginning "To achieve these goals..."
re-writing the sentence about everyone beiong able to use the web
PJ: how do we express the need for everyone to read and write to the web?
Adding statement: "Everyone should have the ability to produce web content."
PJ: They play a critical role in determining the accessible of that content."
Trying to determine the leading points to be made...
...under "rationale"...
Keep the statements in the same order as the supporting language.
Now have: "Everyone should have the ability to produce and access Web content. Authoring tools are the predominant means for producing Web content, so the tools themselves, must be accessibile."
...but there's very little web content NOT produced with an authoring tool...
changing again...
Second sentence now reads: "The accessibility of authoring tools determines who can create Web content and the output of authoring tools determines who can access the web content."
Concensus that we should write in "active" sentences rather than "passive."
adding in a "curb cut" example...
"The principles set forth in these guidelines will be benefit to many people who do not have a disability but who have similar needs. This includes people who work in noisy environments where the use of sound is not practical, people who need to use their eyes for another task and are unable to view a screen, people using small mobile devices having small screens, no keyboard, or no mouse.
...change to "people with disabilities, and those with similar needs."
we are busy removing lots of redundancies ...
Completed the organization of the "goals".
JT: What is happening with WCAG re: changing compliance levels?
MM: Some talk about removing one level, but not resolved.
Phill sent in comments to early discussion/edits
ACTION JR, JT, MM: Resolve awkwardness of Relative Priority conformance block
Moved conformance to rear of document, before Glossary of Terms....for now.
ACTION JR: Move conformance minutiae into an appendix
JT: A lot of the minimum requirements in the document say essentially "If you're not going to do this at all, tell us." Need to fix that.
(on minimums:)
JR: Minimums were meant to help guide tool developers.
JT: Didn't UAAG have minimums?
MM: They had normative inclusions and exclusions.
JT: Should we get rid of minimum and advanced?
PJ: That's opposed to what the other groups have.
PJ: We need checkpoint requirements bulleted out like UAAG. What is normative needs to be in the guidelines document.
JT: If we can't explain normative inclusions and exclusions to ourselves, we shouldn't be emulating it.
MM: They refer to applicability.
PJ: UAAG says "in order to meet this requirement, the tool must do x".
JT: So we need measurable criteria within the guideline document?
PJ: We only need it relative to the authoring tool. Content stuff is in WCAG.
PJ: 2.1: Does this exclude Flash and PDF?
JT: Yes.
PJ: I don't like that.
MM: 4.1: I think the checkpoint name could be under minimum functionality, and the rationale should be the checkpoint name.
JT: Move success criteria into the main document?
(from evaluation techniques)
Homework: construct the predicate of "You know you've met this checkpoint when..." for each checkpoint.
ACTION PJ: Guideline 1 (integrate 508)
ACTION JR: success criteria for Guideline 2
ACTION MM, JT: success criteria for Guideline 3
ACTION LN, DG: success criteria for Guideline 4