W3C

Site Navigation

Nearby

Results of Questionnaire Error Prevention Guideline

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-09-02 to 2021-09-07.

9 answers have been received.

Jump to results for question:

Approval to move to CFC

1. Approval to move to CFC

Can we move the revised Error Prevention Guideline along with the Input instructions provided outcome and supporting methods to CFC for addition to the next update of WCAG 3?

Update: Please view the Pull request at https://github.com/w3c/silver/pull/548/files to view the most current changes

Summary

Choice	All responders
Choice	Results
Agree	7
Agree with the following changes
Disagree for the following reason	1

(1 response didn't contain an answer to this question)

Details

Responder	Approval to move to CFC	Comments
Laura Carlson	Agree
Todd Libby	Agree
Sarah Horton	Agree	Note that resolution at the Aug 17 meeting was, RESOLUTION: Move amended Error Prevention Guideline to CFC for addition to the next update of WCAG 3. This survey appears to be about the editorial changes we made in response to the Aug 17 survey: https://www.w3.org/2002/09/wbs/35422/wcag3-error-prevention-pre-cfc/results. You can see those edits here: https://github.com/w3c/silver/pull/548/files. The editorial changes are not all reflected in the linked documents. Also, the text above mentions new methods, but that may be a leftover from the Aug 17 survey. There are no new methods, just a few editorial changes.
Shawn Lauriat	Agree
Jake Abma	Disagree for the following reason	1: ------------------ I don't think the guideline serves as a good example for preventing errors. The work done by the group has so much more information not reflected yet. Short version: the outcome basically is a synonym for the guideline (Error prevention = Input instructions provided = Error prevention) and doesn't cover the true meaning of what the outcomes should be. 2: ------------------ There are more outcomes for intructions and the outcomes should have an AND relationship or are not applicable (N/A) The Methods under the outcome right now do NOT have an "OR" relationship and must have one (this is what has already been discussed before). Scoring an outcome based on methods while there is no "OR" relationship is not possible or very strange / difficult. 3: ------------------ People present at last Friday call have seen my proposal for a framework structure based on User Needs / User Functions and User Outcomes and as an example I've been busy with merging Error Prevention / Instructions provided. The results for the Outcomes is the following: 4: ------------------ Spreadsheet info available at row 43/44: https://docs.google.com/spreadsheets/d/1POhgI_xHZtSoNbHFp3r5HYIkl6ePaP8DC5d90SZ1tF4/edit#gid=752043294 User Need / (= Guideline): => Users get instructions for interaction User Outcomes: - Provide editorial instructions for complete tasks - Provide format instructions for completing inputs (example: mm/dd/yyyy) - Provide conditional instructions (example: required, dimmed, etc.) - Provide identifiable attributes (example: purpose / icons) - Instructions are present when needed (example: persistent or appear, in the viewport?!) - Instructions are connected to UIC (example: proximity, programmatic relationship, editorial text?) User Functions: => Each outcome might be applicable to one of the User Functions defined IF there's an imbalance in accessibility for that function (like the SC Acceptance Criteria). The formula is: User needs <-- intersection --> User Function = User Outcome (requirements) 5: ------------------ The methods are not worked out but this work can be done later, just like we do with techniques in WCAG 2.x
Janina Sajka	Agree	I think it important to publish good work, even if it's not the eventual language we think we will adopt when we finalize and take WCAG 3 through the CR/PR/TR process. So, I favor this publication because it moves us forward in a good way.
Michael Gower		I'm getting a 404 on the Error Prevention Guideline link. INSTRUCTIONS FOR COMPLETING TASKS I'm concerned with the method 'Instructions for completing tasks' including the following example: "Providing simple instructions within labels". Typically labels that include instructions are wordy and often counterproductive. The example you give "(required)" is not so much an instruction as an indicator. If this is specifically meant to address required inputs, why not make it something like "Identifying inputs that must be completed" I'm not sure the User need section is really addressing in the way intended? I thought they were supposed to align with Functional needs? I don't think your test procedure really captures checking for Required fields. REQUIRED INPUTS INDICATED Okay, so given there is a separate method for required inputs, why is that appearing in the prior input? Removing references to required inputs from instructions resolves most of my prior concerns. I think there are 2 scenarios that are legitimate ways to meet this which don't align with some of your guidance. They are: 1) Scenario: all fields are required. Solution: "All questions must be answered" is stated once at the start of the form. Fields are still programmatically marked as required, but no additional visual indicator is provided. 2) Almost all fields are required.Solution: "Responses are required, except where noted." appears at top of form. Fields that are not required are marked "(optional)" INSTRUCTIONS AVAILABLE... "Instructions provided using the placeholder attribute are not persistent and therefore do not meet this requirement." I was a little surprised by this, which appears in the Detailed description section, because I didn't think a Method was considered a "requirement". It also seemed a little technology specific. Finally, I think it needs the word "only" as in "Instructions provided using only the placeholder..."
Bruce Bailey	Agree
Jeanne F Spellman	Agree