Are we all happy with this? I envision a short script in stack overflow making a lot of this automatic as soon as it becomes a requirement

new text
"Minimize user errors: The unit and meaning ambiguous input data fields are clarified. Input error are automatic correction where the correction can be reliably made. "

Changes in the description:
The examples would be changed/added for the data collect date information as 3 discrete pieces of information, Date, Month and Year" - or more abstractly, "Ensure all fields in a compound data-set is individually visibly labelled"
We also need to clarify that this does NOT include auto spelling correct - unless it is for names that are of a limited data set (so you can auto correct the state spelling inside the US but not a personal name which can not be done reliably)
Note this is based on off list comments

from gregg
"Minimize user errors: The units and meaning of ambiguous input data fields are clarified. Input errors are automatically corrected where the correction can be reliably made. "

The concerns I would have with this are

what does unit mean (do you mean units - like inches or pound etc?)
when is an input data field amgibuous? (if it is ambiguous if there are no units or labels — the this SC is circular.) (kind of like saying Things that are unclear are clarified but if they are clarified — then how can the be unclear. Remember SC are statements of fact — not commands. things are are unclear should be clarified is a command but not a true false statement
Remember that all SC should be true false statements
ambiguous - is not testable (everyone has a different opinion unless egregious)
what does Clarified mean

I like the last one - -though I don’t know how often it is true. I often find the corrections are wrong and really mess me up. Better to suggest than to do?
perhaps another is ‘when an input error is detected - and remediation advice is possible - it is offered. ?

Minimize user errors: Input error are automatic corrected where the correction can be reliably made.

This avoids Greggs issues

@lseeman Is there a PR ready to go on this or do you need more time?

Updated the issue description to reflect the FPWD text.

New wording

The user can select from a choice of valid input values when there a finite set of values for a input. Alternative formats of separate characters such as dash, dots, bracket and spaces are accepted in numerical inputs.

we are also happy to make this two sc.

There was an error in Lisa's version. The word "separate" should have been "separator". Therefore it should now read:

New wording

The user can select from a choice of valid input values when there a finite set of values for a input. Alternative formats of separator characters such as dash, dots, bracket and spaces are accepted in numerical inputs.

we are also happy to make this two sc.

@jnurthen A very good point. I'm also not sure what the value of X is. I personally find that some of the lists of countries are tiresomely long and difficult to navigate (particularly when I don't know if I am looking for "United Kingdom", "Great Britain", "England" or some other variant!

@jnurthen @mapluke mpluke how about when the set of valid values for an input field or section of an input fieild is less then 40

It would now read

The user can select from a choice of valid input values, unless there are more than forty valid values for any section of the input field.

@lseeman The problem is we will get asked to justify we have chosen 40 and not 35, or 50 and at the moment we don't have a good answer. Choosing a number that is greater or equal to 31 allows all days of a month to be included, but any figure over that needs some evidence to back up its selection.
How about using 31, which does have the very clear and precise days in a month justification?

I wonder if this would be better at a AAA level. It seems like we may be putting an undue burden on authors at level A, since there may be a significant amount of programming required to provide a complete set of acceptable alternatives.

The user can select from a choice of valid input values, unless there are more than thirty one valid values for any section of the input field.

The user can select from a choice of valid input values, unless there are more than thirty one valid values for any section of the input field or unless this interferes with the main purpose of the content (such as evaluation applications).
Alternative formats of separator characters such as dash, dots, bracket and spaces are accepted in numerical inputs except for the use of a dot as a decimal mark.

FYI
we need to point out in the understanding section that the user can also enter free form text and that if any section of the input field is like a field record (so if each digit going up to 9 in a large number is not included) we can define section of an input field as a record

Common input errors are automatically corrected where the corrections can be reliably made.

Although I see the benefits of what is intended here it’s more a technique for SC 3.3.3. or maybe a AAA as Mike mentioned at #13 (comment) Implementation can be hard and with multiple languages on a site may cause frustrating results due to differences in writing formats (example: dd-mm-yy VS mm-dd-yy). Are automatic adjustments, which may end up in the wrong results, the responsibility for the (web site ) owner for example or for the user? Do we need a confirmation in place for all adjustements like we have at SC 3.3.4?

3/2/2017 may easily be converted to 03/02/2017 but 3/12/2017 converted to 03/12/2017 could be the wrong result as I just forgot to ad a ‘1’ to the date 31/12/2017.

working with @lseeman on some rewording for this one. Please provide comments...

• Where it is possible to provide pre-defined choices, the user can select from a list of valid input values.
• Where users must manually enter numerical inputs, alternative separator characters are accepted.

Exceptions:

• Where pre-defined choices for a piece of data have more than thirty-one valid values, it is not necessary to provide pre-defined choices. For example, a piece of data with more then 31 choices could be a year in a date field.
• Where pre-defined choices interfere with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

Questions:

• is "a piece of data" better than "an input field"
• is the first exception better without the "For example..." sentence? Can this just go in the understanding document?

Is the phrasing "where it is possible" viable for a Success Criteria? I suspect this would be a "get out of jail, free" card and most devs would skip this entirely.

I do like this SC where it pertains to numbers - and more specifically to manage date input, but perhaps that might be too narrow of a scope (having this SC focus solely on date inputs)?

I'm still struggling on how this can be implemented on text inputs. I see where it can be of value in some situations where options are limited - but in cases where the the options are going to be pre-defined (or limited), aren't they already going to provide that list of valid inputs?

For conflicts on other SC I don’t see a potential failure of 3.2.2 On Input – Level A as it doesn’t change the context as defined in https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html#context-changedef

For the title of the SC itself “Minimize User Errors” I have the feeling this title is only partly covered by the solutions we try to find for the intent as described (too generic).

We do minimize user errors this way but there’s a lot more possible for minimizing user errors and to confiscate the whole spectrum of minimizing user errors for these two suggested options may conflict other minimizing user error options in the future as they all want to belong tot this SC.

I came across a usability discussion by the UK Government about why they don't use select boxes.

http://govuk-elements.herokuapp.com/form-elements#form-select-boxes
https://paper.dropbox.com/doc/Select-boxes-v7PWDvPDV2tmc9pzDbm3s

They say:

1. Users unable to close the select.
2. Users try typing into the select
3. Users confuse focused items with select items
4. Users try to pinch zoom select option on tablets

I'm not sure what to do about this, but I thought we should be aware of it.

@DavidMacDonald

I came across a usability discussion by the UK Government about why they don't use select boxes.

I think their guidance is kinda flaky.

These are their stated reasons, and my comments.

They hide the choices they represent. Users have to interact with the control before they know what they're being asked, which makes it harder to comprehend things at a glance.

That's what a label is for. Selects can also be programmatically set to expose more than one value by default.

They're hard for some people to use. Less experienced users can struggle to use these controls, especially if they contain a lot of options - either they don't know how to interact with them, or they're unaware that they can scroll through the list.

I'd like to see some studies supporting that. Including instructions for operation is obviously an option.

They can cause accessibility issues. On some devices the list of options cannot be zoomed, which means that some people with visual impairments cannot use them.

What devices, and in what context? Is anyone aware of any issues?

They suggest a few options:

Free text boxes
Sometimes it's better to just let users type their response as free text.
Radio buttons or checkboxes
For shorter lists, consider using radio buttons or checkboxes. Remember, long lists can sometimes be broken into multiple shorter lists by asking a few questions up-front to filter out options.
Autocomplete boxes
For long lists of known options (like countries) try using autocomplete boxes.
Custom select boxes
Some of the usability issues of select boxes can be addressed by creating customised controls. These should always be tested very thoroughly though, especially for accessibility.

So, their primary advice is antithetical to what COGA is seeking. Their advice to use radio buttons and checkboxes aligns with what we have for language now and could be a technique (we're not requiring a select; we're saying provide a list of options, which radios and checkboxes are). Autocomplete? I think that's going to depend on implementation. Their example of countries shows 3 options! Their advice to make custom select boxes? I originally though "yuck" but their example is similar to an ARIA pattern. Still a risky piece of advice without more qualifications though.

Although the new / adjusted text gets better on its own it looks a bit like we’re drifting off the main purpose here. The intent text...
Although related I can’t find this information back in the new proposed text and also the number constraint is only part of the options for auto-correct.

@jake-abma, so first off, please ignore the Intent and other material for the time being. Discussion is focused entirely on the SC language.
In regard to this changing from the original, yes, it is. A decision was made to heavily refine the original challenging parametres and focus on something measurable and testable.

For the title of the SC itself “Minimize User Errors” I have the feeling this title is only partly covered by the solutions we try to find for the intent as described (too generic).

Suggestions? Would "Minimize User Input Errors" be better?

Here we do see it’s about manually entered data which is the basis of the intent but why only numerical data? If spaces are part of the “separator” characters OR if content needs to change to contain spaces in order to meet the data format this is not only about numbers.
As an example you may have to fill in a bank account and do it as follows: “NL31INGB0001234567” while this is auto-corrected to “NL31 INGB 0001 2345 67” (with spaces).

I mentioned considerations for spacing in the definition I provided to separator characters. If we can find ways to make this not just numeric, I think that would be great. I just think that becomes more challenging. Might make more sense as a Best Practice.

BTW, here is the first draft I sent with regard to a definition of separator characters...

Separator characters
Delineators between sequences of numbers, which are used to separate a long numeric string into culturally or visually accepted groupings. Separators are common in dates, phone numbers and identify numbers. Common separators include forward slashes (/), colons (:), dashes (-), commas (,) and spaces. In a numeric string, an alternative separator key could be any alpha or punctuation key which does not affect the value of the numeric string.

The lack of an separator key may also be acceptable. I wonder if we need to specify that?

Do we need to indicate at this point that the author does not need to preserve the alternative separator, just accept it when accepting the number? I would think that would be a technique...

I like the definition.

The lack of an separator key may also be acceptable. I wonder if we need to specify that?

I think so

Do we need to indicate at this point that the author does not need to preserve the alternative separator, just accept it when accepting the number? I would think that would be a technique...

Yes I think so.

Okay, then, here it is in full form. Based on reaction to this, I'll put in a pull request on the git version...

Minimize User Input Errors

Where users are required to submit information, all of the following are true:

1. Where all possible inputs come from a discrete set of data values, a user can select from a choice of valid input values without manually entering the value.
2. Where numerical data needs to be manually entered, a user can leave out separator characters or use alternative separator characters.

Exceptions

1. Where the set of discrete data values is larger than thirty-one valid values.
2. Where providing a list of valid input values interferes with the main purpose of the content.
3. Where leaving out or substituting separator characters could alter the numeric value, such as substituting commas with periods.

Definitions

Separator characters
Delineators between sequences of numbers, which are used to separate a long numeric string into culturally or visually accepted groupings. Separators are common in dates, phone numbers and identify numbers. Common separators include forward slashes (/), colons (:), dashes (-), commas (,) and spaces. In a numeric string, an alternative separator key could be any alpha or punctuation key which does not affect the value of the numeric string.
Discrete data
Data that can only take certain values. Discrete data is based on counts. Only a finite number of values is possible, and the values cannot be subdivided meaningfully.

• altered the title to Minimize User Input Errors
• added in the idea that a user can not use a separator character, and worked an absence of a separator character into the exception as well
• altered the second exception to make it a bit clearer
• added definitions
• need to make a technique for substituting separators
• capture use of separators in alphanumeric as best practice (unless anyone else thinks we can make it tight enough to include in the second bullet now?)

@awkawk and @joshueoconnor, Style question.
Should the 2 requirements be an ordered or unordered list? I see both in the existing 2.0 language and can see no difference. I would have thought when all listed items are required, that might be numbered, and where it is at least one, it would be bulleted, but that is not the case. I'm listing them all here, in the hopes we can make a decision and make it consistent for all our new SC:

Ordered list:

"Achieve the following"

1.4.8 Visual Presentation

"at least one of the following is true"

3.3.4 Error Prevention (Legal, Financial, Data)
3.3.6 Error Prevention (All)

Unordered list:

list of exceptions

1.1.1 Non-text Content
1.4.3 Contrast (Minimum)
1.4.5 Images of Text
1.4.6 Contrast (Enhanced)

"The following are true"

1.2.1 Audio-only and Video-only (Prerecorded)
2.2.2 Pause, Stop, Hide

"At least on of the following is true"

1.4.7 Low or No Background Audio
2.2.1 Timing Adjustable

Since the list of exceptions seems consistently unordered, I will adopt that for the exceptions. I will leave the 'all' as an ordered list, since that makes more sense to me.

@nschonni and several others made the following comments at the Global accessibility Awareness Day

• Minimize user errors: UK research, plus native implementations have been poor (date pickers, drop downs, validation)

Perhaps we should have a conversation with the research team at the UK GOV who did this, to evaluate their findings and weigh them.

@mbgower thanks for the feedback!

so first off, please ignore the Intent and other material for the time being. Discussion is focused entirely on the SC language.

Ok, clear, but this brings me to the question of the texts on Github and clearance on what to respond on. What is the rationale / way of work for members to respond? This may cause lots of waste in spend time and would work better if this is updated on a regular basis.

Is this already documented somewhere?

Would "Minimize User Input Errors" be better?

Seems more durable, could ask others what they think?

If we can find ways to make this not just numeric, I think that would be great. I just think that becomes more challenging. Might make more sense as a Best Practice.

The example I gave is a regular and common pattern along with others we could find. It would feel not correct not to take these ones along in the SC and only focus on numbers. It’s more a case of data formats and automatic corrections on data formats or not? It totally would suit the SC if this is for all formatting. All input values could fall under “Common input errors…”

Hi @mbgower still wondering why the focus on numerical data

Where numerical data needs to be manually entered…

Where will it go wrong if we just make it “Where data needs to be manually entered…”?

Also for the definition of “Separator characters”

“Separator characters” Delineators between sequences of numbers, which are used to separate a long numeric string into culturally or visually accepted groupings…

According to me we can not use this for a definition as a separator between letters (or other characters) are also separators.

Besides the example I gave before we also have postal codes (numbers and letters mixed with a separator between), string inputs with a separator (like providing tags in a CMS) and lots more.

A generic approach where the data format i.c.w. the separator is the focal point and not fixed on numbers would be preferable.

@jake-abma your comments on the definition of separator keys highlights the challenge in making it more than numbers. If we expanded what we're covering for the input scenario to include alphas, then as you point out, the separator definition would need to be reduced to a specific subset of punctuation.

You then have a few problems:

1. how do we define that subset? How cultural is it -- what do we need to do to cover internationalization?
2. what happens if one of those separator characters is now part of the required input string -- that is, not used a separator but as a required part of a string?

If you believe we can cover this by language changes, I'm open to suggestions

Perhaps we should have a conversation with the research team at the UK GOV who did this, to evaluate their findings and weigh them.
@lseeman , @DavidMacDonald made this suggestion in his prior comment. is this worth following up on?

Solid view @johnfoliot,

When I was re-reading the SC text today I had the same feeling, did’t mention it yet but would even elaborate a bit on this.

1. Where all possible inputs come from a discrete set of data values, a user can select from a choice of valid input values without manually entering the value.

Does this means as an A Level SC this is mandatory? Even with / without Johns examples, would a plain input text element fail IF there are less than 32 known discrete data values (always)?

This would dictate the choice / design of the site / application and I don’t think this is what we want to achieve here. Or DO we want to dictate solutions like a text input and alternative selects OR text input and always an auto-suggest when less than 32 known discrete data values are present?

From an accessibility perspective also for lots of people the text input is preferable above selects or auto-suggest as these are harder to operate / make accessible (on all devices).

There is a concern that this will be misinterpreted to suggest creating something like...

Are we really thinking anyone would try to alter a single input date field into 8 separate inputs that each take a numeral? Or a 10-digit phone number into 10 separate inputs? I can envision dates being three-field inputs and have seen some implementations that way, i.e., Y-M-D (1900-2017, 1-12, 1-31). I guess it's conceivable that someone might try a phone line as code-trunk-line (200-999, 100-999, 1-9999). But note that neither of those scenarios is required to meet this proposed SC. The most that would be required would be requiring the provision of month and day of month as options to choose from. All the others fall under existing exceptions. Note too that something like an accessible date picker negates the need to offer any select containing numbers in the date scenario.

Is anyone else gleaning the language as requesting or condoning what John is concerned with?

would a plain input text element fail IF there are less than 32 known discrete data values (always)?

Yes, it would. What examples can you think of where this would be problematic?

Also, I can only think of situations where this would impact numerical values, and so I wonder if that is also a relevant distinction

@marcjohlic has been advocating restricting this SC solely to numeric inputs. So I guess that is one potential option, but that just seems overly reduced to me.

I'm not sure that your exception really resolves what I think you're viewing as a potential issue. Can we get some others weighing in on these three topics?

• restricting to numeric input
• expanding to make the numeric input requirement expand to letters as well
• outlier situations we need to address, and to what degree they could be dealt with in techniques and Understanding doc

In example, could we make the second requirement be

Where alphanumeric data needs to be manually entered, a user can leave out separator characters or use alternative separator characters.

Might have to add a bit to the separator definition to accommodate that. Also don't know whether the term "alphanumeric" (or the concept of a "separator") has globalization considerations.

[restricting to numerical] but that just seems overly reduced to me. but that just seems overly reduced to me.

I think the suggestion is just for the second part... separators, not the first part (selecting from a list)

I think restricting the separator requirement to numerical data is prudent. But Jake's example of Postal codes is interesting... Mike G. @mbgower counter concerns I think trump them though, unless they can be answered.

I think someone needs to track down the UK team... because there will be a lot of references to how WCAG is flying in the face of their recommendations. Let's get to the bottom of it.
https://www.formisimo.com/blog/why-are-drop-downs-and-select-boxes-bad-for-forms/

Jake's example of Postal codes is interesting

There are error checking algorithms that already standardize the space in the Canadian Postal code format (A1A 1A1) and ensure numerics and alphas appear in the right locations in the string. (So that someone typing v8v25m gets prompted to confirm V8V 2M5 is the correct code). Such algorithms are what I think were envisioned in the original scope of the SC. We can certainly offer encouraging language for incorporating these, and best practice techniques, but I do think we'll have to reduce down to what is truly measurable to get initial traction.

@DavidMacDonald, what do you think of this mod to the second point? We'd need some word alterations to the separator definition, but it is essentially already covered by it. I'm a little leery of extending it, but I'd like some reaction.

Where alphanumeric data needs to be manually entered, a user can leave out separator characters or use alternative separator characters.

My biggest concern? That suddenly now we have to figure out how someone's text entry is interpreted without spaces, as an example, is it "carpet" one word or "car pet"? Or worse, is punctuation a form of separator, and do I have to add it in? "eats, shoots and leaves".

If someone can come up with something firm, cool. Otherwise focusing at least on only numbers for the manually entry is a lot cleaner.

I think for this dot release we'll need to stick with numerical for the separator requirements. @mbgower

I've established contact with the Gov UK team, and will try to get to the bottom of their recommendations to NOT use select and that text boxes are better, and maybe we can have a call with them and @lseeman and a few of us and try to steer these waters together.

Regarding @johnfoliot concern that its not explicit enough about the user being able to choose and automatically enter the choice, that can be word smithed, We could define "choose". I agree we don't want the word "select" because it maps directly to an HTML element, and apparently its an element that some UI schools of thought think is poor. That's what I'd like to get to the bottom of.

To be surveyed shortly by group