W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2009

Re: [Fwd: [Fwd: re: My ATAG Glossary action items (draft)]] - finished my responses

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 16 Apr 2009 17:40:42 -0400
Message-ID: <49E7A5DA.90707@utoronto.ca>
To: w3c-wai-au@w3.org
Hi all,

Back in January Tim did a very thorough review of the document for 
glossary-related issues and general quality.

I responded in another email that either proposed solutions or explained 
why I thought a particular issue was not actually an issue 
(http://lists.w3.org/Archives/Public/w3c-wai-au/2009JanMar/0010.html)

Tim has let me know that he agrees with my responses, so I will list 
only the issues that we now agree are issues, along with the proposed 
solutions with ("----------" between each):

----------

 > Global Note:  the "[UAAG 1.0]" designations should be linked to
 > appropriate version/spec..

JR: Agreed.

----------

 > In "Definition of authoring tool" section:
 > application

CURRENT:
ATAG 2.0 defines an "authoring tool" as any application, part of an 
application, or collection of applications that authors interact with to 
create, modify or assemble Web content to be used by other people.PROPOSED:
ATAG 2.0 defines an "authoring tool" as any software application, part 
of an application, or collection of applications that authors interact 
with to create, modify or assemble Web content to be used by other people.

----------

 > embedded/stand-alone?

CURRENT:
- WYSIWYG editors, plain text editors (embedded and stand-alone)
PROPOSED:
- WYSIWYG editors, plain text editors

----------

 > In Notes on the Definition following, for #1, add "Web" in front of
 > "content"?, and

PROPOSED:
Any guidelines that require authors to modify Web content in some way 
always assumes that the person has author permission.

----------

 >  "live content authoring tool" may need definition
 > For #2, add "authoring" in front of "tool"?

PROPOSED:
APPLICATIONS THAT ARE USED TO CREATE CONTENT IN REAL TIME (e.g., chats, 
collaboration tools, whiteboards, etc.) are only required to meet Part 
A. However, many guidelines in Part B may still usefully apply, 
especially if the AUTHORING tool archives as Web content. For more 
information, please see the Techniques - Appendix E: Real-time content 
production.

----------

 > Is the "Components of Web Accessibility" section normative or
 > informative (not clear)?

PROPOSED:
- Move definition of authoring tool section to its own Normative section 
which is out of the Introduction.
- Move Levels of Conformance down to Conformance like in WCAG 2.0
- Allows Introduction to be Informative
- Relationship to the Web Content Accessibility Guidelines (WCAG) MAYBE 
should also move out and be a Normative section

----------

 > Provide a link for "WCAG2.0"?

JR: OK

----------

 > "user interface components"?

PROPOSED: Delete this sentence:
"This is especially important for user interface components that do not 
implement an accessibility platform architecture or leverage existing 
implementations (e.g. custom user interface components built via 
JavaScript and CSS)."

----------

 > In "Part B" section, add "authoring" in front of "tool"?

PROPOSED:
Generally use "authoring tool" instead of just "tool".

----------

 > and "functions related to accessibility"?

PROPOSED: change to:
"accessible content support features "

----------

 > "Success Criteria" section before "Levels of Conformance":
 > insert "middle" after "AA"?

PROPOSED:
A (lowest), AA (middle), and AAA (highest).

----------

 > Relationship to the WCAG:
 > Do we want to still list "WCAG1.0" after "e.g.", since WCAG2.0 is
 > now a rec?

OPEN:
What should we do about WCAG 1.0 reference?

----------

 > Do we want to provide a link to WCAG2.0 when used first?

PROPOSED:
Provide link to WCAG 2.0 when used first.

----------

 > WCAG-conforming?

CURRENT:
- "ATAG 2.0 Conformance Claims are supported by WCAG-conforming examples 
of Web content produced by the authoring tool..."
PROPOSED:
- "ATAG 2.0 Conformance Claims are supported by examples of Web content 
produced by the authoring tool that conform to WCAG..."

----------

 > insert "Web" before "content" (two places in paragraph)?

PROPOSED:
Generally use "Web content" instead of just "content"

----------

 > user interface (or do we want to add "authoring tool" before "user
 > interface"?

PROPOSED:
Generally use "authoring tool user interface" instead of just "user 
interface"

----------

 > Guideline A.1.2 - > A.1.2.1
 >
 > standards
 > platform conventions

OPEN ISSUE: New term:
standards and/or platform conventions that benefit accessibility

----------

 > Guideline 2.1 (should be A.2.1?):

FIX NUMBERING ERROR

----------

 > state, value, description?

PROPOSED: from WAI ARIA (http://www.w3.org/TR/wai-aria/):

State
A state is a dynamic property expressing characteristics of an object
that may change in response to user action or automated processes.
States do not affect the essential nature of the object, but represent
data associated with the object or user interaction possibilities.

Value
A literal that concretizes the information expressed by a state or
property, or text content.

Property
Attributes that are essential to the nature of a given object. As such,
they are less likely to change than states; a change of a property may
significantly impact the meaning or presentation of an object.
Properties mainly provide limitations on objects from the most general
case implied by roles without properties applied.

re: Description - WCAG doesn't define similar terms.

----------

 > 2.1.4:
 > available programmatically

CURRENT:
image label present in the content is available programmatically
PROPOSED:
image label present in the content is available via a *platform 
accessibility architecture*

----------

 > Applicability Note:
 > user agent interface

CURRENT:
user agent interface
PROPOSED:
user agent USER interface

----------

 > A.2.1.1:
 > Alternative equivalents (or equivalent alternatives - need to decide
 > which one and stick to it for consistency)

WE DECIDED ON: Alternative Content

----------

 > Guideline A.2.2:
 > Programmatic access

CURRENT:
- Provide programatic access to all information in the editing view
PROPOSED:
- Provide programatic access to information in the editing view

----------

 > A.2.2.1:
 > functional purpose

CURRENT:
the functional purpose for the modification
PROPOSED:
a description of the purpose of the modification

----------

 > A.2.2.2:
 > WYSIWYG (need to spell out?)

PROPOSED: New term:
WYSIWYG
This is an acronym for "What You See Is What You Get". A WYSIWYG user
interface displays (to authors) the content being edited in a way that 
is very similar to how it will appear to end users.

----------

 > Guideline A-3-1:
 > authoring features?

CURRENT:
Enhance keyboard access to authoring features
PROPOSED:
Enhance keyboard access

----------

 > keyboard trap

PROPOSED: New term:
keyboard trap
A user interface phenomenon in which the keyboard may be used to move
focus to, but not from, a control or group of controls.

----------

CURRENT:
Importing Content Keyboard Trap
PROPOSED:
Avoiding Content Keyboard Trap

----------

 > standard sequential keyboard command
 > direct keyboard command

OPEN ISSUE: I came up with these terms for UAAG
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html)

----------

 > focusable element

CURRENT:
will always move keyboard focus to a subsequent focusable element
PROPOSED:
will always move keyboard focus to the next element able to receive focus

----------

 > Applicability Notes:
 > keyboard navigation functions

CURRENT:
keyboard navigation functions
PROPOSED:
keyboard navigation features

----------

 > Guideline A.3.2:
 > time-dependent-interaction

CURRENT:
Enable time-independent interaction
PROPOSED:
Minimize time limits on authors

----------

 > A.3.2.2:
 > simple action

CURRENT:
can, with a simple action, select
PROPOSED:
can select

----------

 > A.3.2.3:
 > moving target
 > selectable component

CURRENT:
If the user interface includes any moving targets for authors' actions 
(e.g.,a selectable component of an animation), then authors can stop 
that movement.
PROPOSED:
If a user interface component that accepts mouse input is capable of 
movement (e.g., animated vector graphic), provide authors with the 
option to stop the movement.

----------

 > A.3.3.1:
 > static view
 > time-based content
 > fixed state

CURRENT:
If an editing view renders content (e.g., WYSIWYG) then the author has 
the global option of a static view in which time-based content appears 
in a fixed state.
PROPOSED:
If an editing view renders time-based content (e.g., animations), 
provide authors with the global option of rendering only the initial 
state of time-based content.

----------

 > Guideline A.3.4:
 > navigation
 > editing
 > content structure

CURRENT:
People who have difficulty
typing or operating the mouse benefit when authoring tools use the
structure present in the content to simplify navigation and editing
PROPOSED:
People who have difficulty typing or operating the mouse benefit when
authoring tools use the structure present in the content to simplify the
tasks of navigating and editing the content

----------

 > A.3.4.1:
 > element, contents, sub-elements (is distinction always clear?)

OPEN ISSUE: This is making me think we need an "Understanding ATAG 2.0"
document since I don't think the Glossary can necessarily clarify
absolutely everything.

----------

 > identical element

CURRENT:
next identical element
PROPOSED:
next instance of the same element

----------

 > A.3.4.3:
 > heading/level?

CURRENT:
authors can move the editing focus forward/backward to the heading
PROPOSED:
authors can move the editing focus to the heading before or the heading 
after the element

----------

 > A.3.4.4:
 > Doesn't above, below, preceding, etc. depend on navigation order?

OPEN ISSUE: Is this really unclear?

----------

 > A.3.5.1:
 > text search

CURRENT:
function is provided that allows text search of the content...
PROPOSED:
Provide the ability to search for text in the content..

----------

 > textual information/text content

CURRENT:
can search any textual information...
PROPOSED:
can search within any content that is text...

----------

 > editable?

CURRENT:
that is editable using the authoring tool
PROPOSED:
that the authoring tool can modify

----------

 > What does it mean to "perform search results"?

CURRENT:
perform search results
PROPOSED:
view search results

----------

 > instruction level?

CURRENT:
instruction level
PROPOSED:
source content

----------

 > markup tags (difference from elements?)

CURRENT:
search for markup tags
PROPOSED:
search for elements by name

----------

 > Guideline A.3.6:
 > preference settings

OPEN ISSUE: agree def'n might help.

----------

 > A.3.6.1:
 > keyboard operability settings

CURRENT:
keyboard operability settings
PROPOSED:
keyboard preference settings

----------

 > accessibility option-setting "wizard"

CURRENT:
...an accessibility option-setting "wizard" to configure options related 
to Part A
PROPOSED:
..."wizard"-type feature that helps them to configure any 
accessibility-related preference settings related to Part A

----------

 > A.3.7.1:
 > help system

CURRENT:
If a preview is provided, then it is possible to return from the preview 
using a simple action which is documented in the help system.
PROPOSED:
If a *preview* is provided, provide a *documented* keyboard accessible 
mechanism for returning to an *editing view* from the preview.

----------

 > Guideline A.4.1:
 > users (different from authors?)

EDITORIAL: Use "authors" not "users"

----------

 > A.4.1.1:
 > irreversible

CURRENT:
reversible actions
Authoring actions that, by their nature, can be completely undone so 
that the system returns to the state it was in before the action. 
Actions that are not reversible may include certain save and delete 
actions as well as actions made in a collaborative environment that 
another author has begun to work with.
PROPOSED:
reversible actions
Authoring actions that, by their nature, can be completely undone so 
that the system returns to the state it was in before the action.
*Irreversible actions* are actions that cannot be reversed and may 
include certain save and delete actions as well as actions made in a 
collaborative environment that another author has begun to work with.

----------

 > A.4.1.2:
 > setting modification

CURRENT:
setting modification is irreversible
PROPOSED:
actions are irreversible

----------

 > A.4.1.3:
 > (Web) content "undo"

CURRENT:
content 'undo'
PROPOSED:
undo action(s)

----------

 > A.4.1.4:
 > reversible authoring function

CURRENT:
Authors can reverse at least 5 consecutive reversible authoring actions.
PROPOSED:
Allow authors undo at least 5 consecutive reversible actions."

----------

 > Applicability Notes:
 > "undo" function (or undo function - need to make consistent)

SUGGEST: "undo" function

----------

 > undo history

CURRENT:
to reset the undo history
PROPOSED:
to make all previous actions *irreversible*.

----------

 > A.4.2.1:
 > documented?

CURRENT:
All features that are specifically required to meet Part A of these 
guidelines (e.g. keyboard shortcuts, text search, etc.) are documented.
PROPOSED:
*Document* all features that are specifically required to meet Part A of 
these guidelines (e.g. keyboard shortcuts, text search, etc.).

----------

 > third-party feed

CURRENT:
third-party feed
PROPOSED:
an RSS feed from a third-party

----------

 > CMS (spell out?)

EDITORIAL: OK

----------

 > markup authoring tool

CURRENT:
markup authoring tool
PROPOSED:
HTML authoring tool

----------

 > software tools

CURRENT:
Authoring Systems: As per the definition of authoring tool, several 
software tools can be used in conjunction to meet the requirements of 
Part B. (e.g. a authoring tool could make use of a 3rd party software 
accessibility checking and repair program.
PROPOSED:
As per the definition of authoring tool, several
applications can be used in conjunction to meet the requirements of Part
B. (e.g. an authoring tool could make use of a third-party plug-in
performing accessibility *checking* and *repair*).

----------

 > 3rd party (vs. third-party previous - consistency?) software 
accessibility

EDITORIAL: "third-party" everywhere

----------

 > for "WCAG" say "WCAG2.0" or provide link to latest WCAG spec?

SUGGEST: Let's provide link to "http://www.w3.org/TR/WCAG/"
OPEN ISSUE: Also put note with link to our informative intro text 
explaining the ATAG-WCAG relationship

----------

 > B.1.1.2 (and 1.1.4 and 1.1.6):
 > Web content technology options

CURRENT:
Web content technology options
PROPOSED:
options for which Web content technology to use

----------

 > accessible technology
 > task

PROPOSE: Removing:
and the tool guides the author towards the most accessible technology 
for the task.

----------

 > B.1.1.5:
 > "technology" instead of "technologies"

EDITORIAL: OK

----------

 > B.1.2.1:
 > target (or target technology?)

CURRENT:
target technology
PROPOSED:
technology of the output

----------

 > resulting content

CURRENT:
resulting content
PROPOSED:
outputted content

----------

 > B.1.2.3:
 > automatic deletion

CURRENT:
authors have the option to turn off the automatic deletion
PROPOSED:
provide authors with the option of preventing automatic deletion by the 
authoring tool"

----------

 > pre-authored content

OPEN ISSUE: Pre-authored content:
Web content (e.g., clip art, synchronized media, widgets, etc.)

----------

 > (in applicability notes)"
 > automated behavior

CURRENT:
automated behavior
PROPOSED:
automatic content generation

----------

 > Notes:
 > authoring tool processes
 > what is example of non-human author?  why do we add "human" here but
 > nowhere else?
 > authoring "choices"

PROPOSED: Removing applic. note:
Applicability Notes: Principle B.2 applies to authoring tool processes 
that interact with human authors, and the authoring choices that author 
is making or the authoring choices under the control of the authoring 
tool. Authoring choices include choice of style sheets, templates, 
scripts, etc

----------

 > (typo - "uideline" should be "Guideline")
 > B.2.1.1 (2.1.3 and 2.1.5 - misnumbered - should be B.2.1.2 and B.2.1.3):

EDITORIAL: OK

----------

 > information (difference from "Web" content)

EDITORIAL: Check "Information" vs "Web content" throughout
SUGGEST: Add "(e.g., file location)"

----------

 > B.2.2.1:
 > individual check

PROPOSED: Use "test" instead of "check" - already used in defn of checking

CURRENT:
At least one individual check is associated with each WCAG Level A 
Success Criterion that the tool has the functionality to modify (e.g., a 
tool that inserts images should check for alt text; a tool that can edit 
captions should check for them).
PROPOSED:
For each WCAG Level A Success Criterion that the authoring
tool has the functionality to meet, provide at least one test of the
criterion (e.g., an authoring tool must check the contrast of images
only if it may be used to edit images).

----------

 > (available to whom?  the author? user of the authoring tool?)

EDITORIAL: add "to authors"

----------

 > relevant "Web" content
 > (this text is confusing to me - "identified" used twice in different
 > contexts?)

CURRENT:
B.2.2.3 Help Authors Locate: For any checks that require author judgment 
to determine whether a potential accessibility problem is correctly 
identified (i.e., manual checking and semi-automated checking), the 
relevant content is identified (e.g., displaying the surrounding text, 
"Is a sign language interpretation provided?") (Level A)
B.2.2.4 Help Authors Decide: For any checks that require author judgment 
to determine whether a potential accessibility problem is correctly 
identified (i.e., manual checking and semi-automated checking), 
instructions are provided to help authors to decide. (Level A)

PROPOSED:
B.2.2.3: Assist Author Decision-Making: If a test requires authors to 
decide whether an accessibility problem actually exists (i.e., in manual 
and semi-automated checking):
- provide authors with information about the location of the potential
problem (e.g., line number, highlighted rendering, text instructions, etc.).
- provide authors with instructions to help them decide if a problem
actually exists.

----------

 > B.2.2.8:
 > accessibility status

CURRENT:
accessibility status
PROPOSED:
the existence of Web content accessibility problems

----------

 > resource discovery

PROPOSED: Remove:
" to facilitate resource discovery by end users"

----------

 > Applicability Notes:
 > authoring experience

CURRENT:
authoring experience
PROPOSED:
"user experience of authors"

----------

 > authoring process

CURRENT:
This guideline does not apply if the authoring tool controls the 
authoring process to such an extent that it is not possible for authors 
to introduce accessibility problems.
PROPOSED:
This guideline does not apply if the authoring tool user
interface limits author options such that it is not possible for them to
introduce accessibility problems (e.g., some content management systems).

----------

 > Guideline B.2.5:
 > accessible template

CURRENT:
If authors can use the authoring tool to create new templates for use by 
a template selection mechanism, they have the option to record the 
accessibility status of the new templates
PROPOSED:
If the authoring tool provides templates options for a task, then at 
least one option template options meets WCAG Level A when used.

----------

 > B.2.5.3:
 > accessibility status

CURRENT:
Indicate: the selection mechanism indicates the accessibility status of 
templates
PROPOSED
Indicate: the selection mechanism indicates the WCAG level at which the 
templates meet WCAG when used.

----------

 > B.2.5.5:
 > new (template)

CURRENT:
If authors can use the authoring tool to create new templates
PROPOSED:
If authors can use the authoring tool to create their own templates

----------

JR: I think the group needs to revisit Guideline B.2.5 to be sure what 
is being said.

----------

 > B.3.2.1:
 > "Functionality" instead of "function"?

EDITORIAL: Or "features" perhaps.

----------

 > relevant to (how measured?)

PROPOSED: "required for Level A WCAG conformance"

----------

 > "complete" the "function" - awkward?

PROPOSED: "complete us of the feature"

----------

 > relevant to (how measured?)

PROPOSED: "required for Level A WCAG conformance"

----------

 > available to whom?  author?

PROPOSED: Add "to authors"

----------

 > B.3.3.1:
 > active

CURRENT
active
PROPOSED:
Turned "on"

----------

 > B.3.3.2:
 > deactivate/reactivate a feature?

PROPOSED: "Turn 'off'/turn 'on'"

----------

 > documented

PROPOSED: Link to "documentation"

----------

 > B.3.4.2:
 > accessible authoring process

CURRENT:
A tutorial on the accessible authoring process that is specific to the 
authoring tool is provided.
PROPOSED:
Provide a tutorial, specific to the authoring tool, that demonstrates 
how content conforming to WCAG can be produced.

----------

 > what does "available" mean in this context?

PROPOSED: Remove: "that is available"

----------

 > non-user agent platform

CURRENT:
non-user agent platform
PROPOSED:
platforms that are not user agents

----------

MAKE SURE ALL GLOSSARY TERMS ARE LINKED WHEREVER THEY APPEAR
- underline everywhere using the less obtrusive WCAG defined
term style

Cheers,
Jan
Received on Thursday, 16 April 2009 21:41:20 UTC

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