w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2015-08-22 to 2015-10-01.
10 answers have been received.
Jump to results for question:
Please review the following GitHub issue response: Issue 113.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Choice | All responders |
---|---|
Results | |
Accept as proposed | 7 |
Accept with the following changes | 1 |
Do not accept at this time | 1 |
(1 response didn't contain an answer to this question)
Responder | Issue 113: Incorrect ARIA Landmark example | |
---|---|---|
Michael Elledge | ||
Andrew Kirkpatrick | Accept as proposed | Agree to run by PF but also think that we can make this fix in the meantime and then update the technique again with any new or additional information. As written the technique is somewhat controversial, but we can get the main point of the technique across and remove the controversial aspect at the same time. |
Makoto Ueki | Accept as proposed | |
Bruce Bailey | Accept as proposed | Since the proposal is to remove one side of an “or” -- do we really need to wait on PF? |
Joshue O'Connor | Accept as proposed | |
Adam Solomon | Accept with the following changes | 1. should make the update to the example code on a div outside the form 2. Should leave out the text explanation of: "The "search" role should be put on a div containing the form, or a div just inside the form, but not on the form element itself (because overriding the native semantics of existing HTML elements is not recommended)." unless we have some (even minimal) evidence that there is an adverse effect or if it is specifically stated in a standard that this is not preferable. 3. Run it by the PF |
Marc Johlic | Accept as proposed | |
James Nurthen | Do not accept at this time | I don't see a problem with role=search on a form. It seems any change we make actually makes things worse. |
David MacDonald | Accept as proposed | put it on the surrounding <div> |
Laura Carlson | Accept as proposed | The response seems okay to me but it can't hurt running it past PF as Michael suggested. https://github.com/w3c/wcag/issues/113#issuecomment-133468810 |
Please review the following GitHub issue response: Issue 111.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Choice | All responders |
---|---|
Results | |
Accept as proposed | 9 |
Accept with the following changes | |
Do not accept at this time |
(1 response didn't contain an answer to this question)
Responder | Issue 111: Example not accessible | |
---|---|---|
Michael Elledge | ||
Andrew Kirkpatrick | Accept as proposed | |
Makoto Ueki | Accept as proposed | |
Bruce Bailey | Accept as proposed | |
Joshue O'Connor | Accept as proposed | |
Adam Solomon | Accept as proposed | |
Marc Johlic | Accept as proposed | |
James Nurthen | Accept as proposed | |
David MacDonald | Accept as proposed | |
Laura Carlson | Accept as proposed |
Please review the following GitHub issue response: Issue 107.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Choice | All responders |
---|---|
Results | |
Accept as proposed | 8 |
Accept with the following changes | |
Do not accept at this time |
(2 responses didn't contain an answer to this question)
Responder | Issue 107: SC 2.1.1: These two advisory techniques are not applicable | |
---|---|---|
Michael Elledge | ||
Andrew Kirkpatrick | Accept as proposed | |
Makoto Ueki | Accept as proposed | |
Bruce Bailey | Accept as proposed | I am not clear what change is being proposed, but I don't want to hang this up. |
Joshue O'Connor | Accept as proposed | |
Adam Solomon | I see Sailesh's point, but Jonathan is correct that people will simply not see it if it is mapped to the main criterion, and therefore we should leave it where it is. | |
Marc Johlic | Accept as proposed | |
James Nurthen | Accept as proposed | |
David MacDonald | Accept as proposed | |
Laura Carlson | Accept as proposed | I'm okay with the response. I wonder though if it would help if Sailesh knew of the wider plan for "future links" in the response? It may all shake out after the "future link" issue (#91) is resolved. https://github.com/w3c/wcag/issues/91#issuecomment-132270267 |
Please review the following GitHub issue response: Issue 105.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Choice | All responders |
---|---|
Results | |
Accept as proposed | 6 |
Accept with the following changes | 1 |
Do not accept at this time |
(3 responses didn't contain an answer to this question)
Responder | Issue 105: 1.2.2 and 1.2.4 Non-Vocal Music Captioning Requirements | |
---|---|---|
Michael Elledge | ||
Andrew Kirkpatrick | Accept as proposed | agreeing that we think these would be good new techniques. |
Makoto Ueki | Accept as proposed | It might be helpful, especially for translations of this document, to have a note which reads "Note: The style guide for captions may differ among different langauges." In Japan, we still don't have any standardized style guide for captions though. For example, TV stations have their own style guides. |
Bruce Bailey | Accept with the following changes | I think the sentence is a bit of run-on. So I have editorial suggestions: An orchestra provides <INS>for</INS> Communication Access Realtime Translation (CART) captioning of each real-time Web performance<DEL>, which</DEL><INS>. The CART service</INS> captures lyrics and dialog <DEL>verbatim</DEL> as well as identifies non-vocal music by title, movement, composer, and any information that will help the user comprehend the nature of the audio. |
Joshue O'Connor | Accept as proposed | |
Adam Solomon | ||
Marc Johlic | Accept as proposed | |
James Nurthen | ||
David MacDonald | Accept as proposed | |
Laura Carlson | Accept as proposed | I added a note per Makoto's great suggestion to read: "Note: style guides for captions may differ among different languages." I agree with Bruce's suggestions. It would make it clearer. I updated the text to read: "An orchestra provides Communication Access Realtime Translation (CART) captioning of each real-time Web performance. The CART service captures lyrics and dialog as well as identifies non-vocal music by title, movement, composer, and any information that will help the user comprehend the nature of the audio." Thanks! |
Please review the following GitHub issue response: Issue 71.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Choice | All responders |
---|---|
Results | |
Accept as proposed | 5 |
Accept with the following changes | 2 |
Do not accept at this time |
(3 responses didn't contain an answer to this question)
Responder | Issue 71: C31:Using percent for font sizes | |
---|---|---|
Michael Elledge | ||
Andrew Kirkpatrick | ||
Makoto Ueki | Accept as proposed | |
Bruce Bailey | Accept with the following changes | Strike the bold “very” -- it just seems inconsistent with other technics. Or maybe explain a bit more why it is very important and not just important? Or maybe provide strong emphasis on a whole key sentence? |
Joshue O'Connor | Accept as proposed | |
Adam Solomon | ||
Marc Johlic | Accept as proposed | |
James Nurthen | Accept with the following changes | Can someone explain the rationale behind this technique? Why doesn't it allow pt font sizes or rems too. |
David MacDonald | Accept as proposed | |
Laura Carlson | Accept as proposed |
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
.