16:57:08 RRSAgent has joined #au 16:57:33 MatTEXAS has changed the topic to: f2f dialin # 800-833-4294, code 793698 16:58:58 jt: Definition of usability override? 16:58:58 km-dk: I looked at this, and sent a suggestion to the list. 16:58:58 JR: I took this and tried to work on some related ideas. 16:58:58 jt: This seems to imply that the usability is done when a change is done. Does i 16:58:58 t adequately address that you'd use an override when you feel you can meet the a 16:58:59 ims of the guideline through different means? 16:59:01 km-dk: Also user groups, a powerful lobby. 16:59:03 tb: User would need to document. May want to document it publicly. 16:59:05 jt: In this case, this is not under the control of the developers, so they can't 16:59:07 predict what would have the most desirable effect. 16:59:09 JR: (proposed text) 16:59:11 JR: Maybe we don't have to get into the specifics of the test, but just require 16:59:14 that the details be linked. 16:59:17 tb: I have issues with the objectivity/testability. Want to be sure testing term 16:59:19 inology is in sync with industry standards. Should say that Part B should only b 16:59:21 e done if a tool can't conform to Part A, and that exception should be publicly 16:59:23 documented. 16:59:25 JR: (edits testing option) 16:59:27 bf: Where would a person record their evaluation? 16:59:29 jt: We're working on templates and technique documents for eval. 16:59:31 tb: The idea is that this information (test subject video, etc.) would be archiv 16:59:33 ed, and information about it would be publicly available. 16:59:35 km-dk: Curious what the usability community would think. I can run this by my conta 16:59:37 cts. Also, does this overlap with the work Tim is doing with the test plan? 16:59:39 tb: Probably a little bit, but I can modify the test plan to accommodate what is 16:59:41 decided here. 16:59:53 km-dk: In 1.2 and 1.5, there's some description of usability in there. 16:59:55 jt: Jan has proposed that description as a new section (1.x). 16:59:57 tb: There's a lot of subjectivity in there, so I'd like to see that fixed. 16:59:59 jt: Should we leave this for Tim to look over? 17:00:01 mm: I'm concerned that the people who wanted to have this provision in the docum 17:00:03 ent are no longer here. Want to make sure it's still a valid concern. 17:00:06 mm: "Statistically significant" -- I'm concerned that 19 out of 20 is too hard t 17:00:08 o attain. If that's going to be in, I think 4 out of 5 is less onerous. 17:00:09 JR: Statement is that usability method would win an A-B test 19 times out of 20. 17:00:12 pj (by phone): I don't think this should be thought of as an override. When you say the most accessible method should be given priority, you could do that in the usability evaluation. 17:00:14 jt: We'll delay this discussion until tomorrow, so you can join us in person. 17:00:19 tb: I'd like some feedback from the parties who were adamant about this. This is 17:00:21 a big additional piece of work. I understand the creativity aspect, but wonder 17:00:22 if it's worth it. 17:00:25 pj: Could also move it to the techniques. 17:00:27 jt: In the success criteria... Guideline 4 uses criteria as suggestions for how 17:00:28 to test it. Different from the rest of the document. Statements in Guideline 4 a 17:00:30 re more indirect. The actual goal is that users are going to do what is most acc 17:00:32 essible. 17:00:35 JR: Preferred option is still to follow guidelines. But if you have really gone 17:00:36 creative, this is a solution. 17:00:39 km-dk: I don't think that we should define number of users, etc. It should be based 17:00:41 on industry-standard usability techniques. 17:00:42 jt: Should we review whether or not we want to have this? 17:00:55 tb: Are there examples of people developing interfaces that need this? 17:00:56 (sorry, just filling in for the record...) 17:04:26 Any software or service that authors may use to create or modify Web content for publication. Different parts of the authoring interface will fall under one or more of the following types of authoring functionality or functionality that falls outside this classification scheme. The types of authoring functions used will help determine which of the ATAG 2.0 implementation techniques are applicable to a particular tool: 17:06:18 jt: Objections to these four categories? Any others? 17:06:57 mm: Audio-only tools? 17:08:25 JR: Object-oriented. Working with representations of audio. 17:10:42 km-dk: 3D Studio Max? 17:11:00 JR: Same thing -- it's a level of abstraction between code and final product. 17:11:20 jt: Do we want to reorder it to be code, object-oriented, and wysiwyg, then content management? 17:13:05 jt: Also, do we want to use content management? That has other connotations. 17:19:38 bf: Indirect? 17:19:44 JR: We can put that in as a placeholder. 17:20:26 km-dk: I'm thinking of asking people what they think. We're talking about content that's separate from structure. 17:23:32 JR: 1.2 Role of authoring tools in Web accessibility 17:23:44 km-dk: Could we reference the EO document How PWDs Use the Web? 17:23:58 km-dk: It's a good explanation for people unfamiliar with the concepts. 17:28:07 The guidelines set forth in this document will benefit people regardless of ability (see "How People with Disabilities Use the Web [PWD-USE-WEB, http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/]). This includes people who need to use their eyes for another task and are unable to view a screen, people in environments where the use of sound is not practical, and people who use small mobile devices with small screens, no keyboard, or no mouse. 17:45:14 JR: What does UAAG say about this? 17:45:29 mm: Should use UAAG's conformance as much as possible. It's the poster child for W3C's QA. 17:49:06 JR: Checkpoint 1.1. We've decided to go with ISO 16071 as our baseline. 17:52:00 title of 16071 is: Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces 17:52:28 no mention of the word software which I thought I heard Matt or someone say 17:52:33 just for the record... 19:15:37 bf: I believe there's some value in partial credit for checkpoints. There are several security levels, and MS only gets C2, when A1 is the highest. 19:16:17 bf: Not sure whether we should discuss that here. I also propose point scales for this. 19:17:21 bf: It would be a challenge to meet this with IBM products, for example. 19:17:49 tb: Just because it's hard to meet doesn't mean we should get rid of things. 19:18:23 bf: I think it should be possible for people to claim AA or AAA, but if they can't get A, they should be able to claim something. 19:18:34 tb: Not sure that the guidelines is where you should place it. 19:18:43 bf: What logos can you put on your product? 19:19:30 JR: What if we had a B, listing what people met, before they get to A? 19:22:39 mm: I wouldn't want to have companies selling ATAG when they haven't met it. 19:26:19 mm: If you want to make some kind of claim, we can make space on the site for tool vendors to put out conformance claims. I would want them to state why they don't meet it, and whether they are working on it. 19:26:39 bf: That's sort of in my proposal of a level B or C. 19:28:13 jt: There's a concept of this using EARL. 19:28:58 bf: There are lots of tools that are good at producing accessible web sites, but aren't themselves accessible. People want to have a way to claim something. 19:29:49 http://www.w3.org/WAI/ER/#earl 19:30:46 km-dk: I'm thinking about discussion on accessibility blogs, and people claiming accessibility where they're inaccessible. People want to use the logo,and if they fail, say they're doing what they can. If you put in any loopholes, people will exploit them. 19:30:58 JR: There's nothing in the tools that says anything about ATAG. 19:32:15 km-dk: Some template for declaring where people stand? 19:32:47 mm: You want to sanction it, but not certify it. 19:33:12 JR: There was a checker that checked most but not all of WCAG, and they don't get anything. 19:38:42 mm: I would want to see a statement that the tool does at least half, and a roadmap to achieve A. I don't want this to be another 508/VPAT system, I want this to be a ladder up to conformance. 19:39:06 JR: This is not getting into this next draft. Should we put this up as something we're thinking about? 19:45:11 ACTION: Tim Find out what it takes to conform to ISO 16071, and whether it is necessary to create multiple levels. 19:58:52 JR: 1.4 19:59:10 bf: Should indicate with something other than a mouse. 19:59:15 mm: Device-independent? 19:59:32 In any element hierarchy, the author must be able, with a single devie independent action, to move editing focus from any structural element to any element immediately above, immediately below or in the same level in the hierarchy. 20:01:45 ACTION: mm Find definition for "device-independent" 20:04:05 Device independent 20:04:09 Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and braille devices. 20:04:16 Please note that "device-independent support" does not mean that user agents must support every input or output device. User agents should offer redundant input and output mechanisms for those devices that are supported. For example, if a user agent supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse. 20:06:02 action- 2 20:13:58 This guideline requires that authoring tools generate standard markup, that content provided or automatically generated by the tool is accessible, and that the tool supports *accessible authoring practices*. Meeting these requirements is an essential pre-requisite to meeting the higher level functions required in the next guideline. 20:17:31 The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilies that rest exclusively with the tool. This includes requirements that authoring tools generate standard markup, that content provided or automatically generated by the tool is accessible, and that the tool supports *accessible authoring practices*. 20:18:12 GUIDELINE 2: Ensure that the tool is designed to produce accessible content 20:18:12 The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilies that rest exclusively with the tool. This includes requirements that authoring tools generate standard markup, that content provided or automatically generated by the tool is accessible, and that the tool supports *accessible authoring practices*. 20:21:45 Standards-based Web content can be rendered more reliably by more user agents, including assistive technologies used by people with disabilities. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that enable accessible content (Checkpoint 2.2). 20:22:43 Standards-based Web content can be rendered reliably by more user agents, including assistive technologies. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that enable accessible content (Checkpoint 2.2). 20:23:08 Standards-based Web content can be rendered reliably by more user agents, including *assistive technologies*. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that enable accessible content (Checkpoint 2.2). 20:27:03 off the phone - dialing in again ASAP 20:33:36 2.2: What is most prominent format? 20:33:52 When format selection is performed by the author, the most prominent format(s) must be WCAG-capable. 20:35:16 JR: Let's get rid of that success criteria. 20:55:39 The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilies that rest exclusively with the tool. This includes requirements that authoring tools generate standard markup, that content provided or automatically generated by the tool is accessible, and that the tool supports *accessible authoring practices*. Standards-based Web content can be rendered reliably by more user agents, including 21:09:44 km-dk: We're starting up again. 21:11:06 ok 21:13:14 Guideline 2 intro text 21:17:40 jt: We need to either beef up this section, or we need to beef up the introduction. 21:22:32 The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool. 21:22:32 The first responsibility is to create valid, standards-based Web content, this can be rendered reliably by more user agents, including *assistive technologies* (Checkpoint 2.1). The next responsibility is to support formats that enable accessible content (Checkpoint 2.2). 21:22:32 Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that support this include ensuring that it is possible to author accessible content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4 and 2.7), automatically generating accessible content (Checkpoint 2.5), a 21:24:46 jr. 2.3 21:24:51 jt: I don't like the rationale. 21:26:29 mm: "The ability to produce accessible Web content is the most basic requirement of this document." 21:26:41 mm: This could be shortened only by saying, "duh." 21:35:53 2.4 21:36:13 jt: Still don't like criteria 1. We're still allowing people to toss accessibility information. 21:36:51 jt: What if we say to preserve things so users can go back? 21:39:33 JR: I think that as long as the author's notified... 21:39:41 jt: The author _must_ be notified. 21:49:49 2.5 21:49:58 Unless explicitly instructed otherwise by the author, the tool must generate content that conforms to WCAG. 21:50:52 Unless explicitly instructed otherwise by the author, all content generated by the tool must conform to WCAG. 21:52:40 jima has joined #au 21:58:15 2.6 21:59:03 km-dk: Preferentially licensed. There's content that comes with it, and some that's preferentially licensed. 21:59:09 mm: Bundled or pref. licensed? 22:01:27 Pre-authored content (e.g. templates, images, videos, etc.) is often included with authoring tools for the convenience of the author. Pre-authored WCAG-conformant Web content is more convenient and more easily reusable. 22:04:16 Rationale: Pre-authored content (e.g. templates, images, videos) is often included with authoring tools for the convenience of the author. When this content is WCAG-conformant, it is more convenient for users and more easily reused. 22:05:27 2.7 22:09:28 bf: Downlevel editor problem. You wrote a tool long ago, and now there's future code, what do you do with it. 22:10:18 JR: Combine 2.4 with 2.7? 22:14:21 Rationale: Preserving information during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language) is critical because it may contain *accessibility information*.Markup that is not recognized by an authoring tool may have been added to enhance accessibility. Also, newer XML-based languages, such as XHTML 1.1, allow authors to inclu 22:14:34 Success Criteria: 22:14:34 During all transformations and conversions, all unrecognized markup and accessibility information must be preserved, unless prevented by limitations of the target format. 22:14:34 When unrecognized markup or accessibility information cannot be preserved during a conversion or transformation, the author must be notified before any change is made. 22:15:47 multiple languages in a single document, via namespaces. In the future, documents may contain metadata, including accessibility information, in another namespace. Authoring tools must not remove or change [@@] this information when it is encountered 22:16:52 JR: Is this front matter? 22:20:43 Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language). *Accessibility information* should also be preserved. 22:24:14 hi Jim 22:24:16 hi jim! 22:25:12 Here is the success criteria for the workflow checkpoint: All mechanisms that guide the author in sequencing authoring actions (e.g., wizards, documentation, templates, help files) integrate accessible authoring practices. 22:25:42 I left out a must. 22:27:12 Hi Jim, everyone else is also on the bridge, can you join the bridge as well so you know what we are working on? 22:29:02 f2f dialin # 800-833-4294, code 793698 22:36:49 was called away, will dial in 22:37:23 GUIDELINE 3: Support the author in the production of accessible content 22:37:23 Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to affect the accessibility of content, either positively, if the author is purposefully following accessibil 22:37:31 Guiding the author to produce accessible content: 22:37:31 Conformance with accessibility authoring practices is an authoring constraint, analogous to producing valid code or grammatical text. Since the role of any authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. The checkpoint requirements for this section include prompting and assisting the author to create accessible content, especially for 22:37:39 Implementation Note: All functions added to support accessible authoring should be flexible enough to take into account different authoring styles. When authors can configure accessibility features to support their regular work patterns, they will be more likely to feel comfortable with their use and be more receptive to interventions from the tool. For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may pr 22:37:46 Specific considerations when providing this guidance 22:37:46 When guiding the author towards the creation of accessible content, several specific factors should must be considered. The checkpoint requirements for this section include taking care not to automatically include inappropriate equivalent alternatives (Checkpoint 3.4), providing automated means for managing equivalent alternatives (Checkpoint 3.5), and providing accessibility status summaries (Checkpoint 3.6) 22:45:14 more rationale for 3.8: 22:45:15 Accessibility should be consistent throughout the tool: in the authoring tool interface, functionality, documentation, help, tutorials and examples, and so on. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences 23:06:23 JR has left #au