w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2016-01-03 to 2016-02-17.
12 answers have been received.
Jump to results for question:
Issue 151 'ARIA5: About jQuery code' in GitHub has a proposed response.
Please review.
Choice | All responders |
---|---|
Results | |
Accept proposed response | 4 |
Accept proposed response with the following changes | 2 |
Do not accept the proposed response for the following reasons | 5 |
(1 response didn't contain an answer to this question)
Responder | [Github ISSUE: #151] ARIA5: About jQuery code | Comments |
---|---|---|
Kathleen Wahlbin | Accept proposed response | |
Jan Richards | Do not accept the proposed response for the following reasons | I'll accept the group consensus... but availability of visual information visually when various technologies are turned off, seems out of scope of this SC. |
James Nurthen | Do not accept the proposed response for the following reasons | The technique would prohibit images added via CSS using :before and content. These images do not disappear in high contrast mode. So long as these images have an accessible alternative then these are fine. The technique should explicitly allow this type of CSS image. |
Sailesh Panchang | Accept proposed response with the following changes | Comment is in Github |
Katie Haritos-Shea | Do not accept the proposed response for the following reasons | Be sure that whatever is proposed that the solution does not hijack the focus - mas that will break 2.4.7 Visible Focus |
Andrew Kirkpatrick | Do not accept the proposed response for the following reasons | This failure was quite simple initially in that it focused on the fact that there is no way to programmatically associate a text alternative with a CSS background image, and was therefore a clear SC 1.1.1 failure if the image was content-bearing. (it is a little dicey when dealing with an image with content but for which the content is repeated in an accessible way on the same page) I'm inclined to agree that a 1.1.1 failure isn't created when the visual image isn't displayed as a result of CSS being turned off. I do definitely agree that this is a problem for users, but don't think that we can add this to 1.1.1. I hate to suggest that this might be part of 1.3.1, but it is an uncomfortable fit anywhere so we need to make sure that this is clearer moving forward if we can't resolve where this fits within WCAG 2.0. New note - I'd like to see the high contrast image aspect in a new technique, but would also like to see it not hold up our dealing with an issue in this technique. |
Michael Cooper | Accept proposed response with the following changes | I'm ok with the proposed direction, but as ever worry about closing an issue with a promise to do something later. The issue should remain open until the new technique is created. While we could create an action to create the technique linked to this issue, that's less robust because the action might not get done. Then we will have gotten (presumably) commenter acceptance on an expectation we would do something that we didn't do, and would eventually forget all about it. |
Sarah J Swierenga | Accept proposed response | |
Laura Carlson | Accept proposed response | |
Wayne Dick | Do not accept the proposed response for the following reasons | There are several reasons for removing background images. The most important is to create a less busy background. This is a misuse of the semantics. I do not object to using generated images from CSS. I object to misusing the semantically well defined background image for something that is really a foreground image. Use of background for any other purpose is misleading AT, like High Contrast in Windows and assistive style sheets that set * {background-image: none !important"}. |
Jonathan Avila | ||
Michael Elledge | Accept proposed response | Yes, I believe providing a technique is important and would help clarify background image accessibility. |
Issue 99 in GitHub has a Proposed resolution (in the form of a pull request from David MacDonald which details a new technique).
Choice | All responders |
---|---|
Results | |
Accept proposed technique as-is | 6 |
Accept proposed technique with the following changes | 4 |
Do not accept the proposed technique for the following reasons |
(2 responses didn't contain an answer to this question)
Responder | Issue 99 | Comments |
---|---|---|
Kathleen Wahlbin | Accept proposed technique as-is | |
Jan Richards | Accept proposed technique as-is | |
James Nurthen | Accept proposed technique as-is | |
Sailesh Panchang | Accept proposed technique with the following changes | Comment is in Github |
Katie Haritos-Shea | Accept proposed technique as-is | |
Andrew Kirkpatrick | Accept proposed technique with the following changes | I do agree with the idea that artifacted content in a PDF that is important needs to be available in some way to the user. I'm concerned that we need to make it clear how one would verify that the footers are artifacted in the document. I'm also wondering if the page numbering discord is a good example. This is a problem in a document for sure, but it does affect all users on the other hand. We should check what the assistive technologies announce when you move from page 1 to page 2 in a document where the page is indicated to be "i" and "ii". |
Michael Cooper | Accept proposed technique with the following changes | As far as I can tell, this describes a failure condition, but doesn't say much about what you can do to pass. I would like to see at least references to sufficient techniques that show the passing condition. |
Sarah J Swierenga | Accept proposed technique as-is | |
Laura Carlson | Accept proposed technique as-is | |
Wayne Dick | ||
Jonathan Avila | ||
Michael Elledge | Accept proposed technique with the following changes | Need an example to illustrate, as well as instructions for how to check. |
Issue 99 in GitHub has a Proposed resolution (in the form of a pull request from David MacDonald which details a new technique).
Choice | All responders |
---|---|
Results | |
Accept proposed technique as-is | |
Accept proposed technique with the following changes | |
Do not accept the proposed technique for the following reasons |
Responder | Issue 99 | Comments |
---|---|---|
Kathleen Wahlbin | ||
Jan Richards | ||
James Nurthen | ||
Sailesh Panchang | ||
Katie Haritos-Shea | ||
Andrew Kirkpatrick | ||
Michael Cooper | ||
Sarah J Swierenga | ||
Laura Carlson | ||
Wayne Dick | ||
Jonathan Avila | ||
Michael Elledge |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.