LC-2939
Devarshi Pant <devarshipant@gmail.com> (archived 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?
|
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? |
tocheck |
|---|
LC-2953
Devarshi Pant <devarshipant@gmail.com> |
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
|
These examples are very similar but they illustrate a slight variation as as a result the working group would like to keep both. |
tocheck |
|---|
LC-2956
Devarshi Pant <devarshipant@gmail.com> |
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
|
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. |
tocheck |
|---|
LC-2918
Sailesh Panchang <sailesh.panchang@deque.com> (archived 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').
|
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. |
tocheck |
|---|
LC-2950
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
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. |
tocheck |
|---|
LC-2951
Sailesh Panchang <sailesh.panchang@deque.com> |
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.
|
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. |
tocheck |
|---|
LC-2952
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
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. |
tocheck |
|---|
LC-2954
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
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 |
tocheck |
|---|
LC-2955
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
The changes that you suggest are helpful and we will accept the pull request. |
tocheck |
|---|
LC-2957
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
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. |
tocheck |
|---|
LC-2958
Sailesh Panchang <sailesh.panchang@deque.com> |
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.
|
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. |
tocheck |
|---|
LC-2959
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
We have accepted this as suggested. |
tocheck |
|---|
LC-2960
Sailesh Panchang <sailesh.panchang@deque.com> |
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…
|
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. |
tocheck |
|---|
LC-2961
Sailesh Panchang <sailesh.panchang@deque.com> |
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
|
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. |
tocheck |
|---|
LC-2963
Sailesh Panchang <sailesh.panchang@deque.com> |
F89 is confusing. The title and procedure are not well-matched.
|
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 |
tocheck |
|---|
LC-2912
Alistair Hastings <alistairhastings@yahoo.com> (archived 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?
|
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. |
tocheck |
|---|
LC-2916
Sailesh Panchang <sailesh.panchang@deque.com> (archived 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
|
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. |
tocheck |
|---|
LC-2917
Sailesh Panchang <sailesh.panchang@deque.com> (archived 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.
|
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. |
tocheck |
|---|
LC-2919
Sailesh Panchang <sailesh.panchang@deque.com> (archived 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.
|
Thank you for your comment. The link from Understanding 2.4.4 to ARIA1 was made in error so we are removing this link. |
tocheck |
|---|
LC-2920
Sailesh Panchang <sailesh.panchang@deque.com> (archived 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.
|
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. |
tocheck |
|---|