List of comments on “Techniques for WCAG 2.0” (dated 6 March 2014)

There are 20 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2957: Remove layout table section from H39 and H73: Commenter:; Context: H39: Using caption elements to associate data table captions with data tables; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/37

H39 and H73 don't need to mention layout table cases because F46 describes common failure cases of layout tables.

H39: Using caption elements to associate data table captions with data tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H39.html

H73: Using the summary attribute of the table element to give an overview of data tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H73.html

F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F46.html

In this pull request,

Changed layout table sentence in description to a note
Added F46 to related techniques
Tweaked related techniques in H39 to align with H73 and F46
Removed layout table check procedures in tests; Related issues: (space separated ids); WG Notes:; Resolution: You have pointed out some helpful changes to make the technique easier to understand. We are accepting the pull request, but will then make some modifications: In H39 1) Modify sentence in the description from " If both are used, the caption should not duplicate information in the summary." to " If both are used, the summary should not duplicate information in the caption." 2) Modify the procedure to: two items, "Check that the table includes a caption element" and "Check that the content of the caption element identifies the table". We will remove the summary check as that represents a different issue and doesn't interfere with this technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2912: ARIA19 issue: Commenter: Alistair Hastings <alistairhastings@yahoo.com> (archived message); Context: ARIA19: Using ARIA role=alert or Live Regions to Identify Errors; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Example 1 in ARIA 19 does not work with the latest version of JAWS and IE9/10/11. Is this a known issue, or is a there a more current technique for making dynamic DOM elements accessible?; Related issues: (space separated ids); WG Notes: @@ add note in ARIA19 user agent notes that reads: Internet Explorer 7/8/9/10/11 do not support notifications as described in this technique when using role="alert". However, using aria-live="assertive" as described in example 1 does function correctly.; Resolution: Thank you for your comment. Internet Explorer currently has incomplete support for ARIA roles, including the alert role. We will provide a note in the user agent notes for this technique that specifically addresses this limitation in IE.; (Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2952: Remove SCR2: Commenter:; Context: SCR2: Using redundant keyboard and mouse event handlers; Status:
assigned to David MacDonald; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/42

... as SCR2 is redundant.

SCR20 provides more generalized and comprehensive information. We should remove SCR2.

SCR2: Using redundant keyboard and mouse event handlers
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SCR2.html

SCR20: Using both keyboard and other device-specific functions
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SCR20.html; Related issues: (space separated ids); WG Notes: Tim - SCR2 contains some detailed information which may be useful as additional clarifying text to SC20. Example 1 of SCR20 seems to "cover" SCR2 at least in part. There are nuances in the SCR2 language that should be kept. Maybe combine SCR2 and SCR20 (add the bits of SCR2 not specifically covered in SCR20 to SCR20)? METAQUESTION: What granularity of technique is most useful? SCR2 is more granular, but this may be more helpful to individuals than a more general technique like SCR20..; Resolution: The WG agrees to that SCR2 is redundant with SCR20. There is some discussion in SCR2 which is not in SCR20 and the code example is more detailed, but after careful consideration of the Description of SCR2, its Code Example, and Test, we feel we can safely delete SCR2 without migrating any of it over to SCR20. Information in SCR2 that is not included in SCR20 goes beyond the purpose of a technique. SCR2 is as much a tutorial for how to create mouse hovers as it is a device independence technique. We feel that SCR20 covers the same information more concisely, and assumes correctly that developers looking for SCR techniques will know JavaScript basics, and if not, they can find those types of tutorials elsewhere. For these reasons we agree to delete SCR2 without making any further amendments to SCR20.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2960: ARIA2 Remove "when there is a visual cue to this effect." from objective.: Commenter:; Context: ARIA2: Identifying a required field with the aria-required property; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/34

The application of ARIA2 should not be limited whether "there is a visual cue to this effect." Because there could be audio or other sensory cues if authors use CSS or JavaScript. Also, the "Tests" procedures don't check whether "there is a visual cue to this effect."

We should remove "there is a visual cue to this effect." from the objective.
takenspc ARIA2 Remove "when there is a visual cue to this effect." from object…; Related issues: (space separated ids); WG Notes: https://github.com/w3c/wcag/pull/65/files?diff=split; Resolution: The intent of SC 1.3.1 is that relationships which are presented as required are also indicated programmatically. As a result the use of aria-required to align the programmatic information with the presentational information is what makes this technique applicable to SC 1.3.1. We have adjusted the technique to refer to presentation rather than visual information, and adjusted the test procedure accordingly.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2959: Remove "WAI-ARIA is a Working Draft" from ARIA2: Commenter:; Context: ARIA2: Identifying a required field with the aria-required property; Status:
assigned to Loretta Guarino Reid; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/35

Because WAI-ARIA 1.0 is a Recommendation.
http://www.w3.org/TR/2014/REC-wai-aria-20140320/
takenspc Remove WAI-ARIA is a Working Draft from Notes; Related issues: (space separated ids); WG Notes:; Resolution: We have accepted this as suggested.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2958: Remove ARIA4 and ARIAe: Commenter:; Context: ARIA4: Using a WAI-ARIA role to expose the role of a user interface component; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/36

We should remove ARIA4 and ARIA5 because they are

too ambiguous for both authors and auditors
technically incorrect
Too ambiguous

Both techniques don't provide helpful information for authors and auditors considering that WAI-ARIA Rec. contains limited examples. We should provide more specific techniques like design patterns of WAi-ARIA Authoring Practices.

http://www.w3.org/TR/wai-aria/
http://www.w3.org/WAI/PF/aria-practices/

Technical correctness

For ARIA 4, people who use assistive technologies may unable to operate user interface components when

states and properties are not correctly exposed
focus is not correctly managed (ex. "application" role in a page which doesn't contain JavaScript)
For ARIA 5, people who use assistive technologies may unable to operate user interface components when

roles are not correctly exposed
focus is not correctly managed (ex. "aria-activedecendant" in a page which doesn't contain JavaScript)
We could add failure example like "incorrect roles are exposed" or "incorrect states or properties are exposed" but I don't think they are necessary.; Related issues: (space separated ids); WG Notes:; Resolution: The issues that you cite on ARIA4 and ARIA5 are unclear. For example, ARIA4 doesn't mention the application role and ARIA5 doesn't use activedescendant. As the point of the techniques is to demonstrate use of the ARIA role attribute and ARIA state and property attributes respectively, it is unclear how these techniques are technically incorrect. The live examples are more fully formed, but the excerpts in the technique itself are trimmed down by design. We do agree that additional examples are needed and welcome any suggestions for additional or improved examples.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2961: Remove example 1 from ARIA7: Commenter:; Context: ARIA7: Using aria-labelledby for link purpose; Status:
assigned to Jonathan Avila; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/33

Changing accessible name from rendered/visible text generally causes accessibility issues. Especially, changing accessible name completely different one from rendered/visible text causes serious accessibility issues.

ARIA 1.0 Recommendation provides some examples of similar issues. In a note of |aria-hidden|
http://www.w3.org/TR/2014/REC-wai-aria-20140320/states_and_properties#aria-hidden

Note: Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control. Similar problems may also arise for screen reader users. For example, a sighted telephone support technician may attempt to have the blind screen reader user click the "Go to checkout" link, which they may be unable to find using a type-ahead item search ("Go to…").
As Example 1 of ARIA7 changes accessible name from "Read more..." to "Storms hit east coast", people who use voice control or who are blind and communicating with sighted person may face issues.

Thus we should get rid of Example 1 of ARIA7.
takenspc ARIA7 Remove Example 1; Related issues: (space separated ids); WG Notes: I see three options: Option 1: Remove example 1. Example 2 is a better example because it includes both the link text and additional on-screen text. Option 2: Keep example 1 and provide example of where a replacement for link text would be a good idea. Perhaps an example where the link was a symbol such as ">>" or ">" but where on-screen text exists. I can't think of a good example where there would be on-screen but you wouldn't want to include it in the link text. Even for a footnote or search result page number example, you'd want to include the footnote or page number in the accessible name. Proposed decision: Remove Example 1.; Resolution: Thank you for your comment. The working group has reviewed the comment and agrees that the example could cause accessibility issues for some users with disabilities and should be removed from this technique. The group also agreed to update example 1 as follows by adding a redundant referenence to the "Read more text". Example 1: Providing additional information for links This example will mean that the link text as shown on screen is then used as the start of the accessible name for the link. Popular screen readers like JAWS and NVDA will announce this as: "Read more ...Storms hit east coast" and will display that same text in the links list which is very useful for screen reader users who may browse by links. <h2 id="headline">Storms hit east coast</h2> <p>Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns. <a id="p123" href="news.html" aria-labelledby="p123 headline">Read more...</a></p> NOTE: Technique ARIA 8 addresses the use of aria-label when link text may not be available and thus also provides a solution for that particular scenario. We hope this addresses your concerns.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2950: Clarify uniqueness of F17: Commenter:; Context: F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient info...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/45

Currently uniqueness or necessity of F17 is unclear. F17 discusses

uniqueness of id attribute
correctness of referencing id or unique identifies (for, headers, usemap attributes)
uniqueness of accesskey attribute
However F77 and F62 discusses most of them.

F77 discusses uniqueness of id
F62 discusses correctness of referencing id or unique identifiers
F68 discusses that in for attribute
F90 discusses that in headers attribute
Remaining issue is uniqueness of accesskey attribute. So we should remove other issuse from F17.

F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML
F62: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine specific relationships in XML
F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association of label and user interface controls not being programmatically determined
F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID
F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content via the headers and id attributes; Related issues: (space separated ids); WG Notes: David MacDonald says: This is a fair comment. I don't even think that access key uniqueness is critical because most browsers just cycle through identical accesskeys. I need to test this. If so, we can remove the failure. If not, we can re-title it for accesskey. On the other hand: F62 applies to XML not html or xhtml This not covered elsewhere For client-side image maps, check that the value of the usemap attribute is a URI that references a valid name or id. http://davidmacd.com/test/more-than-one-accesskey.html is my testing of accesskey. It appears the expected behaviour is to allow more than one of the same accesskey, although this is poorly supported. On the HTML5 next discussion the accesskey issue came up. I think we shpuld wait for that.; Resolution: We agree that F17 is redundant to other failures, primarily F77. As part of this investigation, we determined that the accesskey information provided in F17 is inaccurate, so we are removing F17 entirely. In addition, we determined that F62 is also partially redundant and also contains some inaccurate information, so we are removing that failure as well. The accurate information contained in F17 and F62 is contained within the remaining failures, particularly F68, F90, and F77.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2955: Clarify the diffrence between F40 and F41: Commenter:; Context: F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redire...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/39

F41 discusses the reloading the page and F40 discusses the redirecting the page. Currently, however , the difference between the two common failures are not clear. We should clarify the difference.

F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redirect with a time limit
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F40.html

F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh with a time-out
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F41.html

In this pull request,

Changed summary of F41 to make its objective clear
Reloading without user permissions is an issue regardless of refresh interval
Removed Example 2 of F41 because it's an example of F40
Removed SVR1 from related techniques of F41 because SVR1 discusses redirecting not reloading
Added SVR1 and H76 to F40 as related techniques (now authors can fix their issues)
Changed tests in F40
Make the test fails in case content="0"
Reloading without user permissions is an issue regardless of refresh interval
Make the test not fail in case content attribute contains "; url="
It's a failure of F40
(bonus) Added lang attribute to html element
H76: Using meta refresh to create an instant client-side redirect
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H76.html

SVR1: Implementing automatic redirects on the server side instead of on the client side
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/SVR1.html; Related issues: (space separated ids); WG Notes: changes to F40 are appropriate Are all meta-refreshes failures? if so then I agree with all of the changes. If not then the title change is in need of modification but all else is fine. IE does support disabling meta-refresh; Resolution: The changes that you suggest are helpful and we will accept the pull request.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2951: Remove F42: Commenter:; Context: F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting e...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/43

F42 discusses two issues; keyboard support and semantics. F54 and F59 discuss each issue. Thus F42 is redundant and we should get rid of it.

F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting events to emulate links in a way that is not programmatically determinable
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F42.html

F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F54.html

F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F59.html

Keyboard Support

In F42,

A control or link created in this manner cannot be tabbed to from the keyboard and does not gain keyboard focus like other controls and/or links.
This is discussed in F54.

When pointing device-specific event handlers are the only mechanism available to invoke a function of the content, users with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as users who must use alternate keyboards or input devices that act as keyboard emulators will be unable to access the function of the content.
Semantics

In F42,

If scripting events are used to emulate links, user agents including assistive technology may not be able to identify the links in the content as links.
This is discussed in F59.

Many HTML elements have well defined roles, such as links, buttons, text fields, etc. Generic elements such as div and span do not have any predefined roles. When these generic elements are used to create user interface controls in HTML the assistive technology may not have the necessary information to describe and interact with the control.; Related issues: (space separated ids); WG Notes: F42 is a specific example of failure due to lack of keyboard support and no role defined on a link. The examples are good and the failure is clear. However, we could add a note about ARIA use into this failure in the description part where it says "The <a href> and <area> elements are intended to mark up links.". The comment states that F42 is redundant and F54 & F59 cover the two issues. This is correct but F42 has more specific information. I recommend that we keep F42. But if we were to remove it, the examples and information should be added to F54 and F59.; Resolution: F42 is a specific example of failure due to lack of keyboard support and no role defined on a link. F59 is a failure that is more focused in that it is only addressing SC 4.1.2, but is also more encompassing in that it is not constrained to link control types. We decided to keep F42 because it represents a very common scenario and feel that there is value in calling this specific failure out. We have modified F42 to make it more clear that this failure is focused only on links, and also included new information about using ARIA with emulated links.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2956: Remove F48: Commenter:; Context: F48: Failure of Success Criterion 1.3.1 due to using the pre element to ma...; Status:
assigned to Loretta Guarino Reid; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/38

Remove F48,

it's same as F34
considering CSS white-space property, it can be said that any HTML elements may have white-space formatted information
F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F34.html

F48: Failure of Success Criterion 1.3.1 due to using the pre element to markup tabular information
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F48.html; Related issues: (space separated ids); WG Notes:; Resolution: Although these two failures are very similar, whitespace formatting of tables in HTML tends to be rare unless the <pre> element is used. We think it is helpful to highlight this particular HTML practice separately from the general failure of using white space characters in plain text content. As a result, we decline to remove the technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2953: F55: Remove Example 3 as it's same as Example 2: Commenter:; Context: F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using scri...; Status:
assigned to Loretta Guarino Reid; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/41

Remove Example 3 as it's same as Example 2.

F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F55.html; Related issues: (space separated ids); WG Notes:; Resolution: These examples are very similar but they illustrate a slight variation as as a result the working group would like to keep both.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2954: Clarify F68 is applicable for controls that use visible labels: Commenter:; Context: F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association o...; Status:
assigned to Adam Solomon; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/40

F68 is applicable for controls that use visible labels.

Applicability

HTML and XHTML controls that use visible labels
F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association of label and user interface controls not being programmatically determined
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/F68.html

Thus we should remove unrelated example, related techniques and check conditions.

Example 3 is the same example of H65 which is a technique for controls that cannot use visible labels. So this pull request removed Example 3.

H65: Using the title attribute to identify form controls when the label element cannot be used
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140724/H65.html

The aria-label and title are techniques for controls that cannot use visible labels. Thus this pull request removed related techniques and check conditions. As the aria-labelledby can be used for controls that use visible labels such as controls in the data table, this pull request doesn't modify that.

Additional changes are

Updated first sentence of test procedures to match notes of description (applicable input type is not limited to radio, checkbox, text, file or password)
Replaced "input element" to "control element" in test procedure to match "For all input elements ... and all textarea and select elements"
Make sure that ids in aria-labelledby are ids of the text label element instead of the control control; Related issues: (space separated ids); WG Notes: seemingly (not sure) 1.3.1 does in fact only apply to visible labels and commenter is correct that use of title or aria-label would not suffice, as opposed to 4.1.2 where they would suffice. Maybe that's why aria-label technique doesn't appear in the sufficient techniques for 1.3.1 We should then have separate failures for 4.1.2 and 1.3.1, the current failure being slightly rewritten for 4.1.2 and a new failure excluding use of title and aria-label for 1.3.1; Resolution: Thank you for your comment. As F68 does in fact apply to criterion 1.3.1 which would apply only to situations where a visible label is present, example 3 should be removed. Also, the presence of title and aria-label should not appear in the test procedure, and the specific mention of input in the test procedure should be amended as per your request. The test procedure would then read: 'For all control elements (input elements of type "radio", "checkbox", "text", "file" or "password", and all textarea and select elements) in the Web page: Check that the visual design uses a text label that identifies the purpose of the control Check that the control element has a programmatically determined label associated in one of the following ways: the text label is contained in a label element that is correctly associated to the respective control element via the label's for attribute (the id given as value in the for attribute matches the id of the input element). the control is contained within a label element that contains the text label. the text label is correctly programmatically associated with the control element via the aria-labelledby attribute (the id given as value in the aria-labelledby attribute matches the id of the element containing the text label)." Furthermore, we may add an additional failure which would apply only to 4.1.2, and would include "title" and "aria-label" in the test procedure, since they are sufficient for 4.1.2; (Please make sure the resolution is adapted for public consumption)

Comment LC-2963: F89 confusing: Commenter:; Context: F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to using null ...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
F89 is confusing. The title and procedure are not well-matched.; Related issues: (space separated ids); WG Notes: http://www.w3.org/TR/WCAG20-TECHS/F89.html https://github.com/w3c/wcag/issues/47; Resolution: Thank you for the comment. We agree that the procedure and title should match and are changing the title to the following: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2939: use of H37 listed under Situations A and B remains unclear: Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message); Context: H37: Using alt attributes on img elements; Status:
assigned to Loretta Guarino Reid; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I have a question regarding some situations listed under "Sufficient
Techniques for 1.1.1 - Non-text Content" --
http://www.w3.org/WAI/WCAG20/quickref/#text-equiv, namely, Situation A: If
a short description can serve (supported by G94 etc.)... and Situation B:
If a short description cannot serve (supported by G95 etc.)...

Question: Can someone decide on the basis of the length of text string if a
short description can 'serve' or 'cannot serve' the same purpose as the
non-text content? For example, wouldn't it be more helpful to know to use
Situation A when the short description is less than 200 char etc.? A case
in point - H37 is listed under both Situations A and B, which means that
although not suitable, a 1200 char length alt attribute on a chart
(Situation B) can be implemented to claim conformance. Basically, how short
should be a short description?; Related issues: (space separated ids); WG Notes:; Resolution: A character count is not an appropriate measure for whether a short description is short, particularly since some languages are terser than other languages. An advisory technique, "Keeping short descriptions short", has been proposed but has not yet been written. Would you be willing to help write such a technique, so that people can find out best practices?; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2916: Make H79 title clearer: Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message); Context: H79: Identifying the purpose of a link using link text combined with its e...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Current: H79: Identifying the purpose of a link using link text combined with its enclosing
table cell and associated table headings

The words 'table headings' may be construed for the table's caption or title and not column / row headings for the cell.

Proposed Change:
Change to: H79: Identifying the context for a link in a data table from table cell's content and headings associated for the cell
Or
Change to: H79: Identifying the purpose of a link in a data table using link text combined
with the table cell's content and headings associated for the cell

In fact the first format may be used for other such techniques (G53, H77, H78, H80) to make them briefer; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for your comment. We will change the title of this technique to: H79: Identifying the purpose of a link in a data table using the link text combined with its enclosing table cell and associated table header cells This change will appear in the next public review draft.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2917: ARIA1 needs example: Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message); Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
ARIA1 does not include an example for links. SC 2.4.4 lists this as a sufficient technique.

Proposed Change:
Consider
<p id="weather">What's the weather like? <a href="weather.htm" aria-describedby="weather">Click here</a></p>
Note: In this example the contextual text is read by screen readers automatically when the
link gets focus upon tabbing to it. One does not have to additionally activate a screen
reader specific keystroke figure out the context.; Related issues: (space separated ids); WG Notes: <p id="weather">What's the weather like? <a href="weather.htm" aria-describedby="weather">Click here</a></p> Note: In this example the contextual text is read by screen readers automatically when the link gets focus upon tabbing to it. One does not have to additionally activate a screen reader specific keystroke figure out the context.; Resolution: Thank you for your comment. The example provided is good, but the working group prefers to keep the techniques for link purpose distinct from more general techniques referring to controls. ARIA7 and ARIA8 are used to describe how to use aria-label and aria-labelledby to meet 2.4.4, and the working group will add a "Using aria-describedby for link purpose" to its list of techniques that are needed. If you would like to contribute to the development of this technique please visit https://github.com/w3c/wcag to do via GitHub or http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ to do so via an online form.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2918: Title does not fully reflect intent: Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message); Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The technique's title is 'Using the aria-describedby property to provide a descriptive label for user interface controls'.
But the intent / objective is much wider and refers to 'descriptive info' for UI controls.

Proposed Change:
Change title for ARIA1 to:
Using the aria-describedby property to associate related description for user interface controls'
(Or 'detailed' in place of 'related').; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for your comment. The working group does not feel that the title and the description are inconsistent so will leave the title as it is currently.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2919: ARIA1 needs 2.4.4 linkage: Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message); Context: ARIA1: Using the aria-describedby property to provide a descriptive label ...; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
ARIA1 is listed as a sufficient technique for SC 2.4.4 but ARIA1 does not list this SC
under 'relates to'.

Proposed Change:
Add SC 2.4.4 under 'relates to' for ARIA1.; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for your comment. The link from Understanding 2.4.4 to ARIA1 was made in error so we are removing this link.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2920: improvement for ARIA7: Commenter: Sailesh Panchang <sailesh.panchang@deque.com> (archived message); Context: ARIA7: Using aria-labelledby for link purpose; Status:
assigned to Andrew Kirkpatrick; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
While the aria-describedby (ARIA1) test procedure actually describes how the attribute can be used to satisfy certain SC by providing additional contextual info, the test procedure
for aria-labelledby (ARIA7) does not do this and only tests for correctness of id values.
Current:
Check that each ID in the value of the aria-labelledby attribute matches an ID of a text
element used as part of the link purpose.

Proposed Change:
Add: The Text referenced by the aria-labelled attribute adequately describes the link's
purpose.; Related issues: (space separated ids); WG Notes: @@ add step 2 as described below @@ add "#2 is true" to the results.; Resolution: Thank you for your comment. The working group agrees that an additional step in the test procedure is needed. We will add step #2: Check that the combined value of the text referenced by the one or more ID's in the aria-labelledby attribute properly describes the purpose of the link element. This change will appear in the next public review draft.; (Please make sure the resolution is adapted for public consumption)

Add a comment.