re: Issue #1: 1. Definitions needed for a number of terms

Thank you for checking WAI glossary for these terms.  I still have a 
concern that some of these terms (although not yet in WAI glossary) may 
have explicit or implicit definitions buried in other WAI specs (or are 
applicable in other WAI specs), and where the terms are not AUWG-specific, 
I feel that we should get some input from other affected WAI working groups 
pertaining to our definitions (or statement that they have no interest in 
our definition of a particular term, or notification to them that we are 
talking about definitions for these terms), because I believe that the 
existence of common definitions that may reach across WAI WGs may become 
important when it comes time to indicate whether or not a specification 
applies for purposes of testing, for example, and it is better to resolve 
these issues now rather than later (not to mention that it emphasizes WAI 
coordination to everyone).

Thanks and best wishes, Tim Boland NIST

PS - Also, for definitions involving web content,  I feel we should refer 
to WCAG whenever we can..

At 11:00 AM 2/8/2004 -0500, you wrote:

>Hello everyone,
>
>Here is an updated list of the outstanding ATAG terms (I'm trying to keep all
>the terms together so none get lost).
>
>====================================
>Terms dropped:
>====================================
>
>At Feb 2 Telecon
>(http://lists.w3.org/Archives/Public/w3c-wai-au/2004JanMar/0051.html):
>
>ACCESSIBLE METHOD
>DISCOVERABLE
>EXCEPTION
>INTERFACE PRIORITY
>
>
>====================================
>Terms agreed on:
>====================================
>
>At Feb 2 Telecon
>(http://lists.w3.org/Archives/Public/w3c-wai-au/2004JanMar/0051.html):
>
>AUTHOR (No WAI glossary def'n):
>For the purposes of this document, an author is a user of an authoring tool
>
>INFORMATION ICON (No WAI glossary def'n):
>Any graphic that an author can select to receive additional information.
>
>TECHNIQUES (No WAI glossary def'n)
>Informative suggestions and examples for ways in which the success
>criteria of a checkpoint might be satisfied.
>
>TYPICAL AUTHOR (No WAI glossary def'n)
>A typical author is a hypothetical individual who possesses levels of
>authoring knowledge, tool proficiency, and experience with accessibility
>issues that fall at the mean of the levels measured from a large random 
>sample
>of actual users of an authoring tool.
>
>
>====================================
>Terms still to define:
>====================================
>
>ACCESSIBLE CONTENT (No WAI glossary def'n)
>
>=>Feb 2 Telecon Outcome: KM,JR to propose rewording:
>
>KM: 4 potential wordings:
>
>1) Content displayed by a user agent that is perceivable, operable, and
>understandable.
>
>1a) Content displayed by a user agent that is perceivable, operable, and
>understandable by all users.
>
>2) Content that is perceivable, operable, and understandable when displayed
>in a user agent.
>
>2a) Content that is perceivable, operable, and understandable by all users
>when displayed in a user agent.
>
>Discussion at: http://lists.w3.org/Archives/Public/w3c-wai-
>au/2004JanMar/0055.html
>
>
>JR:I don't think it's necessary to parallel the wording from WCAG (what if it
>changes?). Instead I'd like to suggest changes to a number of related 
>terms so
>that they fit together smoothly. (**) show links to defined terms:
>
>ACCESSIBILITY (some of the old text could go in the introduction)
>Within these guidelines, the concept of accessibility has two senses:
>- *accessible web content* refers to the content produced by tools being
>accessible by people regardless of disability, and
>- "accessible authoring tool interface" refers to the tools, themselves, 
>being
>accessible by people regardless of disability.
>
>ACCESSIBILITY INFORMATION
>Any information that is necessary for an *accessible authoring practice*
>including, but is not limited to, *equivalent alternative information*.
>
>ACCESSIBILITY PROBLEM (AUTHORING TOOL INTERFACE)
>*Authoring tool interface* features that fail to meet the success criteria of
>the checkpoints of ATAG2.0 Guideline 1.
>
>ACCESSIBILITY PROBLEM (WEB CONTENT)
>Web content that fails to meet the requirements of the *Web Content
>Accessibility Guidelines (WCAG)*.
>
>ACCESSIBLE AUTHORING PRACTICE
>Web content modifications made by the author or the tool that increase the
>likelihood of producing *accessible Web content*.
>
>ACCESSIBLE WEB CONTENT
>Web content with no *Web content accessibility problems*.
>
>ACCESSIBLE AUTHORING TOOL INTERFACE (new term)
>*Authoring tool interfaces* with no *Authoring tool interface accessibility
>problems*.
>
>
>====================================
>
>
>APPLICABLE WCAG REQUIREMENTS (No WAI glossary def'n)
>
>JR: Those WCAG checkpoints that could reasonably to applied to the web 
>content
>produced by an authoring tool. A WCAG checkpoint is "not applicable" only if
>the authoring tool lacks the capability to produce content that could fail 
>the
>checkpoint. However, the inability of an authoring tool to pass a checkpoint
>does not make the checkpoint "not applicable".
>
>=>Feb 2 Telecon Outcome: TB to propose rewording:
>
>TB: (http://lists.w3.org/Archives/Public/w3c-wai-au/2004JanMar/0053.html)
>those requirements associated with the word "WCAG" whereever it appears in 
>the
>text of any ATAG success criterion?   The particular "WCAG" documentation
>referenced to find those requirements is specified according to "Resolving
>ATAG2.0 References to WCAG"  document
>
>JR response: I still think its important to say in the normative document 
>that
>only those WCAG requirements that can't be failed by a tool count as not
>applicable. (of course the reference to WCAG should go through the "Resolving
>ATAG2.0 References to WCAG" document.
>
>
>====================================
>
>AUTHORING TOOL INTERFACE (No WAI glossary def'n)
>
>JR: The means by which an authoring tool is operated by an author.
>
>=>Feb 2 Telecon Outcome: JR to add idea of display.
>
>JR: The means by which an author operates an authoring tool and receives
>information on the state of the tool.
>
>
>====================================
>
>CHECKING (WAI glossary: ATAG only)
>
>KM: Checking refers to built-in mechanisms in the authoring tool that bring
>accessibility problems to the author's attention through some form of
>notification. Notifications can take various forms as described in ATAG
>Checkpoint 3.2. Checking can be considered a reminder of corrections that
>should or must be made.
>
>JR: The process by which web content is searched for accessibility problems.
>
>=>Feb 2 Telecon Outcome: JR - rework (with no author notification, make sure
>to encompass real time, add ref to 3.2)
>
>JR(This is meant to replace the current def'n of "Check for" as well):
>The process by which web content is searched for accessibility problems. This
>applies to searches performed automatically or with assistance from the
>author. The search may be performed at specific times or be performed on an
>continuous basis as Web content is modified. For more information on 
>checking,
>see ATAG checkpoint 3.2.
>
>
>====================================
>
>REPAIR (ING?) (No WAI Glossary def'n)
>
>KM: Repairing refers to correcting, completing, deleting, or replacing 
>whatever
>elements are giving accessibility problems. Suggested methods for dealing
>with repairs are described in ATAG Checkpoint 3.3.
>
>JR: The process by which web content, identified as an accessibility problem,
>is modified (corrected, completed, or deleted) so that no accessibility
>problem remains.
>
>=>Feb 2 Telecon Outcome: Action JR - rework (add ref to 3.3)
>
>JR: The process by which Web content is modified to solve accessibility
>problems. This applies to modifications performed automatically or with
>assistance from the author. For more information on repairing, see ATAG
>checkpoint 3.3.
>
>
>====================================
>
>WORKFLOW (No WAI glossary def'n)
>
>KM: The entire sequence of steps or tasks that are followed to produce a
>deliverable.
>
>=>Feb 2 Telecon Outcome: Action JT - Rework JT's def'n (add'n of habitual,
>familiar process); Action KH - send earlier iterations to JT
>
>KH,JT?
>
>
>====================================
>
>
>--
>Jan Richards, User Interface Design Specialist
>Adaptive Technology Resource Centre (ATRC), University of Toronto
>
>   Email: jan.richards@utoronto.ca
>   Web:   http://www.geocities.com/janrichards/staff/richards.html
>   Phone: 416-946-7060
>   Fax:   416-971-2896

Received on Monday, 9 February 2004 10:37:29 UTC