Re: Fairly extensive external comments on ATAG 2.0 - All comments

Hi everyone,

My piece by piece approach to these comments was getting hard to keep 
track of, so I've made up a new version of our comments table with the 
comment issues in the 2nd column and my proposals in the third column. 
New text (proposals or my comments) are labelled "[NEW]" in displayed in 
bold.

See attached.

Thoughts?

Cheers,
Jan




Jan Richards wrote:
> 
> Hi,
> 
> These are comments that Barry has collected:
> 
> (Thanks Barry, this will give the group a lot to work on!)
> 
> [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."
> 
> 
> [2]
> 
> 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.
> 
> [3]
> 
> Some people still don't understand how the Relative Priority items are
> calculated.
>  "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:
> 
> [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.
> 
> 
> [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."
> 
> 
> [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.
> 
> 
> [7]
> 
> 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.
> 
> 
> [8]
> 
> A.2.5 For usable access suggest this be a P1. Users have problems with
> model-based authoring tools because of this today.
> 
> 
> [9]
> 
> A.3.2 For usable access suggest the be a P1. *Maintain consistency
> within the authoring tool user interface. [Priority 2]*
> 
> 
> [10]
> 
> Suggest documenting accessibility implementation for AT vendors be a P3?
> For example, this would encompass what MSAA APIs were supported per widget.
> 
> 
> [11]
> 
> 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.
> 
> 
> [12]
> 
> A.4.1  Concern over how tough this is to enforce (i.e., what version
> number of JAWS, which AT products?)
> 
> 
> [13]
> 
> 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.
> 
> 
> [14]
> 
> 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_*
> <http://www.w3.org/TR/2005/WD-ATAG20-20051123/#Relationship-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?
> 
> 
> [15]
> 
> 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!
> 
> 
> [16]
> 
> B.1.4 Need to better explain relative priority.
> 
> 
> [17]
> 
> 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.
> 
> 
> [18]
> 
> B.2.1 *Prompt and assist the author to create content that conforms to
> **_WCAG_*
> <http://www.w3.org/TR/2005/WD-ATAG20-20051123/#Relationship-To-WCAG>.
> B.2.2 *Check for and inform the author of accessibility problems* and
> B.2.3 *Assist authors in repairing accessibility problems*
> 
> 
> [19]
> 
> 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.
> 
> 
> [20]
> 
> 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.
> 
> 
> [21]
> 
> 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.
> 
> 
> [22]
> 
> *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?
> 
> ==================================================
> 
> Cheers,
> Jan
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Friday, 3 March 2006 13:36:16 UTC