Initial reaction to Adobe comments on ATAG2

Hi all,

Because this was received today, during the F2F, my comments are unfortunately short and are primarily whether the comments are new or lending support to issues already raised.

ATAG Comments - Adobe Systems
September 2010
Adobe Systems is pleased to offer comment on ATAG 2.0.  The working group work is appreciated, but Adobe seeks clarification on some success criteria and modification or removal of others to ensure that the standard is testable, harmonized with WCAG 2.0, and able to be supported by authoring tool vendors such as Adobe.  Please consider the following comments and feel free to convey questions or requests for clarification through Adobes AUWG member.

Conformance leveling comment: It is not entirely clear how ATAG differentiates between levels for SC's.  It is clear what the set of criteria that are used is, but not how they are applied.

JR: New comment.
	
A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow accessibility standards and/or platform conventions that support accessibility.
Comment: Which platform conventions?  This needs to be more clearly defined.

JR: Issue already raised.

A.2.1.1 Recognized Alternative Content: If recognized alternative content is available for editing view content renderings, then the alternative content is provided to authors.
Comment: This is understandable enough for me, having experience with the WCAG document, but the language does make it hard to parse.

JR: Issue already raised.

A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views) without affecting the web content to be published.
Comment: Sounds like authors should be able to set a high-contrast mode that affects my authoring tool UI and NOT the content being authored as viewed in the auth tool.  Suggest "without affecting the appearance of published web content".
Comment: Also, why is A.2.3 separate from A.3.6 - seems like they should be together.

JR: Issue already raised.

A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input. (Level A)
Comment: Are there any implementations in drawing programs that currently exist that meet this?  We're concerned that this may be mandating the ideal situation whether it has been proven practical or not. I'm interested in how the drawing aspect of this was considered when applying the level for A.3.1.1 - does the existence of mousekeys count as valid assistive technology to affect whether this aspect of A.3.1.1 is essential or if there is a workaround? We have no issue with the bulk of this SC, but this aspect is a concern.

JR: New comment in this round (but issue was previously recognized)

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)
Comment: This needs to be more defined.  As written, it seems like an authoring tool needs minimal keyboard shortcuts, but we doubt that is what you mean.  If this can't be defined better then it should be removed.

JR: Issue already raised.

A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off. (Level A) 
Comment: We have difficulty reconciling the needs of authors to be able to view/approve/edit content and this SC which requires that the content be able to be disabled.  Given that this is at level A that concern is more pronounced.  Have you considered moving this to AA or AAA?

JR: Issue already raised.

A.3.4.1 Edit By Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. (Level A)
Comment: Please define what "that can make use of the structure" means more precisely.  

JR: Issue already raised.
 
Comment: This seems like it might be at too high a level, although since I'm not completely certain what it means I'm not sure.  Is this essential for authors?

JR: Issue already raised.

Comment: Which structures are you referring to?  In an HTML document does this include paragraphs, lists, tables, headings, and any other sementic structures, or just a subset that is needed?

JR: Issue already raised.


A.3.4.2
Comment: See A.3.4.1, comments are the same.

JR: Issue already raised.

A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. (Level AA)
Comment: This approach is very different from that of WCAG, which specifies display properties that need to be supported, such as text must be able to resize by 200%.  Given the ambiguity of "respect platform settings" and the variety of platforms that may be able to support a given authoring tool, please consider changing this to be in line with the WCAG model.

JR: New issue.

A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A)
Comment: in "b" you require conformance with UAAG as one of the options.  Which UAAG - 1 or 2? 

JR: New issue. Would need to be 1.0 at the current time.

Guideline A.3.7: [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents.
Comment: the implicit statement here is that there are user agents that conform to UAAG.  Are there?  It seems like there is a way to meet this be using an existing UA or meeting UAAG, but not by matching the accessibility of existing tools.

JR: Actually, that's not implicit. The intention is to have previews be accurate.

A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. (Level A)
Comment: is one level of undo sufficient?

JR: Issue already raised.

A.4.2.2 Document All Features: All features of the authoring tool are documented. (Level AA)
Comment: This is not a SC that impacts users with disabilities any more than users without disabilities.  As such, it doesn't belong in an accessibility standard. Please remove.

JR: Issue already raised.

B.1.2.2 (b) Warning: authors are warned that this will result in web content accessibility problems in the output.
Comment: This is inappropriately worded. Some formats may not make use of all of the accessibility information that may be present in another, yet if that format can still meet WCAG 2.0 it seems inappropriate to cite this as a flaw in the authoring tool.  Please remove "b".

JR: It's not a flaw in the authoring tool, it's just a warning that content - that may have taken resources to create is about to be lost.

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output. (Level AA)
Comment: Please modify "up to WCAG 2.0 Level AAA" to reflect the AA level of B.1.2.3

JR: Issue already raised.

Comment: Please add "when the output format is able to utilize that accessibility information" to the end of the SC (see comment on B.1.2.2(b) )

JR: New issue.

B.2.1.1 Decision Support: If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A)
Comment: Adobe will not make claims about 3rd party technologies, we doubt many vendors would.  This is unrealistic and needs to be removed.

JR: Issue already raised.

B.2.1.3 Other Technologies: If the authoring tool can insert web content that it cannot subsequently edit, then authors can associate accessibility information with that web content. (Level A)
Comment: this is fine to say for an image in HTML authoring tools, since the path to delivering access is defined and (at present) under the singular control of the HTML editor.  However, this is not the case for other content, such as video needing description (e.g. does every HTML editor also need to provide support for editing SMIL), or Flash or PDF content that needs to support accessibility.  Authors need to associate accessibility information in some cases, and authors need to utilize assets that are accessible in other cases, but we don't see provision for the latter here.

JR: Issue already raised.

B 2.2 Rationale
Comment: Given the definition of authoring tool, the use of the term "integrated" seems incorrect.

JR: New issue.

B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA)
Comment: Please provide information on why this is a AA SC.  Are there tools that use accessibility results metadata?

JR: Issue already raised.

B.2.4.2 Automated Suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)
Comment: As stated earlier, it is not clear what makes one SC level A and another AA or AAA.  This seems like it should be AA at least, given that B.2.4.1 is A.

JR: Issue already raised.

B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level A when used. (Level A)
Comment: This is a challenging SC since templates may provide rigid or loose structure for an author to work within.  I'm not sure how to word this so that the point is preserved, but it may be difficult to define a single direction that an author must take to use a template in an accessible way.  How about "Where templates can provide guidance for authors to comply with WCAG 2.0 Level A, authors are encouraged to take necessary steps"?  Hard to find the right language...

JR: New issue (related to other raised).

B.2.5.5 New Templates: 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. (Level AA)
Comment: feels like a AAA SC, but I'm not sure how the criteria for placement were applied.  Please advise.

JR: Issue already raised.

Conformance

Definition: "Any software, or collection of software components, that authors can use to create or modify web content for use by other people."
Comment: Definition of Authoring tool is confusing and will raise difficulties in making conformance claims. Will it be allowed to reference the availability of tools (possibility of tools?) that can work with the output of one tool in a chain?  Or will the conformance claim need to reference the additional tools?

JR: Issue already raised.

Conformance condition #1: Why must ATAG specify the location of the conformance claim?

JR: New issue. 

Conformance condition #2: See comment for #1 above.

JR: New issue.

Conformance condition #3: "The existence of a conformance claim does not imply that the W3C has reviewed the claim or assured its validity." Seems like the condition needs to be that this statement needs to be included in the claim.  Please revise.

JR: New issue.

Conformance condition #4: "Claimants may be anyone (e.g., authoring tool developers, journalists, other third parties)." This "condition" seems misplaced here - a claim needs to be made by someone to be a claim?  Not much of a condition.  Perhaps stating that claims can be made by anyone in the intro to the section?
Conformation condition #6: we recommend removing this condition since it isn't really a condition.  This recommendation can go with the intro.

JR: Issue already raised.

Comment: Required components of a claim: #5 Authoring Tool information.  Adobe is not going to be able to provide information about 3rd party tools in a claim due to liability concerns.  This section needs to indicate that providing information about one tool in an authoring chain is allowable.

JR: Issue already raised.

Definitions

Comment: Can the AUWG provide a listing of any defined terms that are shared by WCAG and ATAG and indicate whether there is any difference in the definitions?

JR: Issue already raised.

Cheers,
Jan

Received on Friday, 17 September 2010 02:00:30 UTC