Minutes from AUWG Face-to-Face Meeting, Los Angeles, 23 Mar 2003 telecon
Attendance
jr Jan Richards
khs Katie Haritos-Shea
br Bob Regan
ln Liddy Nevile
sh Shawn Henry
js Janina Sajka
mm Matt May
jt Jutta Treviranus
Minutes
Rationales with Jutta
jt: Created rationales where there weren't rationales.
jr: Rationale for 1.1
br: What constitutes a convention? Janina and I have been talking about GNOME accessibility. Even though that's not finished, does that constitute a convention?
jr: We addressed some of this in techniques.
br: Could be in glossary. But that's a question to be answered. If we made a custom Flash browser on an OS that had no API, and built apps on top of that, you wouldn't be using conventions of the OS because they don't exist, but you're providing accessibility.
mm: More concrete example: Java accessibility.
jr: Would "environment" be a better solution?
br: That could be good.
js: I prefer the term "environment"
jt: That's what's in the document.
br: My impression is that the rationale is supposed to fill in the gaps, and I'm wondering if we want to say how to make decisions on what constitutes a convention. Or is that in techniques?
jr: This could be in the rationale.
jt: Could we say in the techniques where the benefits to accessibility are?
jr: Without having to drill down into techniques each time, perhaps one sentence here would be helpful?
ACTION br: Explain what "operating environment conventions" are.
jt: 1.2, there was no rationale. We frequently have properties of elements, etc that are shown WYSIWYG, which is inaccessible to someone using a text reading device. Explained not accessible to screen readers, Braille displays or screen enhancers.
khs: Should say "to those technologies which read text." Not limited to ATs.
jt: Agree.
jt: One of the reasons I had in the rationale was that we were talking in generic language, and wanted to have something concrete.
js: Say "text-based tools"? Maybe say something about stuff other than ATs?
mm: Worried about scope creep.
js: Still a little confused. It's not the properties, it's the graphic itself. We want the properties exposed to a text editor.
jt: But when it's inaccessible, the properties are edited in a graphic means.
ln: Proposed text: Explicit property should be accessible to those technologiess which read text and support authors editing text.
AGREED: Adopt proposed text for 1.2
jt: 1.3 We seem to go back and forth on what this encompasses. This was to support the overall viewing and transformation. Rationale here is that when using an AT, it's hard to get an overview of the document. To edit a document, people should be able to edit the document at a less granular level. Do we want to move these structures together with 1.5? One is navigating, the other is editing the structure.
js: I agree with moving them together. I don't know if we'd confuse or clarify if we used "leaves" and "nodes".
jt: Or parent and child, lots of terms for trees.
ln: I think we can say that outline editing is an established process, and we don't need to redefine that as a control system.
js: And when you edit that, you're editing the relationships and their order.
jt: Found in the techniques document.
br: Fundamental question. Are we getting into WCAG here? Gregg's new argument that structure shouldn't be in WCAG... We're talking about how the content should be structured.
jr: 1.3 says if there is a structure, let the author edit that structure. 1.5 says let the users use that structure to navigate.
jr: I'm confused about flexibly collapsing the structure.
js: If you treasure your keyclicks, you may want to collapse everything between item 2.0 and 6.0 to get to 7.0.
jr: Seems like navigation to a point where you want to paste.
jt: I think there was just one checkpoint originally.
ln: I think it's a question of collapsing the chunks.
jt: Navigation (1.5) should go first, and the difference is that you're just moving to a place. Then in 1.3, we want to be able to edit the structure.
jr: Example: Ability to select a list, then change all the attributes of all the items. That's changing the structure of the document.
mm: There's also an issue of object models versus pure list hierarchies, where any item can become a child or parent of another. In Flash, for example, we want people to be able to take a movie clip and move it to a layer.
Definition of Authoring Tool
jr: "Any software that an author may use to create or modify Web content." Describes as categories: Text Editing, Symbol-Level Editing, WYSIWYG Editing, Graphics Editing, Content Management, Constrained Editing, Timeline Editing, Conversion
jr: Is a stock ticker that allows control of display an authoring tool? It's not a bright line between that and a constrained editing app.
js: Disagree.
br: If you are directing the ticker to display to others, then it's a tool, but if it's only for you, then it's not.
br: I see Macromedia Contribute as blurring CMS and constrained editing.
mm: Most CMS are constrained editing in some form. Weblogs, for example. We may even want to include APIs for creating Web content.
br: There are moments when plain text without assistance are going to be acceptable.
mm: Scenario: Mozilla 1.3 has rich-text textarea box now, and it should be producing good HTML out of the end.
js: Presence of Web Services in the definition?
mm: "software or service" in the definition? It may not be a "Web Service" per se, but we're still targeting Web pages that produce Web content.
jr: Add "for publication" to say that anything that is not an individual user's preference.
sh: Change "enables an author" to "enables authors".
khs: Add browsers that have authoring into the definition?
mm: We don't say that tools have to have the primary purpose of authoring content. Amaya is already a browser that is a text-level editor, a WYSIWYG editor, and a graphics editor.
Bob Regan
br: Philosophical question: should my tool allow users to create inaccessible content if they want to? The more professional the tool, the harder it is to force compliance, whereas with Contribute we do have tools to drive enforcement. In Dreamweaver, the path is toward facilitation.
br: Specifics: the user has to specify validation. There is no context menu that says you have an accessibility problem. I like the idea of saying on save that errors exist. That's all under the umbrella of facilitation. But there are some items that fall under enforcement, and I don't think I can get that into the tool.
js: My understanding is that W3C is not a policy body, it's a technology body. Enforcement comes from other entities.
jr: What's telling is that we don't have any one checkpoint that says "don't allow publication unless x".
br: I'm looking at checkpoints that say all content has to conform. Then I have to be concerned with what's possible.
js: I was thinking that e.g. Macromedia would allow a checkbox to say "I want to create accessible content."
br: I also read these documents knowing how many hours of dev time I have before the next release. More than 2 releases out, at 12-18 months each, that's a question of whether I can get things done. For example, using headers for navigation. Dreamweaver has nothing like that. I have to think how easily we can do this, because it's a fundamental shift.
jr: In the case of walking the tree, we don't prescribe that. We say to leverage what structure is already there.
br: The reality of ATAG is that there are only so many hours we have per release. There is a danger of relying on tools and feature sets that don't exist to gain conformance.
jr: We don't want to burden content authors with a huge layer of rules, because that won't help.
js: The only part that troubles me at all is that we don't really have the testing tools for snippets of code, e.g., content added via constrained editing tools. I think other tools in this arena already exist.
br: The problem to me is in legacy code. By version 5, lots of things become rocket science. My goal is to provide users with tools that I think they'll actually use.
br: There is a public perception that W3C is not responsive to the needs of business. But I think that what is happening here is helpful, and I'm trying to get my coworkers more involved. But the more reflection that occurs, the better.
mm: Is ATAG 2 an improvement over ATAG 1 in respect to streamlining the needs regarding accessibility?
br: Yes. It got us to the table.
Lunch and meeting with WCAG WG
NOTE: The working group met with the Web Content Accessibility Guidelines WG for an hour.
Rationale, pt. 2
jr: 1.4
ln: Does this provide any value?
jr: It says that authors are the ones who can require it.
ln: Added an example
jr: 1.5
jr: Rephrased for accuracy
jr: 1.6
mm: I think it's more a business case than a rationale like the others.
ACTION jr: Concise rationale for 1.6.
jr: 2.1
js: Need to clarify that "latest" is because W3C is monitoring specs to make sure they are more accessible.
ACTION jr: Rationale for the term "latest".
jr: 2.2-2.4
jr: Leave as is?
jr: 2.5
ln: Second sentence doesn't say anything.
jr: I'll strike the rest of the paragraph after the first sentence.
jr: 2.6
js: Whoever provides the pre-canned content should be responsible to see that it's accessible.
jr: Removed much of the rest of the paragraph, since it's more like techniques.
jr: 2.7
jr: Leave as is.
jr: 3.1
khs: "Prompt and assist the author to avoid creating accessibility problems..."
jr: Changed checkpoint text.
mm: Rationale seems a little awkward. Can't offer specific advice.
jr: Changed rationale text.
jr: 3.2
jr: New text: "Authors may not notice or be able to identify accessibility problems."
jr: 3.3
ln: Rationale should be "authors may not know how to correct..."
jr: "Providing assistance will increase the likelihood of authors correcting accessibility problems."
ln: Sounds like we're putting a rationale where we don't need one.
ln: Some authors will be unable to correct accessibility problems without assistance.
jr: ...others may be encouraged?
jr: "Assistance may expedite the task of correcting some authors' accessibility problems, while other authors may be unable to correct accessibility problems without this help."
jr: 3.4
jr: Leave as is.
jr: 3.5
jr: Leave as is.
jr: 3.6
jr: Minor copy.
jr: 3.7
jr: Removed "all" from "the accessibility-related features"
jr: "Without documentation of the features that promote accessibility (e.g. prompts for alternates, code validators, accessibility checkers, etc.) authors may not find or use them.
jr: 3.8
jr: "Authors will be more likely to use features that promote accessibility if they integrate them into their existing authoring practices."
jr: 4.1
jr: Jutta: "If the features that support accessibility authoring are difficult to find, activate or use, they are less likely to be used. Ideally, these features should be turned on by default."
jr: Does that last sentence belong in the rationale?
ln: It should go back to the checkpoint.
js: Agree.
jr: Leave Jutta's version as is.
jr: 4.2
ln: "Authors are most likely to use the first and easiest options."
mm: Add "the easiest way to accomplish a given task should be the most accessible one."
jr: 4.3
ln: "Authors are unlikely to depart from the authoring conventions of the tool."
mm: "diverge."
jr: "reluctant."
mm: "Most authors are reluctant to use features that depart..."
jr: 4.4
:
Next Steps
mm: Who will be in Budapest? (Bob, Phill, Liddy, Jan, Jutta, Janina)
mm: RESNA in June in Atlanta.
js: Probably won't stay around for RESNA.
khs: V2 is doing Trace in October. Dublin Core is in late September in Seattle.
mm: Montreal?