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

...and this time with the attachment.

-Jan



Jan Richards wrote:
> 
> 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?
>>
>> ==================================================
>>