Minimize User Errors

[lseeman]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Common Input Error definition for viewing | Common Input Error definition for editing
• Reliable and Achievable definition for viewing | Reliable and Achievable definition for editing
• SC in full draft guideline

SC Shortname

Minimize User Errors

SC Text

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

Suggestion for Priority Level

(A)

Related Glossary additions or changes

• common input error: errors that have been documented in the understanding of the Success Criteria section or have supportive techniques or that have been reported or documented more then one time and there is a known way to identify them
• reliable and achievable (known to be): Identified in the WCAG techniques as possible to reliably correct an errors, or found in user testing to constantly

What Principle and Guideline the SC falls within.

Principle 3 Understandable - Guideline 3.3: Help users avoid and correct mistakes.

This is an update to 3.3.3 Error Suggestion

Description

The intent of this Success Criteria is to minimize user generated errors by detecting, and when reliable and possible, automatically correcting common input errors.

For example, while registering for an online banking account a form requires the input of the user's birthdate. The required input format is xx/xx/xxxx with a leading zero for single digits. If a single input field with no input correction is presented, a user with a cognitive disability may enter 1/3/1996 thus triggering an error notification. It may not be clear to the user that the required format is 01/03/1996 even if an example for instance, xx/xx/xxxx, is shown below the input field or in the error notification. To alleviate any confusion for the user the application should insert a leading zero if a single digit is entered into the month or day along with the required forwardslash characters which act as a delimeter between the month, day and year.

Minimizing user generated errors by automatically correcting them will also minimize error notifications. Error notifications may be distracting for some users with cognitive disabilities, taking focus away from tasks and task completion. Users with cognitive disabilities may find it difficult to understand how to correct an error even when a notification is given. In the case of an unsuccessful form submission, this group of users may abandon forms because they are unsure of how to correct the error even though they are aware that an error has occurred.

If automatic correction is reliable and possible it should be implemented. If automatic correction is not possible the content author, the user agent or supported APIs should provide a description of the error along with suggestions for fixing the error except when to do so would jeopardize the security or purpose of the content.

This Success Criterion helps users who need help preventing errors.

Benefits

People with cognitive disabilities and aging users abandon tasks and believe they cannot complete them if they receive too many errors. See Neilson studies.

We need to minimize errors because:

• Error notifications may be confusing for users with cognitive disabilities. Many users will not understand the problem making the task impossible to complete
• Correcting errors is often difficult and frustrating for the user. Many users give up when they get successive errors
• Error notifications can distract a user from tasks and task completion
• Correcting errors before they occur will minimize the number of actions needed to complete a task or process

This Success Criterion helps people with many different cognitive disabilities including people with:

• Language related disabilities
• Memory related disabilities
• Focus and attention related disabilities
• Disabilities that effects executive function and decision making

Related Resources

• Background research document including research carried out by Neil Milliken with web users who have dyscalculia - case studies.
• User Needs Table 3: Entering data, error prevention & recovery

Testability

1. Identify data with a constrained format in the form
2. look at techniques for these types of data formats to see if they are included as reliably fixable
3. Input common formats for a field which has a data format requirement (as identified in the techniques)
4. Confirm that all common formats for writing the information are accepted

Techniques

• Accept as many formats as possible of different ways of writing a phone number
• Accept as many formats as possible of different ways of writing a date format
• Using an interface were only valid dates can be selected
• Accept voice prompts for people with a speech impairment
• Correct errors of the post code being written in the text field with the city or state information
• Calendars and dates -- Calendars should default to the first relevant day. Work calendars should default to first working day of a user's locale. -- Calendar based booking systems must avoid ability to book return date before departure date. Failure example: The booking form provides two calendars without clear labels and instruction and user is able to select dates without warning as to whether they are possible e.g. flight out on June 1st - flight return May 30th.

Pass example:User is unable to select inappropriate dates and a simple explanation provided should he/she try to do so.

Failure example: User can select inappropriate dates without warning. Calendar merely grays out inappropriate dates which may not be noticed. No warnings provided.

• Temperature Use the default temperature format of location. The requirement to convert between Centigrade and Fahrenheit and vice versa is burdensome so defaulting to the format of the locale removes one layer of complexity. We can also include: -- Automatic correction of required formats for any input fields -- Appropriate default values for date fields within the context of the application -- Appropriate default time zone format based on location -- Appropriate default currency format based on location -- Appropriate default temperature format based on location

Working group notes

removed the first sentence: Identify common input errors.

It was decided that the original COGA Success Criteria below should be broken into three separate Success Criteria - Minimize User Errors (outlined above), Labels or Instructions, and Identify Charges.

Prevent the user from making errors

Was: Support is provided that help users complete and check their task, that includes

(may be provided via a standard personalization mechanism) (COGA Techniques 2.9 )

In forms

1. Use known techniques to prevent errors that are relevant to the content. All standard ways of representing information are accepted as input formats, such as different ways of writing a phone number and date formats.
2. Documented common input errors can be corrected automatically. (example spelling mistakes)
3. Enable and identify the default format and standards of locale and allow for change of format on labels and user input (removed use the default format and standards of locale and allow for change of format)
4. Clear visual indicators are provided that identify what information is essential, and non-essential information is clearly differentiated from essential information.
5. Instructions are provided if there is not a label that fully describe the control or if it is not clear were to get the required information. Instructions should explain the purpose and usage of the control. (Graphics with a text alternative may be sufficient) ( A clear instruction or information is on where 99% of your target audience understand immediately what to do)

For legal and financial transactions

1. Options that may disadvantage the user are only selected at the users specific request.
2. All types of charges must be clear at the start of a transaction task.
3. When a minimum is known for a type of charge it must be be made clear at the start of the transaction task. (from support the user)

For all content

1. Non native content and sponsored content are clearly marked and visually differentiated by standardized techniques
2. Clearly differentiate between facts and less substantiated opinions. Was rewritten from "Clearly differentiate between opinions and facts "

[lseeman]

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

[lseeman]

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

[lseeman]

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. ?

[lseeman]

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

This avoids Greggs issues

[joshueoconnor]

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

[lseeman]

there was a PR a while ago

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Sat, 04 Feb 2017 19:53:30 +0200 joshueoconnor<notifications@github.com> wrote ----

@lseeman Is there a PR ready to go on this or do you need more time? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[awkawk]

Updated the issue description to reflect the FPWD text.

[lseeman]

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.

[mapluke]

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]

I think there needs to be an upper limit on the finite set of values for an input. It is not helpful to present a list of choices where there are more than X results (no idea what this X is). Allowing selection using some sort of autocomplete rather than being presented with all the choices is far more appropriate in these circumstances.

Regards, James

On Apr 26, 2017, 3:31 PM -0700, mapluke notifications@github.com, wrote:

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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mapluke]

@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!

[lseeman]

@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

[lseeman]

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.

[mapluke]

@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?

[MikeElledge]

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.

[lseeman]

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

[jake-abma]

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 https://github.com/w3c/wcag21/issues/13#issuecomment-298666264 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.

[mbgower]

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?

[marcjohlic]

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?

[mapluke]

@marcjohlic No, you are quite right - "where it is possible" will not be accepted. Here is a suggested way to overcome this problem:

• Where only one member of a set of discrete data values is an acceptable input, the user can select from a list of those valid input values.
• Where numerical data can be manually entered, alternative separator characters are accepted.

Exceptions:

• Where the set of discrete data values is larger 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 limiting input values to a set of discrete values interferes with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

[johnfoliot]

Where it is possible to provide pre-defined choices, the user can select from a list of valid input values.

Hi Mike,

Playing devil's advocate here, would the following meet this new SC?

"Pick a number between 1 and 20: "

In the example above, I have suggested / requested-one-of a possible 20 "pre-defined" choices as valid input values that you can select from (with me assuming you can count from one to twenty << the weak link here). However, I have not actually provided you with a "list" of those options, as my example question presumes that you already know what those 20 options may be.

If it is deemed non-compliant, would providing an external list http://www.manythings.org/vocabulary/lists/b/words.php?f=numbers_1-20 (or similar https://nicholasacademy.com/numbers1to20chart.gif) meet the requirement?

If my example passes (and I will argue that it does meet the "letter-of-the-law" w.r.t. the actual current wording) then it strikes me then that the current wording really isn't addressing the issue (as I understand it), which is that we want the content author to present specific choices, rather than expect the user to be able to 'contain' the possible answers in short or long-term memory (am I understanding the gist of the issue correctly? Lisa?)

JF

On Thu, May 11, 2017 at 7:08 AM, mapluke notifications@github.com wrote:

@marcjohlic https://github.com/marcjohlic No, you are quite right - "where it is possible" will not be accepted. Here is a suggested way to overcome this problem:

• Where only one member of a set of discrete data values is an acceptable input, the user can select from a list of those valid input values.
• Where numerical data can be manually entered, alternative separator characters are accepted.

Exceptions:

• Where the set of discrete data values is larger 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 limiting input values to a set of discrete values interferes with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/13#issuecomment-300769872, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c6MSb3z-ugCc7cIcnyRDIVBOeIptks5r4vpCgaJpZM4J_16g .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mapluke]

@johnfoliot I think you are rather playing fast and loose with the term "select" which in normal UI design means something that can be touched or clicked on.

So I don't think that your non-interactive example that you linked to meets the requirement at all. I notice that the original also uses the word "select" and the example also passes that version using your interpretation of select.

Maybe, for WCAG, we need to include a glossary term "select". Maybe this has already been done by the MATF perhaps.

[mbgower]

the user can select from a list of valid input values.

@johnfoliot , I'd suggest that what you describe is not the user actually selecting from a list, so I'd say it failed. I take your point, but at some point we have to assume that clarity is provided in the Intent section and in the techniques.

I personally believe that we also have to assume a willingness by users to meet the intent. So, to take your example. Let's say that someone creates such an interaction and we deem it to pass. Is it well designed? Does it make sense? If folks want to create an awful user experience to try to circumvent a requirement, I don't think we can stop them. This is going to be especially true in many of the cognitive ones, where we are ultimately talking a lot more about design and UX considerations than we are about technical accessibility.

I support @mapluke's recent rewrite, and think it is clear enough to invite further discussion. I'm repasting here with a few tweaks, minus the example in the exception, which I think adds nothing. I've also pulled out the second part of the first exception, which seems to me to be redundant.

• Where a value from a set of discrete data values is the acceptable input, the user can select from a list of those valid input values.
• Where numerical data can be manually entered, alternative separator characters are accepted.

Exceptions:

• Where the set of discrete data values is larger than thirty-one valid values.
• Where limiting input values to a set of discrete values interferes with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

[johnfoliot]

Mike and Mike,

select programmatically choose (?)

We don't want to say "use the element", as that is both overly prescriptive as well as HTML-centric. However, since I spend the bulk of my time helping developers and others new to accessibility both understand and implement accessible design, it has been my experience that the "normal and natural" definition of terms is what most people will initially apply to any of our SC, and so specificity is important here.

There is also a question of how this SC would be interpreted in a court of law, and while my example was deliberately controversial (and, I might add, pedantically correct using "normal and natural" definitions), it is also NOT outside the realm of reality in the wild, and the question posed (I anticipate) would be posed again by others, so at the very least we need to be prepared with the right (normative) answer: what we mean is that the value is selectable, and not "the user can select from a list ", else by definition this would meet the requirement:

Pick a number between 1 and 20:

Choices:

1 6 11 16

2 7 12 17

3 8 13 18

4 9 14 19

5 10 15 20

...which I do not think is the intent (or maybe it is?).

JF

On Thu, May 11, 2017 at 12:28 PM, Mike Gower notifications@github.com wrote:

the user can select from a list of valid input values.

@johnfoliot https://github.com/johnfoliot , I'd suggest that what you describe is not the user actually selecting from a list, so I'd say it failed. I take your point, but at some point we have to assume that clarity is provided in the Intent section and in the techniques.

I personally believe that we also have to assume a willingness by users to meet the intent. So, to take your example. Let's say that someone creates such an interaction and we deem it to pass. Is it well designed? Does it make sense? If folks want to create an awful user experience to try to circumvent a requirement, I don't think we can stop them. This is going to be especially true in many of the cognitive ones, where we are ultimately talking a lot more about design and UX considerations than we are about technical accessibility.

I support @mapluke https://github.com/mapluke's recent rewrite https://github.com/w3c/wcag21/issues/13#issuecomment-300769872, and think it is clear enough to invite further discussion. I'm repasting here, minus the example in the exception, which I think adds nothing. I've also pulled out the second part of the first exception, which seems to me to be redundant.

• Where only one member of a set of discrete data values is an acceptable input, the user can select from a list of those valid input values.
• Where numerical data can be manually entered, alternative separator characters are accepted.

Exceptions:

• Where the set of discrete data values is larger than thirty-one valid values.
• Where limiting input values to a set of discrete values interferes with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/13#issuecomment-300860126, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c7tcUhV2SSOVxX02hKGHI3OC20YYks5r40VSgaJpZM4J_16g .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

I find the difference between 'user can select from' and input value is "selectable" to be pretty thin -- and that the latter is a lot more awkward to describe in simple, clear language.

What I have done here is taken the word "set" from 4.1.2 ("values that can be set by the user can be programmatically set") to see if this addresses your concern. I've also added in the idea of 'without manual text entry' in an attempt to close this gap.

Where a value from a set of discrete data values is the acceptable input, the user can set a valid value without manually entering it.

Actually, two different meanings of "set" in one sentence if pretty bad. How about "choose":

Where a value from a set of discrete data values is the acceptable input, the user can choose a valid value without manually entering it.

[johnfoliot]

Getting really close. How about:

Where a value from a group of predefined, author-supplied data values is the acceptable input, the user can set a valid value without manually entering the specific value.

???

JF

On Thu, May 11, 2017 at 2:49 PM, Mike Gower notifications@github.com wrote:

I find the difference between 'user can select from' and input value is "selectable" to be pretty thin -- and that the latter is a lot more awkward to describe in simple, clear language.

What I have done here is taken the word "set" from 4.1.2 ("values that can be set by the user can be programmatically set") to see if this addresses your concern. I've also added in the idea of 'without manual text entry' in an attempt to close this gap.

Where a value from a set of discrete data values is the acceptable input, the user can set a valid value without manually entering it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/13#issuecomment-300898073, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-cxOZ2FXHHEit4IiSHehTTaQ4x8TOks5r42ZmgaJpZM4J_16g .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

My concern is that your update is a self-fulfilling SC now. 'Hey when you supply data values, let the user choose from them'

For language, I like "set" better than "group", but I can live with either. Besides that, what is the exact issue with the last version I posted?

To make this interesting, I also thought I'd go back to Lisa's earlier language and try to update, while adding on this idea of not manually entering data. Let me know if this is any better:

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 enter the value.

[johnfoliot]

Hi Mike,

At this point, sure, go with that and see what kind of feedback we receive in Round Two. (I note we've abandoned a limiting value, which was an issue brought up by James Nurthen... we had tossed around 50, 40, 31, etc. - are we disregarding this now?)

JF

On Thu, May 11, 2017 at 4:20 PM, Mike Gower notifications@github.com wrote:

My concern is that your update is a self-fulfilling SC now. 'Hey when you supply data values, let the user choose from them'

For language, I like "set" better than "group", but I can live with either. Besides that, what is the exact issue with the last version I posted?

To make this interesting, I also thought I'd go back to Lisa's earlier language and try to update, while adding on this idea of not manually entering data. Let me know if this is any better:

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 enter the value.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/13#issuecomment-300920328, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c89uIb0Cp8u04O4IMqk3zv84YJVAks5r43urgaJpZM4J_16g .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

I note we've abandoned a limiting value

Nope, still there in the exceptions...

• Where the set of discrete data values is larger than thirty-one valid values.
• Where limiting input values to a set of discrete values interferes with the main purpose of the content.
• Where alternative separator characters could alter the numeric value, such as substituting commas with periods.

[awkawk]

Can you email me the current version in full, or update it in the linked version at the top of the issue?

[mbgower]

@awkawk I emailed it to you about the time you were writing that :) I've made the pull request, but I do not have write access.

[jake-abma]

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 goes like this:

“The intent of this Success Criteria is to minimize user generated errors by detecting, and when reliable and possible, automatically correcting common input errors.”

Taking into account the previous comments on the text we end up with two possible options:

1. If a user provides input the content author must provide a suggestion list for a user to choose from (instead of auto-correct values)
2. Auto correct data formats if the input value is already in a correctly accepted form but not conform the required data format

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.

Let me elaborate on this:

First:

"Where a value from a set of discrete data values is the acceptable input, the user can select from a list of those valid input values."

On its own this doesn’t seem to cover any part of the intent. It reads like “do not provide a text input field when possible values are already known. Instead give the user a choice of preselected values”. This is not supplemental on what the user already manually entered for a input value (which may need some correction).

Also changing “discrete data” to “distinct data” may be more generally understood.

Second:

“Where numerical data can be manually entered, alternative separator characters are accepted.”

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).

Some conceptual re-thinking on the tekst seems appropriate.

[jake-abma]

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

[jake-abma]

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.

[DavidMacDonald]

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.

[mbgower]

@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.

[mbgower]

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.

[mbgower]

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...

[DavidMacDonald]

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.

[mbgower]

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?)

[mbgower]

@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.

[DavidMacDonald]

@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.

[jake-abma]

@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…”

[jake-abma]

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.

[mbgower]

@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

[mbgower]

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?

[johnfoliot]

Hi All,

Coming off 2 days of AccessU, and I'd like to re-examine something a bit closer (please). The current draft text states:

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.

There is a concern that this will be misinterpreted to suggest creating something like the following:

[image: Inline image 1] [alt="screen capture of a form asking for telephone number, and then there are 10 select combo boxes each with 0-9, so that the end-user "selects" the 10 digits to make up their phone number"]

...and so my question is, how do we avoid this?

Providing 10 discrete elements with the options of 0 through 9 in each , to thus complete providing a telephone number, is and would be both a literal reading of the requirement, as well as a literal "solution". Yet I'm fairly confident this is NOT what we want or are asking for (but I'm equally confident we're going to see stuff like this if we're not careful).

I'm not sure whether we need to modify the SC language, or address this in either the Understanding documents or the (Failure) Techniques document, but I did want to get this out on the table as a real and serious concern.

Thoughts?

JF

On Fri, May 19, 2017 at 9:11 AM, Mike Gower notifications@github.com wrote:

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 https://github.com/lseeman , @DavidMacDonald https://github.com/davidmacdonald made this suggestion in his prior comment https://github.com/w3c/wcag21/issues/13#issuecomment-302602932. is this worth following up on?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/13#issuecomment-302713307, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-czHd9-_BUeJtM7zMJSia5lWrOrg3ks5r7aL7gaJpZM4J_16g .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[jake-abma]

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).

[mbgower]

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?

[mbgower]

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?