02:53:02 MatTEXAS has joined #au 15:10:15 RRSAgent has joined #au 15:10:20 dialling in 15:10:30 oops. I guess so should we. :) 15:11:38 I'm on the line but it will silent until another person joins in!! 15:16:48 pj: When you do usability testing, you find out how successful your design is. The testing helped us understand just what is easy to use. If the issue is that we're not mature enough to know what is usable, then we should just specify option 2. 15:19:25 jt: 4.1 success criteria, part A 15:19:34 pj: How much of WCAG do I have to meet with that one click? 15:19:56 jr: Point is to make sure that the accessible version is as easy to find as the non-accessible version. 15:20:10 pj: I think 1 is rewriting the checkpoint. 2 is the checkpoint. 15:20:25 jr: (removing 1) 15:22:22 pj: It's a problem whether audio or visual. Could have the same problem with a VoiceXML tree. 15:23:48 jr: Right now, we're saying in 4.2 that prompting, checking, repair and documentation are always available. 15:26:33 bf: Unclear what you can get away with in success criteria and what you can't. 15:27:15 pj: 1, 2 and 3 make sense. 15:27:30 jr: In 4, what we're saying is that when things are combined, we don't want them to be lost. 15:27:33 pj: Isn't that another checkpoint? 15:27:39 jr: I think it still fits under this. 15:27:49 pj: Functionality, or attributes? Getting prescriptive. 15:30:29 jr: Maybe 3 takes care of it: these functions need to be available at all time with no more steps than high-priority functions. Doesn't matter if they're mixed. Maybe 4 is redundant. 15:31:56 pj: What if it shows alt, but not longdesc? 15:32:09 mm: Could conform to ATAG A, but not AAA (matched with WCAG) 15:32:33 pj: high-priority is tool-dependent. 15:32:46 jt: Should we use "frequently-used" or "commonly-used" instead? 15:35:09 jr: Checking/repairing has to have same priority as spell-check, etc. Documentation has to be with the rest of the docs. etc. 15:39:22 jt: Use "prominence" rather than "visibility"? 15:41:35 km-dk: "conspicuous"? 15:43:34 jr: If we're going to define prominence for 4.2, why not for 4.1? 15:44:24 FYI: definition of prominence is the quality or condition of being immediately noticeable 15:54:27 tb: "position within location"? 15:56:06 location seems more geographical. Position is more an appropriate place or arrangement. Tricky. Position is also defined as "a location"! 15:56:54 mm: Position within location isn't a good measure. Last item on a list can be just as prominent as the first. 15:56:59 jr: Remove? 15:57:19 jt: ok. 15:58:23 pj: If it's 10 levels deep, but I have a shortcut key, would it pass? 15:58:31 jt: It wouldn't have the same location. 16:06:35 tb: Is there something we can do with Part B without abandoning it? 16:07:12 pj: It's relative, not subjective. It's relative to the other controls. 16:12:31 pj: User interface and functionality must be similar? 16:14:11 jt: Do we need usability overrides? 16:14:57 tb: I don't think we need it right now. 16:15:08 jt: Does anyone feel we need it? 16:15:15 pj: Propose we move it to the list. 16:16:44 bf: I interpret this as saying, you can pass the Part A, or by meeting the requirements of disabled users. 16:17:00 jt: no. To prove your tool does the same things. 16:19:25 bf: If you just want them to do the job, then you don't need it. If you want to give an out, then you do. 16:19:35 tb: I think innovative solutions can be done under the guidelines. 16:21:26 agreed: Take usability override out of next TR draft 16:23:13 JR has joined #au 16:23:19 hi Karen 16:23:22 hi 16:41:23 karen we're back 16:41:36 ok I'll be there ASAP 16:44:21 The first guideline addresses the accessibility of the authoring tool, itself. Guidelines 2, 3, and 4, on the other hand address the accessibility of the content produced by the tool. These three guidelines build upon each other, with guideline 2 establishing core requirements, guideline 3 establishing key user support functionality and guideline 4 specifying general considerations for how any functionality related to accessibility should be integrated with the r 16:45:32 Relationship to Web Content Accessibility Guidelines 16:45:32 ATAG 2.0 interoperates with the Web Content Accessibility Guidelines (WCAG) 1.0 and 2.0. Authoring tools developed using these guidelines will commonly produce content that conforms to WCAG by default. This de facto accessibility means authors of conforming tools will spent less time producing quality content that can be accessed by larger audiences. 16:45:33 The Web Content Accessibility Guidelines are the global standard for Web accessibility. Many countries and organizations have adopted WCAG for their Web content. An ATAG-conformant tool indicates that the requirements set for authors in these environments can be met more easily. 16:47:02 Jutta has joined #au 16:48:29 Is this being placed just after 2. Determining Conformance and before 2.1? 16:48:53 Just before 2, in the intro. 16:49:35 Conformance profiles 16:49:36 Authoring tools claiming conformance to ATAG 2.0 must also state a version of WCAG to which its output conforms. For example, a tool may claim ATAG 2.0 conformance with WCAG 1.0, because its accessibility checking tools test for WCAG 1.0 conformance, and the tool's output conforms to WCAG 1.0. Another tool may claim ATAG 2.0 conformance with WCAG 2.0 because its native file format has a WCAG 2.0 Techniques document, and/or could not claim conformance to WCAG 1.0. 16:49:41 A third tool may claim ATAG 2.0 conformance with both versions of WCAG. 16:49:45 For information on ATAG 2.0 conformance regarding individual versions of WCAG, see Resolving ATAG 2.0 References to WCAG. 16:53:12 ATAG 2.0 builds upon the *Web Content Accessibility Guidelines (WCAG)*. Authoring tools developed using these guidelines will commonly produce content that conforms to WCAG by default. This also means that authors using ATAG conforming tools will more easily produce quality content that can be accessed by larger audiences. 16:54:30 Responsibility for claims 16:54:30 A conformance claim (with or without an accompanying conformance icon) is an assertion that an authoring tool has satisfied the requirements of a chosen conformance profile. Claimants (or relevant assuring parties) are solely responsible for the validity of their claims, keeping claims up to date, and proper use of the conformance icons. 16:54:30 The existence of a conformance claim (with or without an accompanying conformance icon) does not imply that W3C has reviewed the claim or assured its validity. As of the publication of this document, W3C does not act as an assuring party, but it may do so in the future, or it may establish recommendations for assuring parties. 16:54:46 Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to claim conformance to the most recent Authoring Tool Accessibility Guidelines Recommendation available. 16:54:52 This specification imposes no restrictions about: 16:54:54 ? who may make a claim (e.g., vendors about their own user agents, third parties about those user agents, or journalists), or 16:54:57 ? where claims may be published (e.g., on the Web or in paper documentation). 16:59:42 tb: I envision a public process where someone using the tool can publish it. Concept of a profile may need to be defined. 17:02:10 ACTION: mm Work on conformance section. 17:03:04 GUIDELINE 1: Ensure that the tool itself is accessible 17:03:05 This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces. 17:03:05 The special nature of authoring interfaces dictates several other accessible user interface design considerations. The checkpoint requirements for this section include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making the use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Check 17:03:36 don't you want to remove "for this section"? 17:05:49 GUIDELINE 1: Ensure that the tool itself is accessible 17:05:49 This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces. 17:05:49 The special nature of authoring interfaces dictates that special consideration be paid to several specific functions of the user interface design. These include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5). 17:06:07 Also we have a definition for, and have been using, "authoring tool interface" as opposed to "user interface". Should this be replaced througout for consistency? 17:07:26 GUIDELINE 3: Support the author in the production of accessible content 17:07:26 When the author has some measure of control over the produced web content, such as *authoring by hand* or *WYSIWIG editing*, elements of human judgment and creativity are introduced, and conformance with *accessible authoring practices* may be improved or worsened. The authoring tool should provide support and guidance to the author to follow *accessible authoring practices*. 17:07:50 It should be natural to include features in an authoring tool that facilitate the process of creating accessible web content, as the role of any authoring tool is to facilitate the satisfaction of authoring constraints, such as conformance with accessible authoring practices. 17:08:01 The authoring tool should provide support with automated or semi-automated checking and repairing facilities. This support includes prompting and assisting the author to create accessible web content, especially for information that cannot be generated automatically, such as descriptions of graphics (Checkpoint 3.1), checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). The authoring tool should avo 17:08:13 The authoring tool should provide high quality accessibility-related documentation to support the author. The documentation and help must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7), ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint 3.8), and including suggested workflow instructi 17:08:22 All functions that support *accessible authoring practices* should allow author preferences to be configurable to allow for different authoring styles. Custom configurations should improve use of the tool and make authors more receptive to assistive interventions from the authoring tool. 17:08:54 The authoring tool should avoid automatically including equivalent alternatives that are inappropriate (Checkpoint 3.4), provide automated means for managing equivalent alternatives (Checkpoint 3.5), and provide accessibility status summaries (Checkpoint 3.6) 17:09:26 and including suggested workflow instructions for using the tool to produce accessible content (Checkpoint 3.9) 17:12:24 jt: Second paragraph seems to refer more to Guideline 4 than G3 17:12:36 JR: If you take out the word naturally it's ok. 17:13:24 JR: Should we use code-level editing in place of authoring by-hand? 17:14:33 jt: The tool can't control everything. I just don't know how to word it. 17:15:38 JR: It's safe to say "when the user has a measure of control" 17:15:43 jt: "shares control" 17:16:56 JR: Whenever the author makes decisions 17:17:01 km-dk: independent of the tool? 17:20:34 Whenever the author makes decisions during the production of web content, elements of human judgment and creativity are introduced, and conformance with *accessible authoring practices* may be improved or worsened. The authoring tool should provide support and guidance to the author to follow *accessible authoring practices*. 17:23:25 Whenever the author makes decisions during the production of web content, elements of human judgment and creativity are introduced, that may or may not conform with a.a.p. 17:24:26 Actions of the author introduce elements of uncertainty that may affect the *accessibity* of the produced web content. 17:29:18 Many authoring decisions are made by the author and are not controlled by the tool. These decisions can effect the accessibility of the content produced in positive or negative ways. 17:32:03 Many authoring decisions are made by the author and are not controlled by the tool. These decisions can effect the *accessibility of the content* produced in positive or negative ways. The authoring tool should provide support and guidance to the author to follow *accessible authoring practices*. 17:43:54 Assistance by the tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others 17:57:50 When objects, for which alternative equivalents have been previously provided, are inserted, the tool must always offer those alternative equivalents for reuse or modification. 19:24:51 km-dk: we're starting up... 19:26:41 hi! Just sent mail to JR with guideline 3 text. you guys can look at it while I phone in. Perhaps then JR can put it in IRC for the record, rather than me? 19:31:17 jt: We had a 3.9 which was a workflow checkpoint, and a 3.x which is a workflow checkpoint. They were similar. 19:34:54 JR has joined #au 19:34:56 Rationale: If accessible authoring is integrated into instruction and 19:34:57 guidance offered by the tool, authors are more likely to follow 19:34:57 accessible authoring as a common practice. If authors must look 19:34:57 somewhere special for information on accessible authoring practices, 19:34:57 they may be unlikely to make the effort. Authors are also more likely 19:34:59 to use features that promote accessibility if they understand when 19:35:02 and how to use them. 19:40:07 Rationale: Accessibility should be consistent throughout the tool: in the authoring tool interface, functionality, documentation, help, tutorials, examples, and workflow processes. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences. If authors must look somewhere special for information on accessible authoring practices, they may be unlikely to make the ef 19:44:41 Rationale: If accessible authoring is integrated into instruction and guidance offered by the tool (e.g. documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring as a common practice. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences. Authors are also more likely to use features that promote 19:44:54 All examples of markup code and views of the user interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices. 19:44:54 All descriptions of authoring processes must integrate the steps needed to create accessible content. 19:44:54 The documentation must contain suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool. 19:44:54 For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for that feature. 19:53:54 3.7 19:56:12 JR: I think we should be careful using words in 3.7 and 3.8, such as "documentation" 19:56:22 JR: Should mean help, whether paper or online; examples; and workflows 19:57:23 jt: tutorials 19:59:47 Documentation def from ATAG10 19:59:48 Documentation refers to all information provided by the vendor about a product, including all product manuals, installation instructions, the help system, and tutorials. 19:59:58 documentation def from UAAG10 20:00:13 Documentation refers to information that supports the use of a user agent. This information may be found, for example, in manuals, installation instructions, the help system, and tutorials. 20:00:24 Documentation may be distributed (e.g., some parts may be delivered on CD-ROM, others on the Web). See guideline 12 for information about documentation requirements. 20:00:50 "See guideline 12" is a broken link. 20:04:34 Documentation: Documentation refers to information that supports the use of an authoring tool. This information may be found electronically or otherwise and includes manuals, installation instructions, help mechanisms, tutorials, etc.. 20:26:18 JR: move 4.x to 4.1. 20:28:20 bf: The goal is to prompt people to think about accessible practices. 20:32:31 Any mechanism that guides the author in sequencing authoring actions (e.g., design aids, wizards, documentation, templates) must integrate accessible authoring practices (from an early stage). 20:41:36 JR: Workflow in 4.x: should this be sequenced processes? Is it meaningless? 20:49:06 Ensure that accessibility prompting, checking, repair functions and documentation are integrated into the *workflow* of Web Content development. 20:49:20 Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports a workflow in which the author considers accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analagous to internationalization, which is much easier when it is considered fro 20:49:44 Any mechanism that guides the author in sequencing authoring actions (e.g. design aids, wizards, documentation, templates) must integrate *prompting*, *checking*, *repair* functions and *documentation*. 20:50:04 That was succ. crit 20:52:34 Rec process: 20:52:46 WD: Working Draft (publicly available for review) 20:52:59 LC: Last Call WD (last chance for comments before implementation) 20:53:15 CR: Candidate Recommendation (must find 2 implementations of each checkpoint before getting out) 20:53:29 PR: Review and approval by Member companies 20:53:37 Rec: Final approval by W3C Director 21:03:01 Actions may be taken at the author's initiative that may result in *accessibility problems*. The authoring tool should include features that provide support and guidance to the author in these situations, so that *accessible authoring practices* can be followed and *accessible web content* can be produced. 21:03:02 This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives 21:03:43 The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and a summary of accessibility status (Checkpoint 3.6). 21:04:30 The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries 21:29:51 km-dk has joined #au 21:30:48 km-dk: we just started. 21:31:07 hi. I got disconnected. all the text is gone, but that is only at my end, right? 21:31:16 I'll phone in now. 21:31:17 yep. That's what RRSAgent is for. 21:31:50 Priority review 21:32:01 JR: 1.1, waiting for priority from ISO docs. 21:32:14 JR: 1.2 relies on ISO doc. 21:35:05 JR: We believe in ISO 16071 that there are several levels for conformance. We say in order to get our P1, you must do the critical elements. To get P2, you must do the less-critical ones. 21:35:42 action: tb Conformance levels for ISO 16071 21:35:51 JR: 1.3: P1 21:36:32 JR: 1.4 21:36:49 jt: When we had participants with screen readers this was a very dearly-held checkpoint. 21:37:06 bf: More about speed than basic requirement. 21:37:15 jt: Important rather than essential. P2. 21:37:22 JR: 1.5 21:37:27 jt: Similar. 21:37:51 JR: 2.1: P1? 21:38:05 jt: We've been back and forth. Came back to P1. 21:40:10 bf: In reality, is the thing actually not accessible because of this? 21:41:41 mm: Valid code is a contract between user agent and content to render properly. Invalid code can break any number of ways. 21:43:18 JR: 2.2 21:43:38 jt: If we can't produce accessible content in the language, it can't pass. 21:44:38 JR: Should put it into the definition of WCAG-capable. You'd need to have a techniques document that can show how to conform at AAA if someone wants to claim ATAG AAA. 21:45:23 JR: P1 21:45:28 JR: 2.3: P1 21:45:55 JR: 2.4 21:46:05 bf: Can you guarantee that it won't be inaccessible if it's removed? 21:46:56 JR: May not want to include transformation/conversion, because you don't need that to make Web content. 21:47:07 JR: Doesn't guarantee that there's a problem, but leaves the way open for them. 21:50:11 mm: If you don't have this, something necessary is eventually going to be left out. 21:50:55 JR: If it's stripped out, then the checker is going to find it. It's going to be a painful experience for the author, and you're not going to sell many tools. So, maybe not essential, but important. P2. 21:51:07 JR: 2.5: Relative 21:51:38 JR: 2.6: Relative 21:52:36 JR: 3.1: Relative 21:52:55 JR: 3.2: Relative 21:53:21 JR: 3.3: Relative 21:56:01 JR: 3.4: P2 21:56:09 JR: 3.5: P3 21:56:17 km-dk: Should it be a should, and not a must? 21:57:14 mm: Other docs have must for P1, should for p2, and may for p3, but our success criteria are the equations to determine conformance. 21:57:33 JR: 3.6: P2 21:58:36 JR: 3.7: P2. Important, not essential 22:00:03 JR: 3.8: P2 22:00:51 JR: new 4.1 22:01:05 P2 22:01:35 JR: 4.2: P2 22:02:08 JR: 4.3: P2 22:02:43 JR: 4.4: P3 22:06:41 actions? 22:06:41 sees 2 open action items: 22:06:41 ACTION: mm Work on conformance section. [1] 22:06:41 recorded in http://www.w3.org/2004/02/20-au-irc#T17-02-10 22:06:41 ACTION: tb Conformance levels for ISO 16071 [2] 22:06:41 recorded in http://www.w3.org/2004/02/20-au-irc#T21-35-42 22:54:02 goodnight Karen 22:55:10 bye! 22:55:30 rrsagent, bye 22:55:30 I see 2 open action items: 22:55:30 ACTION: mm Work on conformance section. [1] 22:55:30 recorded in http://www.w3.org/2004/02/20-au-irc#T17-02-10 22:55:30 ACTION: tb Conformance levels for ISO 16071 [2] 22:55:30 recorded in http://www.w3.org/2004/02/20-au-irc#T21-35-42