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

Farily extensive external comments on ATAG 2.0

From: Jan Richards <jan.richards@utoronto.ca>
Date: Fri, 24 Feb 2006 11:19:06 -0500
Message-ID: <43FF31FA.9010100@utoronto.ca>
To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>


These are comments that Barry has collected:

(Thanks Barry, this will give the group a lot to work on!)


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."


ATAG glossary should be consistent with WCAG 2.0 glossary. For example,
the definition of a keyboard interface. You may have a voice reco
system. Using a voice reco system to insert text should not be precluded
by having a physical keyboard to also do the insertion.


Some people still don't understand how the Relative Priority items are
  "Some are clear, while others could be issues for meeting ATAG
compliance.  For example, can you give a better explanation of how a
specific checkpoint like B.2.2. will apply to tools if we say all tools
must meet all ATAG P1 guidelines while conforming to WCAG 2.0 and not
WCAG 1.0."

Guideline specific comments:


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.


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."


"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.


A.2.4 Allow authors to avoid content that could cause seizures due to
photosensitivity. [Priority 1]   - Are sure you don't want to just allow
the user to be able to control the rate as opposed to just turning off
flashing. What determines flashing? Some flashing is not harmful. This
seems like an all or nothing.


A.2.5 For usable access suggest this be a P1. Users have problems with
model-based authoring tools because of this today.


A.3.2 For usable access suggest the be a P1. *Maintain consistency
within the authoring tool user interface. [Priority 2]*


Suggest documenting accessibility implementation for AT vendors be a P3?
For example, this would encompass what MSAA APIs were supported per widget.


The techniques outlined for "Maintain consistency" sound like P1 items,
not P2.  Especially in a tool, you don't want icons to have more than
one function or UI controls performing multiple functions. Making the
Authoring UI understandable takes more than just documenting
accessibility features.  I think many items in A.3.2. techniques should
be P1 for this guideline.


A.4.1  Concern over how tough this is to enforce (i.e., what version
number of JAWS, which AT products?)


B.1.1 Comment received ("not sure I understand it"): For example,
PowerPoint can be delivered from the Web - per WCAG 2. Why not limit
this to any technology delivered through the Web? WCAG 1.0 does not fit
this mold due to its HTML- like dependencies but WCAG 2 does.


Support of new content types is not clear.  For example, does the
success criteria for *Support content types that enable the creation of
Web content that conforms to **_WCAG_*
mean that if a company develops or uses a content type and
there is no content-type specific WCAG benchmark then the tool is not
compliant?  Does this get us into the type of situation we had with
JavaScript in WCAG 1.0 where it was supported, but you still couldn't
implement a JavaScript site and be WCAG compliant?


B.1.2 Comment: For recognized markup - this should be a P1.

Why would this be a P2?  If a new technology comes along with
unrecognized markup, shouldn't the tool preserve that?  [When]
accessibility information is not preserved ... the authors have to add
it back in.  What is the rationale for being P2?

Perhaps we need to make a statement on recognized markup, i.e., it must
be preserved!


B.1.4 Need to better explain relative priority.


B.2.1 - B.2.3 General issue if you make use of tool by PwD P1 and you
make authoring content for PwD something less (say RP).   Some audiences
may choose to make authoring more critical than use by PwD.


B.2.1 *Prompt and assist the author to create content that conforms to
B.2.2 *Check for and inform the author of accessibility problems* and
B.2.3 *Assist authors in repairing accessibility problems*


Many vendors do not do prompting and/or repair in current
tools. This could be a major issue for them.  [Some vendors have] tools
that make it possible (with a lot of work) to create accessible content,
but there is no prompting.  This is a relative priority, so its unclear
the exact impact to these companies.

Commenter's opinion: Its not that they shouldn't provide this support,
but we don't understand the impact since these are Relative Priority.


B.2.6 *Provide the author with a summary of accessibility status*.  This
is a P3 but seems more doable than the Relative priority items in B2.1,
B2.2, and B2.3.  Why would this be P3, seems more like P2 according to
the ATAG definition of priority.


B.2.7 Suggest this be P1. This seems in conflict with what is trying to
be accomplished. How can anyone use the authoring tool to accomplish the
task of producing accessible content if in fact that author does not
know the capabilities of the tool? Example require keyboard access
features to be documented.


*B.3.2 Ensure that accessibility prompting, checking, repair functions,
and documentation are always clearly available to the author. [Priority
2] *as P2 is inconsistent with all checkpoints in B.2.x.  If you say it
isn't Priority 1 to make the features described in B.2.x available, then
does that mean you don't have to do them?


Received on Friday, 24 February 2006 16:20:35 UTC

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