Disposition of comments for the Accessibility Guidelines Working Group

Not all comments have been marked as replied to. The disposition of comments is not complete.

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

Commentor	Comment	Working Group decision	Commentor reply
LC-2985 Jason Kiss `<jason@accesscult.org>` on behalf of New Zealand Government (archived comment)	While it is true that non-unique ID value is a failure of SC 4.1.1, and may very well introduce a failure of SC 1.3.1 where that ID value is referenced by another element in order to establish a relationship, it's not clear why two elements that have identical ID values but that otherwise aren't referenced by additional elements or in any one-to-one relationship. Proposed Change: Under Failure Example 1, change "An id attribute value that is not unique" to something like "An id attribute value that is not unique and that is referenced by another element to establish a relationship." Under Procedure, change "1. Check for id and accesskey values which are not unique within the document." into two steps: "1. Check for id attribue values that are not unique within the document and that are referenced by other elements. 2. Check for accesskey values that are not unique within the document."	The failure in question was problematic in the ways you describe and redundant to other failures in others. As a result the WG decided to remove F17 entirely. Failures resulting from missing relationships between specific elements as a result of id attribute value issues are covered in other techniques.	yes
LC-2966 Jens O. Meiert `<jens@meiert.com>` (archived comment)	Following “HTML and Specifying Language” [1] and “Usefulness of language annotations” [2] I propose to review guidelines that mandate marking up changes in language for appropriateness (like H58 [3]). The primary arguments for this proposal are that 1) determining language is per definitionem not an accessibility problem, and that 2) requiring authors to mark up all changes in language is a costly and unrealistic requirement, and one that may be better and more efficiently done by software at that. My interest in pursuing a WCAG conversation has been killed; although a bit scattered you find materials clarifying and elaborating the proposal in [1] (also review the comments) and [2]. [1] http://meiert.com/en/blog/20140825/html-and-language/ [2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/thread.html#msg136 [3] http://www.w3.org/TR/WCAG20-TECHS/H58.html	The need to indicate changes in language is required by WCAG 2.0 and as this document is not changing we will record your comment in the team wiki as an area that we should review as part of a possible future revision. Responding to your numbered arguments: 1) When the language changes on a page the assistive technologies are expected to adjust accordingly by switching the speech synthesizer to pronounce the language with appropriate inflection. Most major assistive technologies for people who are unable to read the text directly provide support for this functionality. If a sighted user encounters text in a different language they are able to view the text and determine if they are able to read the language as they are able to view an accurate representation of the information and make that determination. A non-sighted user encountering text that is in a different language than the default language of the page where the language is not correctly indicated will hear information that will be difficult or impossible to identify even if the user understands the language. As a result of this degraded information that impacts users with certain types of disabilities and doesn't impact users without disabilities, the working group considers it an accessibility problem when changes in language are not identified. 2) Marking up all changes does take more time than not marking up changes, but WCAG does not necessarily require that authors do this work themselves. An author could choose to employ a tool or web-based service to identify and properly indicate the language, if such a tool was available to them. There may come a time where the machine identification of language is of sufficiently high quality and is integrated into browsers so assistive technologies can programmatically identify the language without the author doing anything. However, this is not the current state of the technology so authors cannot rely on machine identification of changes in language and will instead need to utilize techniques such as H58 which utilize the lang attribute. As a final note, it is important to understand that the sufficient techniques are not necessarily the only way to meet success criteria. As technology changes, a new technique may allow authors to meet a success criteria, but it is up to the author to determine whether a published technique or a non-published technique is effective in their particular situation.	tocheck
LC-2986 Wilco Fiers `<wilco@accessibility.nl>` (archived comment)	Step 2 of the test procedure in H95 only has the text "step_two." as it's value. That doesn't seem right. Also, this feedback form doesn't have H95 listed under the techniques.		yes