w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com
This questionnaire was open from 2024-01-15 to 2024-01-31.
5 answers have been received.
Jump to results for question:
The first two questions in this survey are regarding SC 2.5.8 Target Size (Minimum)
Review the draft proposal for updating the SC 2.5.8 Target Size (Minimum) notes. You can see it in-context in the PR draft in the section Applying SC 2.5.8 Target Size (Minimum) to Non-Web Documents and Software. Note 3 is the only new content being proposed.
CAUTION: This is not opening the rest of the previously agreed upon guidance to further editing unless there is some glaring error.
Proposed new note:
Note 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to Non-Web Documents and Software.
Indicate whether this proposal is ready to incorporate into the editor's draft and note any desired changes.
Choice | All responders |
---|---|
Results | |
The proposed note is ready to incorporate into the editor's draft, as-is. | 5 |
The proposed note is ready to incorporate into the editor's draft, with the following changes. | |
The proposal isn't ready yet. |
Responder | Review proposed new note for Applying SC 2.5.8 Target Size (Minimum) to Non-web Documents and Software | Comments |
---|---|---|
Sam Ogami | The proposed note is ready to incorporate into the editor's draft, as-is. | |
Devanshu Chandra | The proposed note is ready to incorporate into the editor's draft, as-is. | |
Fernanda Bonnin | The proposed note is ready to incorporate into the editor's draft, as-is. | |
Bruce Bailey | The proposed note is ready to incorporate into the editor's draft, as-is. | |
Mitchell Evan | The proposed note is ready to incorporate into the editor's draft, as-is. |
Review the updated proposal for adding a bullet for 2.5.8 Target Size (Minimum) to the SC Problematic for Closed Functionality Section below. Indicate its readiness to include in the editor's draft. If you wish to read it in the context of the section, see Success Criteria Problematic for Closed Functionality.
Proposed content
2.5.8 Target Size (Minimum)—This Success Criterion uses CSS pixels for defining the target size. Closed functionality may not use CSS pixels as a standard measurement, but the definition of 'CSS pixel' still applies as described in Applying “CSS pixel” to Non-Web Documents and Software. If the system supports a density-independent pixel measurement, it should be used in place of CSS pixels.
NOTE 1: If the viewing distance or pixel density of the system is unknown, approximating the reference pixel as described in Applying “CSS pixel” to Non-Web Documents and Software is not possible."
NOTE 2: For software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for CSS pixels is dependent on the viewing distance and pixel density of the display."
Choice | All responders |
---|---|
Results | |
Incorporate the proposed bullet, as-is. | 3 |
Incorporate the proposed bullet, with the following changes. | 2 |
Something else. |
Responder | Proposed 2.5.8 Target Size (Minimum) content for SC problematic for Closed Functionality | Comments |
---|---|---|
Sam Ogami | Incorporate the proposed bullet, as-is. | |
Devanshu Chandra | Incorporate the proposed bullet, as-is. | |
Fernanda Bonnin | Incorporate the proposed bullet, with the following changes. | In what cases would the viewing distance of the system be unknown? do we need to provide examples? |
Bruce Bailey | Incorporate the proposed bullet, as-is. | |
Mitchell Evan | Incorporate the proposed bullet, with the following changes. | Fernanda asked: "In what cases would the viewing distance of the system be unknown?" I don't know exactly, but I believe Sam said he's talked to engineers for closed systems who have convinced him this case is needed. In one of our calls, I came to understand and agree: *if* these things are unknown then the calculation won't work, that's logical. Small but substantive edits, because we offer a choice of two calculations to get a CSS pixel, and each calculation only needs one of those values... NOTE 1: If the viewing distance *and* pixel density *are* unknown... NOTE 2: ... dependent on the viewing distance *or* pixel density of the display Typos: Note 1 should not end with a quotation mark. Note 2: calculations for CSS pixels *are* |
Review the updated proposal for 3.3.8 Accessible Authentication (Minimum) and indicate the readiness to incorporate the proposal into the editor's draft. This will be split into 5 questions, all regarding this proposal.
Background on the changes in this proposal: These changes were due to survey feedback for questions 1 and 2 , and our meeting discussion of survey results on 16 November and survey results for closed functionality question on 30 November.
Suggest edits or changes in the Google doc for 3.3.8
For this question, indicate whether the content from the beginning of the "Applying SC 3.3.8..." up to the notes (not including them) is ready to incorporate into the editor's draft.
Choice | All responders |
---|---|
Results | |
The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. | 5 |
The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | |
This proposal isn't ready yet. Provide your alternate proposal in the Google doc. |
Responder | Question 1 of 5: Review main part of Applying SC 3.3.8 Accessible Authentication (Minimum) | Comments |
---|---|---|
Sam Ogami | The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. | |
Devanshu Chandra | The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. | |
Fernanda Bonnin | The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. | |
Bruce Bailey | The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. | |
Mitchell Evan | The 3.3.8 proposed content (up to the notes) is ready to incorporate into the editor's draft, as-is. |
This question is about Note 3 in the proposal for 3.3.8 Accessible Authentication (Minimum). This did not change from the previous proposal as the group didn't come to a conclusion in the previous discussion. Indicate the readiness to incorporate Note 3 into the editor's draft.
Suggest edits or changes in the Google doc for 3.3.8.
Choice | All responders |
---|---|
Results | |
Note 3 is ready to incorporate into the editor's draft, as-is. | 3 |
Note 3 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | 1 |
This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | 1 |
Responder | Question 2 of 5: Review Note 3 of SC 3.3.8 Accessible Authentication | Comments |
---|---|---|
Sam Ogami | Note 3 is ready to incorporate into the editor's draft, as-is. | |
Devanshu Chandra | Note 3 is ready to incorporate into the editor's draft, as-is. | |
Fernanda Bonnin | Note 3 is ready to incorporate into the editor's draft, as-is. | |
Bruce Bailey | This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | I suggest we drop note 3. A reference to "device" is a reference to hardware, and we don't want to encourage using WCAG for evaluating hardware. |
Mitchell Evan | Note 3 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | See my "Option 2" for Note 3 in the Google doc. |
This question is about Note 4 in the proposal for 3.3.8 Accessible Authentication (Minimum). This is a newly proposed note. Indicate the readiness to incorporate Note 4 into the editor's draft.
Suggest edits or changes in the Google doc for 3.3.8.
Choice | All responders |
---|---|
Results | |
Note 4 is ready to incorporate into the editor's draft, as-is. | 2 |
Note 4 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | |
This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | 3 |
Responder | Question 3 of 5: Review Note 4 of SC 3.3.8 Accessible Authentication | Comments |
---|---|---|
Sam Ogami | Note 4 is ready to incorporate into the editor's draft, as-is. | |
Devanshu Chandra | Note 4 is ready to incorporate into the editor's draft, as-is. | |
Fernanda Bonnin | This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | If shared use systems are out of scope, why aren't those same shared systems out of scope for the WCAG S.C. as well? e.g. accessing your email (or any other website that is password protected) in a shared computer in a public library would have similar challenges as the user would not have access to applications that allow them to auto-complete content. |
Bruce Bailey | This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | Per comment, Note 4 Option 2 -- including moving the note to Closed Functionality. |
Mitchell Evan | This proposal isn't ready yet. Provide your alternate proposal in the Google doc. | See my "Option 2" for Note 4 in the Google doc. I propose rewriting the note and moving it to Problematic for Closed Functionality. Fernanda asked: "If shared use systems are out of scope, why aren't those same shared systems out of scope for the WCAG S.C. as well?" Good point. I believe shared use systems like a library computer are very problematic for WCAG (web) when a user can load any website they want, but they can't use their password mechanism -- but that's not a problem for WCAG2ICT to solve. Shared use systems are somewhat less problematic for web applications and software that the library provides and controls on the computer, because the library is more likely to be responsible for (or federated with) the storage of the user's credentials, and thus could provide an alternative authentication method as I mentioned in "Option 2". |
This question is about Note 5 in the proposal for 3.3.8 Accessible Authentication (Minimum). This is a newly proposed note. Indicate the readiness to incorporate Note 5 into the editor's draft.
Suggest edits or changes in the Google doc for 3.3.8.
Choice | All responders |
---|---|
Results | |
Note 5 is ready to incorporate into the editor's draft, as-is. | 2 |
Note 5 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | 3 |
This proposal isn't ready yet. Provide your alternate proposal in the Google doc. |
Responder | Question 4 of 5: Review Note 5 of SC 3.3.8 Accessible Authentication | Comments |
---|---|---|
Sam Ogami | Note 5 is ready to incorporate into the editor's draft, as-is. | |
Devanshu Chandra | Note 5 is ready to incorporate into the editor's draft, as-is. | |
Fernanda Bonnin | Note 5 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | There were some interesting comments from Mike, Mitchell and Loïc on (https://www.w3.org/2002/09/wbs/55145/WCAG2ICTauthentication/results#xq2) around calling ATM pins as out of scope because there is no good alternative, versus just highlighting there is an issue for this scenario. Also relevant to note, I believe this is the first S.C where we are explicitly calling things out of scope with Notes 3,4, and 5. (apart from hardware requirements for contrast) |
Bruce Bailey | Note 5 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | See Option 2 |
Mitchell Evan | Note 5 is ready to incorporate into the editor's draft, with the changes proposed in the Google doc. | See my "Option 2" for Note 5 in the Google doc. I think it should be in both general and Closed, but if nobody wants it in general I'm fine with only putting it in Closed. |
The proposal didn't specify whether a note was needed in the SC problematic for closed functionality section, but our previous survey on this SC indicated one was needed. We may be able to use content verbatim or summarized in that section. Indicate your preferred solution.
Use the Google doc for 3.3.8 to provide any proposed content for that section. There is a section title placeholder in the Google doc where you can add your suggested text.
Choice | All responders |
---|---|
Results | |
No bullet needed in the SC problematic for closed functionality section. | 3 |
Copy bullet(s) verbatim into the SC problematic for closed functionality section. Indicate which one(s) in the comment. | 1 |
Summarize bullet(s) in the SC problematic for closed functionality section. Indicate which one(s) in the comment. Provide suggested text in the Google doc. |
(1 response didn't contain an answer to this question)
Responder | Question 5 of 5: Does 3.3.8 Accessible Authentication need content in SC problematic for closed functionality | Comments |
---|---|---|
Sam Ogami | Copy bullet(s) verbatim into the SC problematic for closed functionality section. Indicate which one(s) in the comment. | Notes 4 - 5.. If the notes are moved to the SC problematic for closed functionality section the the SC should have an note "See also the discussion on Closed Functionality." |
Devanshu Chandra | No bullet needed in the SC problematic for closed functionality section. | |
Fernanda Bonnin | No bullet needed in the SC problematic for closed functionality section. | |
Bruce Bailey | No bullet needed in the SC problematic for closed functionality section. | |
Mitchell Evan | See my "Option 2" for Note 4 in the Google Doc, which should be moved to Closed. See my "Option 2" for Note 5 in the Google doc, which should be copied (or maybe moved) to Closed. |
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
.