Minutes from AUWG face-to-face, Gaithersburg, MD, USA, 13-14 June 2003
Attendance
jt Jutta Treviranus
jr Jan Richards
pj Phill Jenkins
tb Tim Boland
js Janina Sajka
mm Matt May
khs Katie Haritos-Shea
Regrets: Bob Regan
Minutes
Review of Kynn's comments
jt: I think that if Kynn needs help using ATAG, anyone would need help.
jr: I took an action item on using the process of the document. I was worried that there would be a big chain reaction of checkpoints (prompting, etc.), but I don't think that's the case.
jt: One change was to the word "output" rather than "use". Still an issue of what happens when one format becomes more standard than another.
pj: I like his idea of moving 2.2 in front of 2.1 because of priority.
jt: Is there a more general edit to be made of the overall guideline?
jr: 2.3 through 2.7: the order is P1, P1, relative, relative, P2. Where does relative priority go, if we order by priority?
mm: I'd prefer that they be in logical sequential order rather than priority.
pj: 2.1 and 2.2 should be reordered, then.
mm: Agree.
jr: Sequence of checkpoints 2.3 to 2.7 looks logical to me.
tb: Not in order RP follows P1
jt: We have multiple orders
pj: Depends on tool type (conversion tools different)
pj: GL3 looks well ordered
jr: What about 3.4-3.6 - they act as modifiers for 3.1-3.3
pj: Yes + we should still put it in another document
jr: Proposed wording for a subheading for 3.4-3.6: "Specific considerations when providing this guidance:"
AGREED: "Specific considerations when providing this guidance:" for subheading in 3.4-3.6
jr: Let's go back and join the structure checkpoints
js: Both checkpoints are important - we need to keep both ideas.
jr: Is "Select parent", "select child", "select sibling" enough for the success criteria?
js: Yes
jt: Ensure "select"
jr: Ensure "editing at the level of sections of tree"
jt: Proposes: "Ensure that the authoring interface enables the author to navigate and edit using the structure."
jr: Proposed: "Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits"
AGREED: "Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits"
tb: "Quickly and easily" is problematic in success criteria.
Going through Kynn's comments...
jt: Does graded system make sense for checkpoint 1.1
pj: What about pointing to 508?
jt: What about barrierfree Europe.
jt: What about UAAG?
pj: Does all apply?
jr: Relevant checkpoints? 6.5, 6.7, 7.1-7.4,
jr: What about getting the IBM software guidelines donated as a W3C Note for AUWG?
ACTION ITEM: PJ
jt: New 1.1
jr: Checkpoint text: Stays the same
jr: Rationale: Explain why important for user interface of the authoring tool to be accessible.
jr: Success Criteria: Follow requirements of note.
jt: Placeholder priority (P1 for "Required" in IBM guidelines (to be our note after submission), P3 for "recommended".
AGREED: "Ensure that the authoring interface follows applicable software accessibility guidelines.
AGREED: Sub-heading "Specific considerations when designing an accessible authoring interface"
AGREED: Define Accessible language format: Content can conform to WCAG [??? and at least one user agent exists that conforms to UAAG ???].
jt: No problem with ordering of rest of checkpoints in Guideline 1
jr: If he's confused, need to consider that
jr: In Rationale for 1.2, add text-level source editors (these are fine)-clarify?
jt: everything in 1 fits under 1.1 - do we want to highlight this point?
jr: add subheading for 1.2 to 1.5 similar to that for 3.4 to 3.6?
jt: there is a 1.6 currently in the draft
jr: this becomes 1.5
jr: adds subheading text as "specific considerations when designing accessible authoring interface"
jt: if comply with 1.1, do comply with others after it?
jr: not necessarily
jt: 1.3 doesn't apply to anything that doesn't have publishing view?
jr: need to be more clear - in order to view the document as created, separate from default document view
ACTION : jt clarify the rationale
jt: don't require rendered vs, markup in 1.6 - is 1.6 accessibility technique?
jr: whatever is appropriate for the tool to search on..
jr: search is appropriate to editing view - add to "success criteria" for 1.6
ACTION : jr add text as line above
jt: 2.1 leaving "use" but adding "w3c format recommendations"
pj: something should not only be accessible if it's w3c - there are other non w3c specs that are accessible
jr: use open standards that have been reviewed for accessibility?
mm: the content can conform to WCAG and user agent can conform to UAAG
js: our scope is w3c
pj: can't have approach that forces vendor neutrality
jr: put in "intro" that this is for w3c formats - strip out "W3C rec.." from 2.2 replace with "language formats"
mm: languages conforming to WCAG?
js: need to check conformance platform by platform
pj: which file fomats do authoring tools need to support for ATAG compliance?
jr: how do you know file format is accessible?
mm: no value in accessible authoring tool if there's nothing to which it can claim accessibility
mm: ATAG plus content guideline production suite (508, WCAG, etc.) - whatever you're claiming
jr: too wide.. get into trouble decoupling from rest of WAI
pj: in "intro" mention use of proprietary formats
jr: can use language format as long as there's a WCAG techniques document associated with it?
jt: what if there's no techniques document?
jr: in success criteria, one technique for each priority 1..?
jr: w3c-WCAG, non-w3c techniques document that has 1 technique for each Priority 1 WCAG checkpoint
pj: file format and WCAG come together in 2.3
pj: need techniques for every WCAG checkpoint
mm: w3c will not host techniques documents..
jr: needs to be WCAG techniques document (in public space linked by w3c) for standard - in Intro?
pj: define "latest" in 2.2?
mm: Is timing a barrier to development?
jr: assumption is that things get more accessible over time-is it so?
pj: does XHTML has WCAG techniques?
mm: one being worked on..
jt: dates make 2.2 very complex - drop 2.2 and put language in intro (scope)? Enhance 2.3?
jt: consensus to do this
jr: fine supporting non-w3c as long as there's a WCAG techniques document associated with it
pj: 2.4 definition of accessibility information needs to link back to scope
pj: which WCAG Checkpoints should tool automatically do?
jr: anything which author doesn't have direct access to..(depends on ingenuity of user)
js: need definition of "automatically generate"
jt: when tool makes choice, it must be an accessible choice; if not enough info, give choice to author
pj: in 2.5, Rationale refer to other checkpoints
pj: in 2.5, success criteria, #3
jr: in 2.5, remove #3 from success criteria - it belongs in rationale and scope
pj: in techniques for 2.5, refer to techniques for managing multimedia types
jr: in 2.5, remove #4 - it is a technique
jt: what does "author's generalized choice" mean - put text to that effect in rationale
jt: 2.6 no problem? Success criteria #1 'changed'-'preferential' meaning?
pj: describes IBM's bundling practices - whatever the user is licensed to receive
jt: don't choose to give preferential offerings unless accessible - not success criteria?
pj: replace 'preferential' with 'tool license' 2.5 success criteria
pj: can't package ATAG compliant stuff with non-ATAG compliant stuff?
ACTION : pj talk to legal staff re
pj: 2.7 should we force authoring tools to open markup it doesn't support?
mm: 2.7 since content valid, should recognize everything in there (except for other schema)
ACTION : mm create an example of accessiblity content being in one schema..
jr: 2.7, reword 3rd sentence "in order to vaoid stripping unregognized content, it is acceptable to refuse to open
jr: document" - make it #3 success criteria
jt: 3.1 checkpoint change to "prompt and assist the author to create accessible content"
jt: remove "typical" #2 of success criteria for 3.1
jt: change "users of the tool" to "authors" in rationale for 3.1
jt: "prompting" may be combined...3.1
jt: 3.2 #2 success criteria remove "typical" change "A' to "the"
jt: 3.3 no change
ACTION : jr put explanatory text in "specific considerations.." before 3.4
jt: 3.4 add "what equivalent content can be known with certainty" in techniques document
jt: 3.4 remove #3 success criteria
jt: 3.5 success criteria #2 "the tool offers these alternative equivalents to the author"
mm: 3.6 like licensing ER tool
jt: 3.6 insert "able" #2 success criteria
Saturday, 14 June
jt: Objective to review remaining checkpoints and Kynn Bartlett's comments and then come back and review success criteria
jt: Starting at 3.7 [reads checkpoint]
jr: Discussions about "typical author" begins
tb: "Typical Author" is subjective, needs a description.
js: Suggestion to test with Typical Author is good, and to document accessibility features. Need to better explaing intent here.
jt: Came from suggestion of developers that regularly do usability testing with "typical users"
jr: Can't we add text to convey idea of this testing and whether this documentation is available.
jt: Need to link to "Typical Author" definition
ACTION : pj add definition for "typical author" that is specific to the tool, not all typical authors.
pj: Difficult to determine cause of problem when user can't do task, is it the missing feature, missing documentation, or is it design/integrated poorly?
pj: Need to move user testing to ckp that covers "natural integration".
jt: Good point. Lets rediscuss when we review Success Criteria.
jt: 3.8 Rationale contains too much about Natural integration - which is covered in 4.4
jt: Change Rationale in 3.8 to only include the process, not the integration.
AGREED: Change 3.8 rationale to: "Authors will be more likely to use features that promote accessibility if they understand when and how to use them."
Guidelines 4 Integration
jt: 4.1
jr: Don't like checkpoint refer to other checkpoint numbers.
jt: Should we actually list the words from the checkpoints?
jr: What if we just used the keywords?
js: Add cross references, link, so that when reading you can find the info.
js: need a doc writing tools to track changes.
pj: Propose Ensure that "accessibility prompting, checking, and repair functions are always clearly available to the author.
jr: Change wording in 3.3 from correcting to repairing?
mm: Rather have repair in both places - group agrees.
mm: Need to create a list of terms
ACTION : tb to keep list of terms from meeting
jr: Would like to change "Check for" to Evaluate to be more consistent with "Evaluation & repair" tools title.
jt: PJ, myself and others prefer "checking, checker, etc. to Evaluating, evaluator, etc.
jr: agrees
ACTION : JT, JR, Change Success Criteria to replace "Accessibility related features" with "Prompting, checking, and repair..." with appropriate links to ckpt 3.1, 3.2, 3.3.
tb: Red flag on terms like "readily", easily, etc.
jt: Do we want to keep the "uability test with typical authors" as part of the success criteria? Let's discuss later when we discuss success criteria.
jr: 4.2
pj: Need to remove terms like most obvious, easily,
jr: Need to idently 4.2 deals with choices
jt: need objective measure in checkpoint - agreed that success criteria is more important than checkpoint.
mm: Need to think in scenarios to explain this better.
jt: To distinguish from 4.1 is that 4.2 deals when there are choices.
jr: Proposal: "4.2 Ensure the most accessible authoring option is given priority."
jt: Work on Success Criteria later.
jr: Reading Kynn question about raising the priority of 4.2
jt: Stays 2 because it is about integration and usability - lower priority.
4.3
jt: 4.3 is a success criteria nighmare.
jr: let's limit 4.3 to "prompting, checking and repairing" functionality? group agrees!
jt: Change 4.3 to mention functionality - reword 4.3
jr: Proposal: "Ensure that accessibility prompting, checking, and repair functions are naturally integrated into the overall look and feel of the tool."
pj: Add Documentation to 4.1, 4.2, and 4.3, drop 4.4
jr: beef up 3.7 & 3.8 to include "what and how, ie.e, examples" in documentations
ACTION : mm,jr reword 4.1 to include documentation
ACTION : mm,jr add #3 success criteria to 4.2
ACTION : mm,jr reword 4.3 to include documentation
ACTION : mm,jr drop 4.4 and move success criteria to 3.7 and review
ACTION : mm,jr move old 4.4 techniques to 3.7, 4.3, etc.
jt: 3.7 is what and low level how's
pj: 3.8 is high level or overall process - agreed.
jt: Reviewing Guideline 3 and 4
AGREED: old 4.4 goes to guideline 3 or 4, majority agrees with moving old 4.4 to guideline 3
AGREED: Move old 4.4 to "documentation subheading" in guideline 3
jt: where does old 4.4 best fit in 3.7 and 3.8?
AGREED: Renumber old 4.4 to 3.8 and move 3.8 to 3.9.
ACTION : mm,jr Fix 3.9 ckpt wording, add overall highlevel process
ACTION : mm,jr Fix Guideline 4 - add promote
ACTION : mm,jr Review new 3.8 criteria.
3.8 Success Criteria:
mm: Make them all [new 3.8 Success Criteria] imperatives. i.e., must shall, etc.
khs: merge 1 & 2
jr: appropriate WCAG is a qualifier to 1, so agree to merge.
jt: 1 and 2 success criteria (SC) can't contratict each other.
AGREED: All markup code example ...
AGREED: All authoring tool examples, including screen shots...
AGREED: link "applicable WCAG" to notes following 2 success criteria in new 3.8
Discussion of 3.9 "document work flow process".
ACTION : jr to create example/sample work flow process as a technique. Keep 3.9 SC 2 on tools that lack features to describe workarounds.
jr: reword guideline 4:"Promote and integrate accessibity solutions..."
AGREED: new Guidelines 4 wording.
Success criteria
jt: Need to deal with regular accessibitly testing of tools in the Success Criteria. Many SC's have "typical Author...". We may need to describe that it is there and why it's there.
ACTION : mm to add a class so that we can pull out the usability stuff for a seperate module.
jt: other part is to review criteria for objectivity, measurable, etc. (using Tim's comments)
AGREED: orderlist for success criteria
AGREED: take out of SC non-normative text
ACTION : jr reword 1.1 SC1 to
jt: need subheading for rest of 1.x checkpoints in guideline 1
1.2
ACTION : mm to add subheading "Specific
AGREED: take all from 1.2 ckpt.
AGREED: replace supported by the tool with editable by the tool.
ACTION : jr,tb Work on success criteria
ACTION : tb Send terms for glossary work
ACTION : tb Introduction on success criteria
ACTION : mm Create a CSS class for usability testing modules
ACTION : pj Look into submitting IBM Software Accessibility Guidelines
ACTION : pj Define preferential content (legal/licensing) as part of the tool
ACTION : jt Create usability test insertion modules
ACTION : jr,pj Create example sample workflow process
ACTION : jr Work on a section describing how the guidelines integrate together
mm: Next face-to-face: Seattle, late September, around Dublin Core?