Current WCAG 2.0 Guidelines	Suggested Changes	Justification	WCAG RESPONSE
Principle 1: Perceivable - Information and user interface components must be perceivable by users	Principle 1: Perceivable - Information and user interface components must be perceivable	"by users" is unnecessary	This language has changed based on other commenter's. The current wording is: "Perceivable - Information and user interface components must be presentable to users in ways they can perceive." We DID remove "by users" from the other principles as you suggested.
Guideline 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language	Guideline 1.1 Provide text alternatives for all non-text content.	"so that it can be" does not belong in the guideline. If it is deemed a necessary explanation, consider putting into supporting ("Understanding" or "How to Meet") documents	This was added to make the guidelines easier to understand. This and a couple other places were expanded where the guidelines' intent was important for conforming and not clear from short version.
1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below.	1.1.1 Non-text Content: Non-text content has an equivalent text alternative. Exceptions are listed below.	Plainer language - elimination of "all" since there are exceptions immediately listed.	We are keeping this as one sentence because the two sentence version has sentence 2 contradicting sentence 1. "text alternative that includes equivalent information" is part of our attempt to not require a definition if we can put the definition in the provision. if we use "equivalent text alternative" then we end up having to define it. Since it is one sentence, and has the exception in it, it can still say "all" and be accurate.
Note: For 1.2.2, 1.2.4, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary.	No change suggested - although this note seems unnecessary		We put this in to answer a common misunderstanding or ambiguity that often arises.
Guideline 1.3 Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure	Guideline 1.3 Create content that does not lose information or structure when presented in different ways.	Please consider moving parenthetical comment to supporting documentation ("Understanding" or "How to Meet") rather than cluttering the guideline.	See comment above regarding understandability. This one also was interpreted narrowly without the provision - which could cause misapplication. Original wording seems more active than proposed wording. Also the new wording suggests that the author do this - which is hard for them to do.
1.3.1 Info and Relationships: Information and relationships conveyed through presentation can be programmatically determined or are available in text , and notification of changes to these is available to user agents, including assistive technologies.	1.3.1 Info and Relationships: Informational relationships conveyed through presentation can be programmatically determined or are available in text.	Confusing... if the intent is to require that AJAX and other dynamic presentation be made available to AT, please consider another separate checkpoint.	Thank you. We agree. We have simplified 1.3.1 as you suggest but have moved the dynamic part down to 4.1.2 where all the other dynamic / programmatic information aspects are handled"
	1.3.1a Dynamic Content: When user interaction changes the content of a webpage, changes are programmatically determined and communicated to assistive technologies	see above
Guideline 1.4 Make it easier for people with disabilities to see and hear content including separating foreground from background	Guideline 1.4 Separate foreground from background on all visual and aural content.	"Make it easier for people" is redundant. After all, isn't that what all of the Guidelines are meant to do? Also how can we measure "make it easier" without survey data?	The new guideline does not cover all of the success criteria and techniques (sufficient and advisory) that are under this guideline. Text sizing for example is not a background issue.
1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1.	1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 5:1, unless text is merely decorative. Larger-scale text or images of text can have a contrast ratio of 3:1.	Plain language - replaced "except if the text is pure decoration" with "unless text is merely decorative"	We have reworded this provision to make it clearer. The current wording is now: [INSERT FINAL LANGUAGE WHEN DONE HARMONIZING WITH TEITAC].
1.4.5 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 5:1.	1.4.5 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1 unless text is merely decorative. Larger-scale text or images of text can have a contrast ratio of 5:1.	Plain language - replaced "except if the text is pure decoration" with "unless text is merely decorative"	While your suggested wording reads better, often text can both be decorative and convey information. This raised ambiguity questions and over-application of the exception. Hence the "pure decoration" language.
Principle 2: Operable - User interface components must be operable by users.	Principle 2: Operable - User interface components must be operable.	"by users" is unecessary	Done
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.	2.1.1 Keyboard: Content function and interaction is operable through a keyboard interface without requiring specific timings for individual keystrokes. Exceptions are noted below. Without exception (Level AAA) With exception (Level A)	If the exception is removed to the Notes, then 2.1.2 can be eliminated and the note can designate the different conformance levels	We don't have any mechanism for assigning levels to notes. Also a note can only explain an SC, they cannot modify it which is what an exception would do.
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.	Note 1: Keyboard access is not required when the underlying function requires input that depends on the path of the user's movement and not just the endpoints.	see above	see above
	Note 2: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.	see above	see above
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.	Note 3: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.	see above, if note is added, this becomes Note 3	see above
2.1.2 Keyboard (No Exception): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.	Eliminate if change is made to 2.1.1	One less Guideline if 2.1.1 and 2.1.2 are combined	see above
Guideline 2.4 Provide ways to help users with disabilities navigate, find content and determine where they are.	Guideline 2.4 Provide consistant methods to navigate, find content and determine location within website and within each webpage.	"help users with disabilities" is condescending. Rather the emphasis should be on clarity of organizational structure	The proposed language is narrower than current language. We feel the existing language does a better job of covering the SC and describing the overall goal.
2.4.3 Focus Order: If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation.	Focus Order: The sequence with which components of a Web page receive focus is consistent with the information and relationships conveyed through presentation.	The condiditon of "If a web page can be" is irrelevant.	There are web pages that are web-like and there is no linear order for presentation. Therefore there needs to be an If to create an exception for that.
Editorial Note: There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.	No change suggested - although it would be quite useful if this debate could be concluded and result in a recommendation		Agree. And it certainly will be resolved by the time this goes to recommendation. Hopefully before.
Principle 3: Understandable - Information and operation of user interface must be understandable by users	Principle 3: Understandable - Information and operation of user interface must be understandable	"by users" is unecessary	Done
Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies	Principle 4: Robust - Content can be interpreted reliably by a wide variety of user agents, including assistive technologies	repetitive use of "robust" is uneccessary	The first Robust is the short name. All the principles repeat the short name.
4.1.1 Parsing: Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.	Unable to suggest as I am not sure I know what is intended.	I am confused as to the intent here. The need to highlight one validation criterion over others is not clear.	{partial/other} The Understanding WCAG 2.0 explains that this is the aspect reported by AT to cause problems with AT which do not have the extensive repair techniques of regular user agents.
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.	Delete or clarify this note	Too tied to existing technology. Please consider how this might be brought out to a non-normative note.	Unfortunately, non-normative notes have no enforcement or exception capability. This was included to clarify a point that was otherwise found to be ambiguous. This applies to any technology that includes markup.
4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically determined and programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.	4.1.2 Name, Role, Value: The name and role of interface components can be programmatically determined; states, properties, and values that can be set by the user can be programmatically determined and programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.	Language should be consistent: Changed "For all interface components" to "The name and role of interface components" for consistency with following clauses	The phrase "for all user interface components" is a lead phrase that should be applied to all of the subordinate clauses. We will check with a grammarian during final edit to be sure we have the right punctuation to achieve this. { Change comma to a semicolon? }
Note: This success criterion is primarily for Web authors who develop or script their own user interface controls. For example, standard HTML controls already meet this provision when used according to specification.	Delete or generalize note	Unecessary and violates "technology neutral" stance. It may currently apply primarily to those who write their own scripts, but it is unknown what it may apply to in future. Please consider how/if this might be brought out to a non-normative note.	We believe your concern is not with the note but with the example. The example is technology specific as examples generally are. This is a special note that was added because the provision would not be understandable by simple web page designers who did not program or re-program their own interface components. This note was included to indicate that this very complex provision does not need to be understood if you are using standard markup technologies like HTML