W3C

Site Navigation

Nearby

Results of Questionnaire WCAG 3.0 - Error Prevention

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-05-27 to 2021-06-01.

12 answers have been received.

Jump to results for question:

Include Error Prevention in the Heartbeat publication

1. Include Error Prevention in the Heartbeat publication

The editors wish to include a new guideline in the heartbeat publication in early June: Error prevention.
It includes:

Please note that the results of this survey will be publicly viewable (a change from previous surveys). It is also possible to provide more updates to this guideline before the next (monthly-ish) publication.

Do you:

Summary

Choice	All responders
Choice	Results
Agree that this new guideline should be included	5
Agree that this new guideline should be included, only with these adjustments (comment)	4
Do not include it in the next publication	2

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

Details

Responder	Include Error Prevention in the Heartbeat publication	Comments
Todd Libby	Agree that this new guideline should be included
Andrew Kirkpatrick	Do not include it in the next publication	Until the conformance model can be more complete it is impossible to really evaluate the guideline/outcome/method, so I do not support adding additional guidelines to the public working draft until the conformance model is clarified.
Laura Carlson	Do not include it in the next publication	Agree with @awk that we should wait until the conformance model is more complete. In addition: 1. Suggest displaying the code snippets for each example in the example tab on: https://www.w3.org/WAI/GL/WCAG3/2021/methods/errors-instructions-source/#examples-button <label for="dob">Date of Birth (MM/DD/YYYY)</label> <input type="text" id="dob"></pre> and <label for="date">Date</label> <span id="date-tip">MM-DD-YYYY</span> <input type="text" id="date" aria-describedby="date-tip"> -- 2. Typo - Please delete duplicate: "Method: Method:" "Method: Method: Instructions available at the source of input (All) https://www.w3.org/WAI/GL/WCAG3/2021/methods/errors-instructions-source/
Stefan Schnabel	Agree that this new guideline should be included, only with these adjustments (comment)	Improve content of https://www.w3.org/WAI/GL/WCAG3/2021/methods/errors-instructions-source/ Technology Web (HTML, ARIA) -> Do you mean Web Applications Applications (iOS, Android, MacOS, Windows) -> Do you mean native Applications? Documents (eidtable PDF and word processing documents) -> typo, and there are also HTML DOCUMENTS
Oliver Keim	Agree that this new guideline should be included, only with these adjustments (comment)	remove typos, ("editable", if editable is required here, IMHO its not) Lists for document types or operating systems may consistently use "such as". If the list for operating systems should be complete, add "Linux and others". Error prevention may be suported by input value helpers (intrinsic and via dialogs), value validation (frontend & backend), source identification & hints to resolve errors.
David MacDonald		This is a global issues: We have at least 7 categories of Cognitive functionality. Have we provided the same level of granularity for the other categories of disability. There are multiple types of vision loss, multiple types of color blindness, and dexterity disabilities. I think we have to review the functional categories and provide a comparable level of granularity for each category. There might be some more critical errors to provide such as: -Failure to provide error messages in text The plain language description of atomic tests says "like the way we test today" And then for the holistic tests they say "test with a screen reader" I think that most professional testers today are constantly checking things with various screen readers, at least I am. If we are going to add "like we do today" to atomic and think we'd have to say the same thing in the holistic tests regarding checking with AT.
Rain Breaw Michaels	Agree that this new guideline should be included	Yes, this is an excellent guideline to include! As the examples and content is written, however, I would suggest that we avoid specifically spelling out "date format" as an example where something specific is required. The better approach is to have flexible formatting and have the system understand the date as entered by the user. If the words "date format" together are included, that makes it seem like the less good approach is just as good. An alternative would be to simply use "dates" without "format" or to use "specific data formating" without "date."
Charles Adams	Agree that this new guideline should be included	I agree with AWK that the conformance model needs to be more complete. The addition of this guidance gives us another source of data to help identify the challenges with the conformance model and will help to craft adjustments.
Makoto Ueki	Agree that this new guideline should be included, only with these adjustments (comment)	Editorial issues must be addressed before the publication. I agree with AWK. But it allows people to build one more concrete example of how WCAG 3's guidelines will look like. And it will allow us to get more feedback from the audience in the near future.
Jeanne F Spellman	Agree that this new guideline should be included	Knowing that the testing and scoring sections will change as we refine the Conformance model. This new guideline provides more valuable testing data for the WCAG3 Conformance proposals.
Gundula Niemann	Agree that this new guideline should be included, only with these adjustments (comment)	I feel some work needs to be done in the details before publishing. 1. 'Documents' is mentioned under platform as well as under technology. It should me classified only once, where I suggest 'technology', as it refers to pdf and other document formats. 2. Please name some examples with 'word processing documents' as the term might be unclear. 3. 'Web' is not a technology, therefore I suggest to say 'web technologies llike html, ARIA' 4. All points mentioned on information are relevant, yet I miss some important points for error prevention. For example, all information needed to successfully complete the task need to be given in a consumable and adequate way. And there more than instructions, like a logical order in the UI, all needed information is easily available, fields are prefilled if possible or have value suggestions, ... In caste of input with patterns, like date, phone number, IBAN, order numbers ... provide a masked input. One example: For IBAN, provide inputs fields for each digit, in groups of 4, where the cursor proceeds through the mask during entry. This eases comparison with the data source and thus human verification during input. Another point in error prevention is case insensitivity whenever appropriate, that is for example, if the entry is expected in capital letters, the input is converted to uppercase automatically. there might be more points. 5. I struggle with the first point: "Instructions that are persistent remain visible as users enter data". Instructions that disappear are per definitionem not persistent. Therefore 'that are persistent' should be dropped. What is the value of non-persistent information?
Kim Dirks	Agree that this new guideline should be included