There are 31 comments (sorted by their types, and the section they are about).
1-20
21-31
question comments
general comment comments
Comment LC-2894 : Inaccessible supporting PDF examples
Commenter: Leona Zumbo <Leona.Zumbo@visionaustralia.org> on behalf of Vision Australia (archived message ) Context: in (PDF)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :A number of the PDF example documents supporting the PDF techniques remain incorrect. Digital Access at Vision Australia have previously notified the W3C of the specific errors within these documents. The incorrect examples are likely to cause confusion for those that are new to implementing these techniques so we would suggest the examples are updated.
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for your comment. The PDF examples are able to be updated continuously, and we have identified and repaired the issues you raised with the example files. The files are published and currently replace the files you identified as having errors. (Please make sure the resolution is adapted for public consumption)
Comment LC-2906 : Technique F24 promotes non-existing "color" attribute of body in example #2 (#16)
Commenter: Webcc on behalf of Fraunhofer FITContext: in
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jonathan Avila
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
i.e., see:
http://www.w3.org/TR/WCAG-TECHS/F24.html
Example #2 is using a "color" attribute on "body" element, which does not exist in the specification. Please, modify it.
Related issues: (space separated ids)
WG Notes: @@Move example 1 and 2 as example 4 and 5. Renumber the example 3,4,and 5 to 1,2, and 3 respectively. The description of the 5th example (now #3) currently reads "In the example below the link text (foreground) color is defined on the @@body element. However, the background color is not defined. Therefore, the example fails the Success Criterion. ". It should be changed to "In the example below the link text (foreground) color is defined on the anchor element. However, the background color is not defined. Therefore, the example fails the Success Criterion. ".
Add a note about newly moved examples 4 and 5 being deprecated but still seen in legacy sites. Indicate that use of these deprecated techniques are still failures and do not indicate endorsement of the bgcolor and color attributes on HTML element.
Resolution: Thank you for your comment. We appreciate your suggestion. We will move example 1 and 2 that refer to the use of color and bgcolor on the body element to be example 4 and 5 and promote the other examples to examples 1,2, and 3. The description of example 5 will be updated to refer to the anchor element and not the body element. While these examples that use bgcolor and color on the body element are deprecated, they are still failures and are still seen on many legacy websites. (Please make sure the resolution is adapted for public consumption)
Comment LC-2879 : Move the logic away from How to meet and into the technique
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: G101: Providing the definition of a word or phrase used in an unusual or r...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Loretta Guarino Reid
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :G101 is not a solution to SC 3.1.3 on it’s own. The how to meet document contains a structure based on multiple possible combinations of techniques, including G101 to create a few distinct possible solutions to SC 3.1.3. This is fairly confusing and almost impossible to test. This is the only criterium in How to meet that works by pairing multiple techniques in different ways to gain a single result. Reading one of the techniques thus doesn’t really tell you how to solve for SC 3.1.3. I expect this was done to avoid duplication of content, but I think this little bit of duplication can avoid a lot of confusion. And it’s not like there is no duplication in other techniques either. So instead of building a logical structure in How to meet, move this logic into one or multiple techniques.
This comment is part of the project for the Accessibility Support Database
Proposed Change:
I think the best solution would be to flatten the How to meet into simply having the following 5 techniques, each of which can be used to meet the criteria without strange combinations with other techniques.
- H40: Using definition lists
- H60: Using the link element to link to a glossary
- H54: Using the dfn element to identify the defining instance of a word
- G62: Providing a glossary
- G70: Providing a function to search an online dictionary
All the things the other criteria require is moved into these techniques, such as that with a definition list you should also link the definition to the definition list, and that if the same phrase is used differently on the same page it is insufficient to only link the first occurrence. This could perhaps also be a failure.
Related issues: (space separated ids)
WG Notes: @@ Needs to be implemented on many techniques:
SC 1.1.1
* G94 with H2, H24, H30, H35, H36, H37, H53, H86, FLASH1, FLASH5, FLASH28, PDF1, SL5, G196
(This one is a mess - you may need to study the Understanding document to understand all the dependencies)
* G95 with H2, H24, H30, H35, H36, H37, H53, H86, FLASH1, FLASH5, FLASH28, PDF1, SL5, G196 and with G73, G74, G92, where G92 must be combined with H45, H53, FLASH2, FLASH11, SL8
* G82 with H2, H24, H30, H35, H36, H37, H53, H86, FLASH1, FLASH5, FLASH28, PDF1, SL5, G196
* G68 with H2, H24, H30, H35, H36, H37, H53, H86, FLASH1, FLASH5, FLASH28, PDF1, SL5, G196
* G110 with with H2, H24, H30, H35, H36, H37, H53, H86, FLASH1, FLASH5, FLASH28, PDF1, SL5, G196
* G143 with G144
SC 1.2.2:
* G87 with SM11, SM12, FLASH9, SL16, SL28
SC 1.2.3:
* G69 with G58, SL17
* G78 with SL1
* G173 with SM6, SM7, FLASH26, SL1
* G8 with SM1, SM2, FLASH26, SL1
SC 1.2.4:
* G9 with G93
* G9 with G87
* G9 with G87 with SM!!, SM12
SC 1.2.5:
* G78 with SL1
* G173 with SM6, SM7, FLASH26
* G8 with SM1, SM2, FLASH26
SC 1.2.6:
* G81 with SM13, SM14
SC 1.2.7:
* G8 with SM1, SM2
SC 1.2.8:
* G69 with G58, SL17
SC 1.3.1:
* G115 with H49
SC 1.3.2:
* G57 with H34, H56, C6, C8
SC 1.4.8
Another one that is really complicated, since there are different sets of techniques for each requirement. Do we add the disclaimer to all of them?
* All the "single techniques" for parts of this SC: C23, C25, G156, G148, G175, H87, C20, C19, G172, G169, G188, C21, C26
* G146 with C12, C13, C14, C24, FLASH33, SCR34
SC 2.1.1:
* G90 with SCR20, SCR35, SCR2, SL9, SL14
* FLASH17 with FLASH22, FLASH16, FLASH14
SC 2.2.1:
* SCR16 with SCR1
SC 2.4.1
* H70 with H64
SC 2.4.2
* G88 with H25, PDF18
SC 2.4.4:
* G91 with PDF11, PDF13, SL18
SC 2.4.8:
* G127 with H59
SC 3.1.3:
* G101 with G55 with H40, H60
* G101 with G112 with H54
SC 3.1.4:
* G102 with G97, G55, H28, PDF8
* G102 with G55, G62, H60, G70, H28, PDF8
SC 3.2.2
* G80 with H32, H84, FLASH4, PDF15, SL10
SC 3.2.4:
* G197 with any sufficient technique for 1.1.1 and any sufficient technique for 4.1.2
SC 3.2.5:
* G110 with H76
SC 3.3.2
* G131 with G89, G184, G162, G83, H90, FLASH10, PDF5
SC 4.1.1
* H74 with H93 with H94
SC 4.1.2:
* G108 with H91, H44, H64, H65, H88
* G135 with FLASH32, FLASH29, FLASH30, PDF10, PDF12, SL26, SL32
* G10 with SL6, SL18, SL20, SL30
Resolution: Thank you for raising this issue. To make it easier for developers, we have added a link to the appropriate section of Understanding WCAG 2.0 in the applicability section of techniques that must be combined with another technique. For example, the applicability section of G101 contains:
This technique must be combined with other techniques to meet this success criterion. See <a href="http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/meaning-idioms.html#meaning-idioms-techniques-head" Understanding SC 3.1.3> for more details.
This change is implemented in the working branch of the WCAG documents in GitHub and will be published as part of the next document update. (Please make sure the resolution is adapted for public consumption)
Comment LC-2881 : This technique should be advisory G183
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: G183: Using a contrast ratio of 3:1 with surrounding text and providing ad...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique is a great idea, but it’s not sufficient to meet success criterion 1.4.1. There is no allowance in 1.4.1 for information to be conveyed through color alone as long as those colors have a large contrast ratio. There is simply nothing in the criterion that mentions any such thing. So even though this makes sense as a technique, this exception is not permitted by the normative part of WCAG and so it can not be considered sufficient. Since this is still a pretty good idea, it’s best to make this technique an advisory technique.
Proposed Change:
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for the comment. You are correct in stating that 1.4.1 does not allow for information to be conveyed by color alone, and that is what this technique seeks to address. Using this technique, in addition to color being used to identify links from surrounding text the relative luminance difference of 3:1 or greater (paired with additional confirmation when the user tabs to or hovers over the links) allows the links to meet 1.4.1.
To help make this more clear, we are adjusting the applicability sentence from:
Colored text when color alone is used to convey information such as words that are links in a paragraph
To:
Text with links which lack decorative effects such as underlining that typically serve to help users identify links from surrounding text.
We will leave this as a sufficient technique.
(Please make sure the resolution is adapted for public consumption)
Comment LC-2880 : This technique should be a failure technique
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H2: Combining adjacent image and text links for the same resource
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Loretta Guarino Reid
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :As an HTML technique, this one is very strange. It doesn't give you a way to solve a certain problem, rather it says not to do something; namely to have two adjacent links with the same description. This seems much more the kind of thing failure techniques are for, the "Don't do X"-type. Failing H2 doesn't mean you failed the SC, since you can still have two links, one with an image and the next with a text, and the image has the same alternative as the text. The image can still meet technique H37 (img with descriptive alt) and thus someone might conclude this meets the success criteria.
There is a pretty good argument that can be made against this scenario. If the W3C logo has the text "W3C logo" adjacent to it, this could be considered it's text alternative. Giving it an alt text of "W3C logo" would be redundant and thus the combined result of the two alternatives would be "W3C logo W3C logo" which is quite clearly not a good alternative. When these two bits of content are in separate links however, the content author MUST provide a text for each link in order to meet 4.1.2. So leaving the alt attribute empty wouldn't be a solution in this case either. The only possible solution would be to combine the two links.
If this argument is valid (And I believe WCAG isn't quite specific enough to decide either way, but opinions my vary on this.), then that would mean having adjacent links one with an image and the other with a text would that had the same description would always be a failure. For 1.1.1 if the image repeated the text in its alt attribute and for 4.1.2 if the alt attribute was left empty.
This comment is part of the project for the Accessibility Support Database
Related issues: (space separated ids)
WG Notes:
Resolution: This is a technique, and not a failure. As you note, having adjacent links does not fail WCAG. This technique demonstrates how to improve the web content usability for keyboard users.
However, we agree that the technique needs improvement. We are updating the technique to read as indicated on the wiki page:
[https://www.w3.org/WAI/GL/wiki/Techniques/HTML/Combining_adjacent_image_and_text_links_for_the_same_resource] (Please make sure the resolution is adapted for public consumption)
Comment LC-2890 : This technique entirely covered by H53
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H53: Using the body of the object element
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Kathleen Anderson
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique seems to be similar to technique H53, both use the body of an object element. Technique H27 seems incomplete however. It doesn’t have any tests and it’s examples doesn’t cover anything that H53 doesn’t cover. Perhaps H27 or H53 should be removed or the two should be merged.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: H27 and H53 do appear to be duplicates, however, H53 is more complete. I would recommend taking example 2 from H27 and adding it to H53 and then either merging the two or "retiring" H27 - I'm not sure what the correct process is.
@@move example 2 from H27 to H53, then remove H27.
Resolution: Thank you for your comment. We do agree that H27 and H53 are duplicates, however H53 appears to be the more complete version of the technique.
We feel that Example 2 (nested objects elements) in H27 is useful and belongs in H53 and we will move it there and then remove H27.
(Please make sure the resolution is adapted for public consumption)
Comment LC-2882 : Add a warning about the poor support for this technique h69
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H69: Providing heading elements at the beginning of each section of content
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sailesh Panchang
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :It seems pretty important to note that most user agents do not support navigating between headings, and not a single one support navigating frames (H70) or maps (H50). To my understanding that means that in practice none of these techniques can be relied upon except in the extremely rare situation where someone is on a closed network using Opera (which has no screen reader support as far as I’m aware). It seems to me that a warning for this would be in order.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: Explanation for "This applies to H70 as well.":
With speech off, one can use NVDA or VoiceOver or JAWS/ Window-Eyes to navigate to headings, lists, frames, etc.
Both H69 and H70 note that browsers / AT allow such navigation and that's the basis for applying these to SC 2.4.1.
Resolution: Thank you for your comment.
Technique H69 does note that "...techniques assume that people needing special user agents (including AT or special plug-ins) will get and be using that ...". The user agent
section also notes that most screen reader software support heading navigation. A free screen reader like NVDA can be operated with speech off and yet allow keyboard navigation
to support sighted keyboard-only users. VoiceOver can be used likewise on Mac OSX.
Technique H70 has been deprecated in the past, and is no longer included in the Techniques document.
Therefore, the Working Group believes no changes are warranted at this time to techniques H69 or H70.
(Please make sure the resolution is adapted for public consumption)
Comment LC-2889 : The technique should be more specific h86
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H86: Providing text alternatives for ASCII art, emoticons, and leetspeak
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Joshue O Connor
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique is quite vague and seems to cover multiple solutions. The test only requires test before or after the ASCII graphic, but in the examples you see much more then that. Including a solution with the abbr element that doesn’t actually pass the test. This technique might need to be rethought. Perhaps it can be a general technique?
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: I agree with the comment, this should be looked at in line with new emoticon etc usage and updated suitably.
Resolution: Thanks for your comment. As we discussed, we are moving this issue to the tracking system for issues raised by Working Group members. [1] We will address this using that process.
[1] https://www.w3.org/WAI/GL/track/issues/34
[1] https://www.w3.org/WAI/GL/track/issues/34 (Please make sure the resolution is adapted for public consumption)
Comment LC-2887 : This technique should be generalized h87
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H87: Not interfering with the user agent's reflow of text as the viewing w...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique doesn't test for anything specific in HTML. Many technologies can reflow the way is described in this technique. Making this a general technique would mean it would be applicable to these technologies.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: @@Change to general technique. No content changes are necessary except:
@@Change HTML and XHTML to "All technologies"
@@ Add to procedure, step 2: Verify if the user agent has a setting that needs to be enabled to allow for reflow, and if so, enable it.
Resolution: Thank you for the comment. We agree that this technique is very general and we will classify this as a general technique in the next update. (Please make sure the resolution is adapted for public consumption)
Comment LC-2884 : This technique should be generalized h90
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H90: Indicating required form controls using label or legend
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sailesh Panchang
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique doesn't test for anything specific in HTML. What the technique does is ensure that the indication that a field is required is part of a label element. This can very easily be generalized by stating that this indication should be part of the label (which may or may not be an html label element). That would make the technique more flexible and usable in other technologies.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for your comment.
Specific techniques for indicating required fields in different technologies (HTML, ARIA, Flash and PDF) are already documented. There's also G131, "Providing descriptive labels" that documents a general technique for labeling form controls. The group also feels that there is an advantage to having an HTML-specific technique as it demonstrates how to make proper use of the HTML labeling elements for indicating require status.
Based on your comment, the following text is being added to the description for G131.
"The label may also be used to include a text symbol or text indicating that input is required." We are also adding a link to H90 in the related techniques section of G131. (Please make sure the resolution is adapted for public consumption)
Comment LC-2877 : The technique should mention input type = file
Commenter: Wilco Fiers <w.fiers@accessibility.nl> (archived message ) Context: H91: Using HTML form controls and links
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The description contains a table with the different input elements. The table should also include <input type = "file"> in one of the rows.
This comment is part of the project for the Accessibility Support Database
Related issues: (space separated ids)
WG Notes: Add row for type="file" to http://www.w3.org/TR/WCAG20-TECHS/H91.html
The HTML element is: <input type="file">
Role: push button
Name: <label> element associated with it or 'title' attribute.
Value: list of selected files, or indication that no files are selected.
Resolution: Thank you for your comment. We have addressed your concern by adding <input type="file"> to the technique. (Please make sure the resolution is adapted for public consumption)
Comment LC-2885 : This technique should be generalized h92
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: H92: Including a text cue for colored form control labels
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Marc Johlic
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique doesn’t test for anything specific in HTML. The proposed solution in this technique can be applied in any technology. There is actually nothing in this technique other then it’s identifier that would have to change for this technique to be a general technique. Making this a general technique would mean it would be applicable to other technologies.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: It is interesting that the Applicability section lists "All technologies that support color and text" and not just HTML. While the Example is written in HTML, Wilco is correct in that the technique itself is more General.
The Example needs to be edited to make slightly more generic:
Example 1: Required fields in a form
The instructions for an online form say, "Required fields are shown in red and marked with (required)." The cue "(required)" is included as part of the programmatically determinable name for the control.
and then provide the specific HTML example code.
Resolution: Thank you for your comment. The Working Group agrees that this technique is applicable to all technologies and will be moved to a General Technique.
This change will appear in the next public review draft. (Please make sure the resolution is adapted for public consumption)
Comment LC-2883 : HTML technique is a duplicate of h93
Commenter: Tom Siechert <tsiechert@csufresno.edu> on behalf of California State University Fresno (archived message ) Context: H93: Ensuring that id attributes are unique on a Web page
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :It appears that this HTML technique is a duplicate of http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20051123/#H93, however, this H93 is of a different subject matter compared to the H93 referenced in the URL above.
Proposed Change:
Change in numbering of this (or the other H93) to keep both techniques as their own separate technique.
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for the comment. The technique H93 that you are referencing is from an early draft of WCAG 2.0 dating back to 2005. This technique was removed in 2006 and the H93 code was repurposed in the 2010 techniques update. We are sorry if this caused confusion, we do try to avoid re-using technique codes but since the first use was prior to WCAG 2.0 reaching Recommendation status this was not a concern in 2010 when the current version of H93 was added. We are also looking into modifying the page template for techniques to include a link to the most current version of each technique. Until this link is established, to ensure that you are reviewing the latest version of the techniques please visit the current techniques document at http://www.w3.org/TR/WCAG20-TECHS/. (Please make sure the resolution is adapted for public consumption)
Comment LC-2888 : This technique should be generalized C26
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: C26: Providing options within the content to switch to a layout that does ...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Marc Johlic
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique doesn’t test for anything specific to CSS. Providing a way to change the layout of a web page is not something that can exclusively be done in CSS either. Most technologies can do it. Making this a general technique would mean it would be applicable to other technologies.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: I agree with the commenter that I don't see a reason to keep this as a CSS technique - especially when compared to G175, G172, G188, or G146 - all sufficient techniques for SC 1.4.8.
Note: If the Work Group agrees with this decision, there are a couple of minor tweaks to be made on the page:
1) Update Applicability - @@"All technologies that support a change in layout" or "All technologies that support style switching"
2) Description, 3rd paragraph - remove this line: "I find it hard to formulate this in a completely unambiguous way."
I will attempt these changes in GitHub
Resolution: Thank you for your comment. The Working Group agrees that this technique could be moved to General Techniques and will be updated accordingly
This change will appear in the next public review draft. (Please make sure the resolution is adapted for public consumption)
Comment LC-2886 : This technique should be generalized C29
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: C29: Using a style switcher to provide a conforming alternate version
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Marc Johlic
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique doesn’t test for anything specific to CSS. Changing the style of components on a web page using some kind of style switch can be done in any technology using the method described in this technique. Making this a general technique would mean it would be applicable to other technologies.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: I could see this one going either way. C29 currently discusses using JavaScript and CSS to switch the presentation, however this could be generalized to apply to more technologies. Or - leave C29 as is and just add specifics around CSS and JavaScript to the Test Procedure:
Option 1: Make C29 a General Technique. Response to commenter: "Thank you for your comment. The Working Group agrees that this technique could be moved to General Techniques and updated to apply to all technologies by providing a method to switch presentation.
This change will appear in the next public review draft."
Option 2: Add specifics around CSS and scripting to the Test Procedure with the following update:
#2: Check that the control changes the presentation by modifying individual CSS style properties or by activating an alternate style sheet.
Response to commenter: "Thank you for your comment. At this time the Working Group feels that this should remain a CSS technique. The Test Procedure has been updated with language specific to checking for scripting controls that allow the user to change the CSS.
This change will appear in the next public review draft."
WG decided to go with Option 2
Resolution: Thank you for your comment. At this time the Working Group feels that this should remain a CSS technique. The Test Procedure has been updated with language specific to checking for scripting controls that allow the user to change the CSS.
This change will appear in the next public review draft. (Please make sure the resolution is adapted for public consumption)
Comment LC-2891 : The technique doesn't solve the problem of the success criterion SCR21
Commenter: Wilco Fiers <w.fiers@accessibility.nl> on behalf of Accessibility Foundation (archived message ) Context: SCR21: Using functions of the Document Object Model (DOM) to add content t...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Joshue O Connor
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This technique is a clear “Don’t do Xâ€, in this case document.write and innerHTML. Which would make it a failure technique, except that using document.write / innerHTML is more a question of accessibility support then of conformance to any specific criterion. I imagine this technique was created to inform developers about the innerHTML problem. But it’s done in a format that seems inappropriate for it; as a script technique.
For all techniques content can be generated using innerHTML, so limiting this to 1.3.1 seems odd. Also, this technique doesn’t actually provide a solution to 1.3.1. If you were to insert a heading without header markup, that would be an accessibility problem, even if it was done using DOM. It would probably be more appropriate to scratch this technique as it is and create an article in which this problem is explained. This article can then be referenced to from other documents.
This comment is part of the project for the Accessibility Support Database.
Related issues: (space separated ids)
WG Notes: Leaving open, work in progress.
Surveyed on https://www.w3.org/2002/09/wbs/35422/15thApril2014/results
The use of innerHTML can support the creation of accessible content if it is used to inject structured accessible HTML. The use of document.write will output a string directly to a page, and is considered an out of date method of adding content.
We acknowledge that SCR21 needs to be re-written to take into consideration changes in user agent/AT support. The working group also acknowledge that this is a wider issue relating to the use of accessible scripting techniques and WCAG. [1]
The original commenter (Wilco) suggested a proposal for dynamic content to the group. [1]
The suggestion in the 'WCAG Techniques for dynamic content' doc was surveyed by the WCAG working group ion the 15th April and overall got positive feedback. [2]
There were some outstanding action items
<Joshue> ACTION: Josh to ping Cynthia for some background on SCR21 [recorded in http://www.w3.org/2014/04/15-wai-wcag-minutes.html#action01] [DONE]
ACTION: David to connect with GOV of Canada regarding their objections to the discouraged parts of SCR21 [recorded in http://www.w3.org/2014/04/15-wai-wcag-minutes.html#action02] [DONE] [4]
As of July 16th, an ISSUE has been logged in the tracker so we can monitor progress - 'ISSUE-35: SCR21 and WCAG Scripting proposal' [3]
As we discussed, we are moving this issue to the tracking system for issues raised by Working Group members. We will address this using that process.
[1] https://www.w3.org/2002/09/wbs/35422/15thApril2014/
[2] https://www.w3.org/WAI/GL/wiki/WCAG_Techniques_for_dynamic_content
[3] https://www.w3.org/WAI/GL/track/issues/35
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/2014AprJun/0051.html
Resolution: Thanks for your comment. As we discussed, we are moving this issue to the tracking system for issues raised by Working Group members. [1] We will address this using that process.
[1] https://www.w3.org/WAI/GL/track/issues/35
(Please make sure the resolution is adapted for public consumption)
Comment LC-2903 : Technique F47 improvement
Commenter: Webcc on behalf of Fraunhofer FITContext: F47: Failure of Success Criterion 2.2.2 due to using the blink element
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jonathan Avila
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
The technique F47 should make a reference to the own documentation of Mozilla, where the use of blink is deprecated and discouraged:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/blink
Related issues: (space separated ids)
WG Notes: @@Add a Resources heading with links to these two Mozilla Developer Network Articles.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/blink
https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration
Resolution: Thank you for your comment. We agree this MDN page is a good resource and will add your suggestion. We will add a Resources heading and add a link to the Mozilla MDN articles on the blink element and a link on the CSS property text-decoration with value blink. (Please make sure the resolution is adapted for public consumption)
Comment LC-2892 : F76: Failure of Success Criterion 3.2.2
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message ) Context: F76: Failure of Success Criterion 3.2.2 due to providing instruction mater...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Andrew Kirkpatrick
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Refer to the failure technique, 'F76: Failure of Success Criterion 3.2.2
due to providing instruction material about the change of context by change
of setting in a user interface element at a location that users may bypass'
at http://www.w3.org/TR/WCAG-TECHS/F76.html.
Note the title of the failure technique and then note that the failure is
not due to providing instructional material but due to lack thereof.
Suggested change: 'F76: Failure of Success Criterion 3.2.2 due to lack of
instruction material about the change of context by change of setting in a
user interface element at a location that users may bypass.'
-Devarshi
Related issues: (space separated ids)
WG Notes: On thinking about this more I think that this technique either just repeats the SC or tries to highlight a situation where advice is not provided properly, but in the latter case it seems that it is very difficult to define the "that a user may bypass" criteria. Unless we have a clearer way to define what this means in a measurable way, we should remove the technique.
Resolution: Thanks for your comment. The Working Group agreed that the title of this failure technique is unclear, but on further reflection feels that the reason the title is not clear is because the failure technique is not clear. The key issue is that the phrase "at a location that users may bypass" is very difficult to interpret. Rather than a overly general failure technique, the working group will ensure that there are enough sufficient techniques that address this success criteria. We will remove this failure technique in the next update of the techniques.
(Please make sure the resolution is adapted for public consumption)
typo comments
Comment LC-2875 : Typo in G192
Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message ) Context: in
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Joshue O Connor
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :G192: Fully conforming to specifications
URL: http://www.w3.org/TR/WCAG-TECHS/G192.html
Under Examples, correct the sentence "It is run though ..." to "It is run
through ...."
Related issues: (space separated ids)
WG Notes:
Resolution: Thanks for the comment. We've fixed this as you recommend. (Please make sure the resolution is adapted for public consumption)
1-20
21-31
Add a comment .