The success criterion needs to have simplified languages.  We cannot determine its meaning without reading through the implementation guide.

Rewrite the success criterion to make it more comprehensible.

“Additional information” is undefined.  In order to determine what is considered additional information, one must know what is considered baseline information. We realize that AUWG considers underlining of misspelled words to be a piece of “additional information”, but there is no way to tell what is it that makes such information qualified as being “additional”.  This will make it impossible to determine if the criterion is met..  We can at best project the concept into the similar scenarios for grammatical errors and coding errors—purely because it is an educated guess.

Define “additional information” to make it objectively testable or revise the success criterion.

JR: Perhaps:
If an editing-view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined.
(Suggestion is not a substantive change)

This criterion should be consolidated to A.3.6.

Move A.2.3.1 to A.3.6

There should be exception and consideration for authoring environment/OS where there is no keyboard.

Either add a condition for environment/OS with keyboard or add an exception.

Why does the language differ from WCAG “except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints”

Either reconcile the difference or provide rationale for the difference.

Why does the language differ from WCAG “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away."

Either reconcile the difference or provide rationale for the difference.

Does a web-based authoring tool need to add short cut keys?  That seems rather unnecessary and arbitrary.  The value of short cut key is contextual.  This proposal is too sweeping.

Remove this success criterion.

Does it meet the success criterion if only two shortcuts are provided since there is no specification?  In that case, it would be hard to find any product that would fail this success criterion (file save and quit application are almost always supported)—making this criterion meaningless.

Remove this success criterion.

It should be recognized that there is a fundamental conflict between the necessity to view the animation during animation editing process and the need to disable animation to prevent seizure.  This cannot be at level A in its current form.
Is this applicable to non-visual time based content too?  If so, what is the rationale?

Move the SC to AA or AAA, explain that there is a potential for fundamental alteration, and to exclude all non-visual time-based content.

JR: Agree that it needs to visual-only. The requirement is not meant to rule out animated interfaces. A stop button is sufficient. Perhaps it would be more clear to say that animations shouldn't start to render auomatically (e.g., on loading them and then once the user starts the animation, they should be able to stop it).
(Suggestion is a substantive change)

Given that the purpose of these success criteria is to “…simplify the task…”, they should not be level A.  These are AA or AAA criteria.

Move all A.3.4 SCs to AA or AAA.

Most web-based authoring tools (think of social networking sites and blog sites) do not allow users to create or control structures.  There should be exemptions for authoring tools that do not allow structural edits. 

Add exemption for tools that does not allow control of structure or condition for tools that allow so.

Does this apply to all structures or some structures?  There is no indication one way or the other.  All structure does not make sense.

Clarify that this is not required for all structure.

What does “make use of” means?

Please provide definition.

In many cases, this is carried out by the browser or the OS instead of the authoring tool.  Does that mean the browsers and OS would be required as part of the conformance?

Please explain how reliance on browser and OS are to be handled.

There is some inconsistency here from A.3.1.4 where customization is set at AAA, but saving such setting is AA.

Please consider moving this SC to AAA to maintain consistency.

Change “…are saved…” to “…can be saved…”.  The current wording implies that the tool will do so without user control.

Please change wording as suggested.

Please define “respects” or use more precise language.

Please define “respects” or use more precise language.

This criterion is redundant to A.3.1.2.

Please remove the criterion.

JR: Agreed. Perhaps with a note in A.3.1.2 mentionning preview.
(Suggestion is not a substantive change - since the normative requirement stays the same)

Please remove the term “third-party” from option A.  It is not appropriate.  This is saying that Microsoft cannot use IE; Google cannot use Chrome; and Apple cannot use Safari.

Please remove the term “third-party” completely.

How many layers of undo are needed to meet the criterion?  Since it is unspecified, we assume one is adequate.

Please specify if more than one layer of undo is needed to satisfy the SC.

“Undo” is normally not feasible for many scenarios for basic web form authoring tool or it depends on the browser to carry out the undo.  In reality, most actions are reversible without having the “undo” function.  If action is reversible, then why impose the specific function of “undo”?

Change the SC to read: “Authoring actions are reversible or include warning to authors that the action is irreversible.”

This SC requires a warning every time the user execute a file save or the like.  This runs against user expectations and will become a serious annoyance.

Please add exception for the like of file save from having to give warning.

It is hard to see what an author can do with the tool that is not considered authoring action.  Please provide examples of non-authoring actions.

Please provide examples of what is not considered authoring action and tighten the definition as necessary.

What is the definition of “committing action”?

Please add definition

JR: We mention save and publish. Of course certian systems like Wikis keep previous content past "committing actions". Perhaps we just say "Save".
(Suggestion is not a substantive change)

“All features” is too encompassing.  Hidden features are common place.  Besides, how is non-documented features affecting people with disabilities any more than those without disabilities.  This SC is not at all related to accessibility.

Please remove A.4.2.2

The examples seem contradictory because both examples pertains to automated content, yet they are treated differently.

Please revise the example to reconcile the contradiction.

Condition b is absolutely not possible if the output is a third party format.  This SC essentially asks authoring tool makers to judge and make claim to users which format is less accessible.  It would require constant update to keep such info up-to-date and the potential liability of claiming one format is less accessible than another is not something that any manufacturer can accept, especially when it comes to 3rd party format.

Please remove condition b.

We suspect there is an error here where the accessibility information should be up to WCAG 2.0 Level AA, not AAA.  There should also be a similar SC for AAA.

Please change the SC language from “…WCAG 2.0 Level AAA…” to “…WCAG 2.0 Level AA…”
Add a new SC to cover AAA.

How does this apply to something like a copy and paste operation from a rich text editor to a plain text editor where structural info will be lost?  Who is supposed to tell the author that the structure is gone?

Please explain how the SC applies to copy-and-paste or cut-and-paste operations?

Please identify a real life product with option c.  This seems like a theoretical option.

Please provide real life example for option c.

“…prior to publishing.” Invalidates the SC.  If a tool generates content in real time, there is no content to meet WCAG 2.0 prior to publishing.  The concept has no meaning.

Please remove “prior to publishing.” In B.1.3.1, B.1.3.2, and B.1.3.3.

No commercial product, or even most non-commercial one, would take on the liability of claiming accessibility on behalf of a 3rd party technology.  This is SC is absolutely not implementable.

Please remove B.2.1.1

What happens if there some properties are set via context menu, some are set on the ribbon, and some are set in a separate dialogue?  This SC implies the accessibility-related properties need to be in all of them.  We believe there is an unstated assumption that all the mechanisms are interchangeable.  That is not a valid assumption.

Please revise B.2.1.2

“Accessibility-related properties” is undefined.

Please define.

If the authoring tool cannot edit, then should the burden of making the association be placed on that tool?  We can only see very specific situation where this makes sense (time text file upload or adding alt text).  Also, what if the content is read-only due to protection?  The proposed text is too sweeping.

Insert condition of “if the content supports association of accessibility info.”

“Appropriate” is not testable.

Revise SC B.2.2.2

What happens when there is no defined workflow?

Revise SC B.2.2.2

The concept of “prior to publishing” is not applicable to real time info.  How is checking done on an online banking scenario?

Revise SC B.2.2.2

This is an AA level SC because B.2.2.1 already provides adequate guidance at A level.

Move to AA.

AUWG needs to specify which WCAG 2.0 SCs require author judgment.

Add a normative note of which SCs in WCAG 2.0 require author judgment.

This SC is AA or AAA.  How is a tool supposed to help locate relevant content to meet WCAG 2.0 3.3.2 or 1.3.3, for example?  This SC demands far too much intelligence from the tool to be level A.

Move SC to AA or AAA.

This SC belongs to AAA.

Move SC to AAA.

Is this meant for audio description as well?  If not, then the proposed language is too sweeping.

Please clarify and tighten the language as necessary..

This is not a Level A SC.  Providing instruction is A.  Providing automate suggestion should be AA.

Please move SC to AA

“Relevant sources” need testable definition.

Please add definition.

This SC seems extraneous.  If text alternative can be accessed, then obviously it can be reused.  If nothing, at least delete “for future reuse.” since it represents future event which is unverifiable at the time of conformance claim.

Consider deleting the SC or at least delete “for future use.”

How can “…used properly” ever be testable? The note is a necessary component of the SC since most templates cannot meet WCAG 2.0 in their initial state.  But adding the note makes the SC not testable.

If all templates are equally accessible, why would this be necessary or beneficial? There seems to be an assumption here that the templates are not all of similar accessibility status.

Revise the SC

Please provide examples of how one goes about indicating the accessibility status of a template.  How much detail is needed?

Please provide instruction of the level of detail required to indicate template accessibility status.

What happens when there is a large variety of template of all different sorts?  The language suggests that the “accessible” option must take precedence regardless of other logical grouping.

Please change the SC to account for other logical grouping of templates.

The term “…accessible template options” implies that there is a distinction of “accessible template” and “non-accessible” template.  How does one go about making such distinction?  Without an exact definition, this SC is not testable.

Please provide a structured way to indicate accessibility status of templates and how to go about showing prominence of template of various (or equal) status.

If AUWG expects users to specify accessibility status of their template, then far more guidance must be given.  AUWG cannot possibly expect any author to know what they are doing here.  Without guidance and control, this will only results in incorrect accessibility status being posted.

Detail guidelines must be given here.  Please do not expect average users to be able to provide accurate accessibility status of their template.  Understand what this would mean over time.

This SC assumes that author is given freedom to create templates with different degree of accessibility.  The assumption is not always valid.

Please address the scenario in which author has no freedom to change accessibility of a template.

All comments from 2.5.4 apply equally.

Please reference comments from B.2.5.4

Most comments from 2.5.4 apply here.

Please reference comments from B.2.5.4

The SC assumes that there is some feature to be “turned on” which is an invalid assumption.

Please add condition of “If there is a changeable on/off status for such features.”

Does the term “always” add anything to the criteria? It can be a loaded word to imply that one must be able to turn the feature from any dialogue.  Obviously, that’s not possible.

Please remove the term “always” form the SC.

“Comparable” is not testable.

Please revise SC.

“Other types of web content problems” has no definition and, thus, there is no way to determine if the SC is met.

Please replace “other types of web content problems” with something more precise.

What counts as a range?  Two or more?

Please remove “A range of” from the SC

The biggest concern for ATAG 2.0 is that it is never clear if ATAG is for a single tool or a collection of tools.  It is trying to be both.  This leads to a great deal of structural problems.

If it is for a single tool, then the SCs are too far reaching and the conformance requirement does not make room for a simple specialized tool to conform.  How does ATAG 2.0 conformance work for something like a web accessibility toolbar, photo editor, FTP client, or a social networking site?  You need to allow tool makers to say their tool does not provide certain function and it is not intended to do so, but the tool conforms where it is applicable.

On the other hand, how would conformance work for a collection of tools where some criteria are met via a portion of the tools?  Would one have to specify which tool(s) is used to conform to any given criterion?  If the collection of tools include tool(s) in which the conformance claimer has no Intellectual property ownership, would the claimer then be held responsible for the accuracy of the claim of such tool?  What if is there is discrepancy between the tool manufacturer and claimers? What if the collection is still not applicable to ATAG in full—for example, only relevant to part A?  Is the collection deemed incomplete? 

Additionally, where does the value chain of the authoring process end?  Without knowing the scope, then ATAG 2.0 may require consideration of software such as scanner application, a database, a web service, or enterprise backend systems.  Does a mail client become a “web authoring tool” only when it sends a message to somebody who access their email via the web?  How is one supposed to know if the mail recipient uses a web client?

These are extremely difficult questions.  But if left unanswered, ATAG 2.0 will not be viable in practice.

The conformance section requires fundamental revision to be viable.  Please revise accordingly.

WCAG 2.0 does not require conformance claim be made in the web or not.  This condition is unnecessary.

Please remove condition.

This is an “encouragement”.  Thus, it does not belong to the normative part of the ATAG 2.0.

Please move condition 6 to non-normative part of ATAG 2.0.