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

Re: Farily extensive external comments on ATAG 2.0 - Comments impacting checkpoint wording [1], [4], [5], [6]

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 28 Feb 2006 12:18:05 -0500
Message-ID: <440485CD.6050309@utoronto.ca>
To: w3c-wai-au@w3.org

[1]

Everything in Part A which talks to the UI of the authoring tool should
be consistent with WCAG 2.0. In general, where the ATAG guideline intent
is the same as WCAG, use the WCAG language. For example:

    1. ATAG A.2.1: "Ensure that all functionality is operable via a
       keyboard or keyboard interface." WCAG 2.0: "Make all functionality
       operable via a keyboard interface."
    2. ATAG A.2.3 : "Allow authors to control time limits on their
       reading or interaction."  WCAG 2.0: "Allow users to control time
       limits on their reading or interaction."


JR: I think we want to keep "Authors" instead of "users", but we could 
change our "ensure" to "make", etc.


[4]

A.1.3 "Ensure that displays are configurable" is not clear until you
read the success criteria.  It sounds like you are talking about
hardware displays rather than display settings.  I recommend "Make
visual and audio display settings configurable." or "Make visual and
audio display preferences configurable." I also think that "Make" is a
better verb than "Ensure" for this guideline.  You are talking about
settings for the UI of the tool, so you must *make* them configurable.

JR: I could go with: "Make visual and audio display preferences 
configurable."


[5]

A.1.4 "Allow the display preferences for the editing view to be changed
without affecting the document markup."  By saying "Allow" this implies
that the display preferences will change the document markup view and
you must provide an option to prevent that from happening.  The language
should be  "*Ensure* the document markup view is not changed when the
display preferences for the editing view are changed."

JR: Not exactly - it means don't change the markup of the content to 
accomplish particular display preferences. I could see rewording it as: 
"Ensure changes to the display preferences of editing views do not 
affect the content being edited."


[6]

"Authoring system must be access system friendly" is not strong enough.
  Being "friendly" doesn't mean that it works with AT.  I recommend
something more like  "Authoring system must work with current assistive
technology" which is more consistent with the WCAG principle that
"...content must be robust enough to work with current and future
technology".  Working and being "friendly" are two different things.

JR: "Authoring system must work with current assistive technology" works 
for me.


=============================
Here's the cumulative changes (in CAPS):

A.0.1 Ensure that browser-accessed functionality conforms to WCAG. 
[Relative Priority]

GUIDELINE A.1 Authoring Interface must be Perceivable

A.1.1 Provide text alternatives for all non-text content[REM]. [Priority 
1] [MATCHES WCAG]

A.1.2 Provide synchronized alternatives for multimedia[REM]. [Priority 
1] [MATCHES WCAG]

A.1.3 MAKE VISUAL AND AUDIO DISPLAY PREFERENCES CONFIGURABLE. [Priority 1]

A.1.4 ENSURE CHANGES TO THE DISPLAY PREFERENCES OF EDITING VIEWS DO NOT 
AFFECT THE CONTENT BEING EDITED. [Priority 1]

A.1.5: Ensure that information, functionality, and structure can be 
separated from presentation. [Priority 1] [MATCHES WCAG]

GUIDELINE A.2: Authoring Interface must be Operable

A.2.1 Ensure that all functionality is operable via a keyboard

A.2.1 MAKE all functionality operable via a [REM] keyboard interface. 
[Priority 1] [MATCHES WCAG]

A.2.2 Ensure user configurable access to selectable actions. [Priority 3]

A.2.3 Allow authors to control time limits ON THEIR READING OR 
INTERACTION. [Priority 1]  [MATCHES WCAG]

A.2.4 Allow authors to avoid content that could cause seizures due to 
photosensitivity. [Priority 1]  [MATCHES WCAG]

A.2.5: Ensure that editing views enable the author to navigate the 
structure and perform structure-based edits. [Priority 2]

A.2.6: Allow the author to search content and markup within the editing 
views. [Priority 2]

A.2.7: Provide an undo function. [Priority 2]

A.2.8: Provide personalized configuration. [Priority 2]

A.2.9: Ensure previews emulate accessible rendering features of target 
browsers. [Priority 2]

GUIDELINE A.3 : Authoring Interface must be Understandable

A.3.1: Observe the accessibility conventions of the platform. [Priority 2]

A.3.2: Maintain consistency within the authoring tool user interface. 
[Priority 2]

A.3.3: Document the authoring interface including all interface 
accessibility features. [Priority 1]

GUIDELINE A.4: AUTHORING SYSTEM MUST WORK WITH CURRENT ASSISTIVE TECHNOLOGY

A.4.1: Support interoperability with assistive technologies. [Priority 1]
Received on Tuesday, 28 February 2006 17:19:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT