W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2004

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

From: Jan Richards <jan.richards@utoronto.ca>
Date: Sun, 8 Feb 2004 11:00:21 -0500
Message-ID: <1076256021.40265d1535c0d@webmail.utoronto.ca>
To: w3c-wai-au@w3.org

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


Terms agreed on:

At Feb 2 Telecon

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

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-

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.

Any information that is necessary for an *accessible authoring practice* 
including, but is not limited to, *equivalent alternative information*.

*Authoring tool interface* features that fail to meet the success criteria of 
the checkpoints of ATAG2.0 Guideline 1.

Web content that fails to meet the requirements of the *Web Content 
Accessibility Guidelines (WCAG)*. 

Web content modifications made by the author or the tool that increase the 
likelihood of producing *accessible Web content*. 

Web content with no *Web content accessibility problems*.

*Authoring tool interfaces* with no *Authoring tool interface accessibility 



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.



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

=>Feb 2 Telecon Outcome: Action JT - Rework JT's def'n (add'n of habitual, 
familiar process); Action KH - send earlier iterations to 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 Sunday, 8 February 2004 11:00:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:49 UTC