EN ISO 9241-17:1998

SLOVENSKI STANDARD
01-junij-2001
Ergonomic requirements for office work with visual display terminals (VDTs) - Part
17: Form filling dialogues (ISO 9241-17:1998)
Ergonomic requirements for office work with visual display terminals (VDTs) - Part 17:
Form filling dialogues (ISO 9241-17:1998)
Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten - Teil 17:
Dialogführung mittels Bildschirmformularen (ISO 9241-17:1998)
Exigences ergonomiques pour travail de bureau avec terminaux a écrans de
visualisation (TEV) - Partie 17: Dialogues de type remplissage de formulaires (ISO 9241-
17:1998)
Ta slovenski standard je istoveten z: EN ISO 9241-17:1998
ICS:
13.180 Ergonomija Ergonomics
35.180 Terminalska in druga IT Terminal and other
periferna oprema IT peripheral equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL ISO
STANDARD 9241-17
First edition
1998-08-01
Ergonomic requirements for office work
with visual display terminals (VDTs) —
Part 17:
Form filling dialogues
Exigences ergonomiques pour travail de bureau avec terminaux à écrans
de visualisation (TEV) —
Partie 17: Dialogues de type remplissage de formulaires
A
Reference number
ISO 9241-17:1998(E)
ISO 9241-17:1998(E)
Contents Page
1 Scope . 1
2 Normative references . 2
3 Definitions . 2
4 Application of this part of ISO 9241. 3
4.1 Appropriateness of form filling dialogues . 3
4.2 Applying the recommendations. 4
4.3 Evaluation of products . 4
5 Form filling structure . 4
5.1 General . 4
5.2 Layout . 5
5.3 Fields and labels . 6
6 Input considerations . 7
6.1 General . 8
6.2 Alphanumeric text entry . 8
6.3 Choice entries . 9
6.4 Control . 11
6.5 Field validation . 12
7 Feedback . 13
7.1 Echoing. 13
7.2 Cursor and pointer position. 13
7.3 Field errors. 13
7.4 Transmission acknowledgement. 13
7.5 Database changes . 13
8 Navigation . 13
8.1 Initial cursor position . 13
8.2 Movement between fields . 13
8.3 Return to initial field. 14
8.4 Tabbing . 14
8.5 Scrolling . 15
8.6 Form selection . 15
©  ISO 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii
©
ISO ISO 9241-17:1998(E)
Annexes
A (informative) Sample procedure for assessing applicability
and adherence .
(informative)
B Bibliography .
iii
©
ISO 9241-17:1998(E) ISO
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national standards bodies (ISO member bodies). The work of
preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented
on that committee. International organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. ISO
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
International Standard ISO 9241 was prepared by Technical Committee
ISO/TC 159, Ergonomics, Subcommittee SC 4, Ergonomics of human-
system interaction.
ISO 9241 consists of the following parts, under the general title Ergonomic
requirements for office work with visual display terminals (VDTs):
— Part 1: General introduction
— Part 2: Guidance on task requirements
— Part 3: Visual display requirements
— Part 4: Keyboard requirements
— Part 5: Workstation layout and postural requirements
— Part 6: Guidance on the work environment
— Part 7: Display requirements with reflections
— Part 8: Requirements for displayed colours
— Part 9: Requirements for non-keyboard input devices
— Part 10: Dialogue principles
— Part 11: Guidance on usability
— Part 12: Presentation of information
— Part 13: User guidance
— Part 14: Menu dialogues
iv
©
ISO ISO 9241-17:1998(E)
— Part 15: Command dialogues
— Part 16: Direct manipulation dialogues
— Part 17: Form filling dialogues
Annexes A and B of this part of ISO 9241 are for information only.
v
©
ISO 9241-17:1998(E) ISO
Introduction
ISO 9241 is a multipart standard that deals with both the hardware and
software ergonomic aspects of the use of VDTs. The description of the
parts, their interrelationships, and a description of the expected users of
the parts is provided in ISO 9241-1:1992, Ergonomic requirements for
office work with visual display terminals (VDTs) — Part 1: General
introduction.
This part of ISO 9241 is concerned with the ergonomic design of form filling
dialogues. In form filling dialogues, users fill in, select entries for, or modify
labelled fields on an area of the screen display.
This part of ISO 9241 serves the following types of users:
a) The user interface designer, who will apply this part of ISO 9241 during
the development process.
b) The designer of printed forms which serve as source documents.
c) The buyer, who will reference this part of ISO 9241 during the product
procurement process.
d) Evaluators responsible for ensuring products meet the recommen-
dations in this part of ISO 9241.
e) Designers of user interface development tools to be used by interface
designers.
f) End users who will gain from the potential benefits provided by this part
of ISO 9241.
This part of ISO 9241 consists of a number of conditional recommen-
dations concerning form filling dialogues. Conditional recommendations are
recommendations which should be met only within the specific context for
which they are relevant (e.g, particular kinds of users, tasks, environments,
technology). These conditional recommendations were developed primarily
by reviewing the existing relevant literature and empirical evidence, then
generalizing and formulating this work into recommendations for use by the
interface designer and/or evaluator. Sources for the individual
recommendations are listed in Informative Annex B.
Designers using this part of ISO 9241 need to know that they are
developing an interface that will meet the recommendations provided in this
part. Likewise, buyers and evaluators need a means to determine how a
product matches the recommendations in this part of ISO 9241. It is not
intended that every recommendation should be applied, only those that are
relevant. Informative Annex A provides an example of a procedure for
evaluating the applicability of and adherence to the conditional
vi
©
ISO ISO 9241-17:1998(E)
recommendations provided in this part of ISO 9241. Design objectives are
provided prior to each of the major clauses to focus on the intent of the
recommendations within the clause.
The application of this part of ISO 9241 is expected to improve the overall
quality of the form filling dialogue, but this standard (like any other
standard) will not guarantee the quality of the interface. Quality depends on
specific usability criteria as set by the user, buyer or other form filling
dialogue consumer which may include specifications based on this part of
ISO 9241.
It should be noted that ISO 9241-10 describes dialogue principles that are
relevant for the design of form filling dialogues. These principles should
provide the designer and evaluator with additional information concerning
the ergonomic rationale for the various recommendations in this part of
ISO 9241 and, therefore, assist in making tradeoffs. However, it may be
necessary to base tradeoffs on other considerations as well.
vii
©
INTERNATIONAL STANDARD  ISO ISO 9241-17:1998(E)
Ergonomic requirements for office work with visual display
terminals (VDTs) —
Part 17:
Form filling dialogues
1  Scope
This part of ISO 9241 provides conditional recommendations on dialogue design, input design and output design for
computer dialogues in which form filling and dialogue boxes are used to accomplish typical office tasks. Form
filling dialogues are dialogues in which the user fills in, selects entries for, or modifies labelled fields on a "form" or
a dialogue box presented by the system. Often the system then creates, or updates the database associated with
the form. Form filling entries typically are in the form of typed input (abbreviations, or full names) or selections from
available option lists. This part of ISO 9241 pertains to form filling dialogues generated through both VDT character-
based and bit-mapped screen displays (often referred to as “GUIs”) and input through keyboards and optional
pointing devices (e.g. mice). In addition, this part includes the use of non-text methods for providing forms entries
(e.g. list boxes) and pertains to dialogue boxes which utilize form filling dialogue techniques. It should be noted that
some of the recommendations in this part of ISO 9241 are based on Western Language conventions. For other
languages, the recommendations may need to be modified to fit the readability considerations inherent in these
languages. These recommendations can be utilized throughout the development process (e.g., as guidance for
designers during design, as a basis for heuristic evaluation, as guidance for usability testing) and in the
procurement process.
Interface design depends upon the task, the user, the environment, and the available technology. Consequently,
this part of ISO 9241 cannot be applied without a knowledge of the design and use context of the interface and it is
not intended to be used as a prescriptive set of rules to be applied in their entirety (see ISO 9241-11). Rather, it
assumes that the designer has proper information available concerning task and user requirements and
understands the use of available technology (this may require consultation with a qualified ergonomics professional
as well as empirical testing with real users).
The recommendations relate to the three major design components of user interfaces, i.e., dialogue, input, and
output.
Dialogue design determines the way in which a user is guided by the system to make inputs and influences the
amount of control the user has over the dialogue. Form filling dialogues should be designed to support the user in
his/her actual work without creating additional work caused by system peculiarities as well as enabling the user to
become well-informed and to remain in control of the flow of work (also, see ISO 9241-10 which deals with dialogue
principles). Dialogue design is covered in this part of ISO 9241 in terms of designing form filling structures, providing
feedback mechanisms and providing appropriate navigation methods.
Input design is concerned with how input devices can be applied to facilitate the entry and modification of form
fields. One or more devices such as an alphanumeric keyboard, function keys, pointing devices and voice (other
devices are not excluded) can be provided depending on the task at hand and dialogue requirements, as well as on
individual preferences. This part of ISO 9241 provides conditional recommendations for text entry, choice entry, and
control using various input devices.
©
ISO
ISO 9241-17:1998(E)
Output design is concerned with how data is to be presented consistently and distinctly on the screen display. This
part of ISO 9241 provides conditional recommendations for the output design of form filling dialogues in terms of the
content and placement of fields and groups of fields (also see ISO 9241-12 for general information on the
presentation of information).
2  Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of
ISO 9241. At the time of publication, the editions indicated were valid. All standards are subject to revision, and
parties to agreements based on this part of ISO 9241 are encouraged to investigate the possibility of applying the
most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid
International Standards.
ISO 9241-2:1992, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 2: Guidance
on task requirements.
ISO 9241-10:1996, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 10:
Dialogue principles.
ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11:
Guidance on usability.
1)
ISO 9241-12:— , Ergonomic requirements for office work with visual display terminals (VDTs) — Part 12:
Presentation of information.
ISO 9241-13:1998, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 13: User
guidance.
ISO 9241-14:1997, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 14: Menu
dialogues.
1)
ISO 9241-16:— , Ergonomic requirements for office work with visual display terminals (VDTs) — Part 16: Direct
manipulation dialogues.
3  Definitions
For the purposes of this part of ISO 9241, the following definitions apply.
3.1  entry field: Type of field in a form in which data is entered. Entry fields may be optional fields or required
fields.
3.2  field: Area on a screen display in which data is entered or presented.
3.3  form: Structured display with labelled fields that the user reads, fills in, selects entries for (e.g., through choice
buttons or radio buttons), or modifies.

1)
To be published.
©
ISO
ISO 9241-17:1998(E)
3.4  label: Short descriptive title for an entry or read-only field, table, control or object. In some applications, labels
are classified as protected fields.
3.5  navigation: Ability to move from field to field within a form, to proceed forward and backward through a form
and move from form to form.
3.6  optional field: Field that not necessarily needs to be filled in or modified by the user.
3.7  protected field: Field that contains data that cannot be modified by the user. These fields are sometimes
called “read-only” fields.
3.8  required field: Field that must be completed by the user if it does not already have a value.
4  Application of this part of ISO 9241
4.1  Appropriateness of form filling dialogues
Form filling dialogues are appropriate for data entry tasks requiring input or modification of multiple data items. A
major use for form filling dialogues is the input of information into a computer from a paper source document.
Examples include: income tax returns, registration (school, motor vehicle), service order completion. Form filling
dialogues are very commonly used in specifying application options and parameters within a dialogue box. Another
use for form filling dialogues is for entering information received over the telephone (e.g. orders, reservations) into
the computer. Also, form filling dialogues are often appropriate for certain complex data retrieval requests where
users might find it easier to fill in parameter information than to input the parameters via a command language. It is
important to emphasize that these tasks can be the source of the emergence of monotonous repetitive work.
Users, buyers and producers of dialogue systems using form filling should take this into consideration. A way to
minimize the negative consequences of repetitive form filling tasks is to incorporate other tasks into the dialogue
system as well. (See ISO 9241-2) Form fields can be required or optional and/or can depict default values.
Form filling dialogues are especially appropriate for one or more of the following conditions, which have been
grouped to reflect user and task issues. The applicability of form filling dialogues becomes greater as more
conditions are met.
a) User characteristics
1) Users are experienced with paper forms but have limited experience with computers.
2) Users are familiar with the use of keyboard.
3) Users have moderate to good typing skills (for intensive use of data entry form filling dialogues).
b) Task requirements
1) It is not necessary to show a large set of alternatives.
2) Data must be input from a paper form.
3) Input data is gathered verbally from customers.
4) Unlimited flexibility of input is not required.
5) User’s input is dominated by parameter values rather than commands.
6) It is important to display default or current values/selections.
©
ISO
ISO 9241-17:1998(E)
4.2  Applying the recommendations
General ergonomic design objectives are provided in each of clauses 5 through 8. The individual recommendations
aimed at achieving these objectives are valid within the specific context for which they are relevant (e.g., particular
kinds of users, tasks, environments, technology). The format for the individual recommendations is: statement of the
recommendation, example (if appropriate), and notes (if appropriate). Examples provided for the various
recommendations generally depict an implementation that embodies the recommendation. Some examples also
indicate preferred solutions.
Individual recommendations should be evaluated for their applicability and, if judged to be applicable, should be
implemented in the relevant form filling dialogue unless there is evidence that to do so would cause deviation from
the design objectives or would result in an overall degradation in usability. When determining applicability, the
recommendations generally should be evaluated in the order presented in the relevant clause or subclause. In
judging whether applicable recommendations have been met, evaluators should evaluate the product or observe
representative users of the product in the context of accomplishing the user's tasks via the form filling dialogue
system. Sample procedures which support the determination of applicability and for determining whether a
recommendation has been followed are provided in Annex A.
4.3  Evaluation of products
If a product is claimed to have met the applicable recommendations in this part of ISO 9241, the procedure used in
establishing requirements for developing, and/or evaluating, the form filling dialogues shall be specified. The level of
specification of the procedure is a matter of negotiation between the involved parties.
Users of this part of ISO 9241 can either utilize the procedures provided in Annex A, or develop another procedure
tailored to their particular development and/or evaluation environment.
5  Form filling structure
Form filling dialogues should be designed such that the user enters information or data in a manner which is natural
to the user, without concern for how the computer will process the data or information. Form filling dialogues should
reflect the user's needs rather than the computer process, and the syntax structure should be consistent with user
expectations, task requirements and the input media. Users also should be able to easily determine the overall
structure of the form presented by the computer.
5.1  General
5.1.1  Titles
Forms, dialogue boxes and other entry screens should be titled (usually at the top) to clearly indicate their purpose
and to differentiate them from other forms. The title should be consistent with the command or selection item which
initiated its display.
5.1.2  Visual coding
If the task requires or is enhanced by discrimination between user entries, defaults, and previously entered data,
distinctively different visual coding should be used.
5.1.3  Form display density
Form filling dialogues should limit the density of the textual information displayed. For most applications, a limit of
40 % overall density, based on the percent of textual information displayed in relation to the total form space
1)
available, is recommended. (Also see ISO 9241-12:— , subclause 5.4.2.)

1)  To be published.
©
ISO
ISO 9241-17:1998(E)
5.1.4  Instructions
If casual or intermittent users may enter data on the form, instructions should be provided on the screen display (or
easily accessible through a "help" facility) for navigating through, completing, saving, and transmitting the form.
5.1.5  Overview of structure
If the form structure is complex, an overview of the form structure or a visual presentation of the structure should be
provided to users.
5.2  Layout
5.2.1  Paper document source
If a paper document is used as the source for computer input, the form filling dialogues screen should be designed
to be consistent with the structure of the paper source document in terms of item ordering, grouping, units for input
of values (e.g. mm or m), etc.
NOTE —  Compatibility with paper source documents is an important layout consideration. However, if the layout of the paper
source document is not compatible with efficient task performance, redesign of the source document is worthy of consideration.
If there are conflicting requirements between those filling in the paper forms (e.g. customers) and those filling in the computer
forms, it may be more important to ensure that those filling in the paper forms achieve the highest efficiency at the expense of
the computer input.
5.2.2  No source document
If form filling dialogues do not depend upon a source document, entry fields should be grouped by function,
1)
importance, etc. (see ISO 9241-12:— , subclause 5.6 “Groups”) or optimized, based on input sequences from the
user's point of view.
NOTE —  If data is supplied by a customer, the sequence could depend on customer needs (for example, in a telephone sales
transaction). In some cases, the form presented can be modified dynamically, to guide the user, depending on the initial input
provided.
5.2.3  Required fields and optional fields
If the form contains both required fields and optional fields within a functional or logical grouping of fields, required
fields should be positioned first unless such positioning is inappropriate to the user's task (e.g. it would not be
consistent with a paper source document).
NOTE —  It also can be appropriate to establish the tabbing order to go through the required fields prior to the optional fields.
5.2.4  Alphanumeric field alignment
If appropriate to the language context, alphanumeric entry fields should be aligned vertically in columns and left-
justified within each column.
NOTE —  This will improve visual scanning and often minimizes the keystrokes required to move between fields.
5.2.5  Numerical field alignment
If groups of entry fields are all numeric and the field lengths are different, these fields should be displayed right-
justified. If numerical fields contain decimal points, they should be aligned to the decimal point.

1)  To be published.
©
ISO
ISO 9241-17:1998(E)
5.2.6  Allowable field values
Information should be provided indicating allowable field values (i.e., either display the information on the form or on
demand).
5.2.7 Differing label lengths
If text or alphanumeric fields are aligned vertically in columns, and if label lengths could differ significantly and the
task involves sequential data entry, labels should be right-justified and fields should be left-justified.
EXAMPLE —
Name: ________________________________
Birth Date: __/__/__
Occupation: __________________________
Sex: _ (M/F)
5.2.8  Similar label lengths
If text or alphanumeric fields are aligned vertically in columns and if field label lengths do not differ significantly, field
labels and fields may both be left-justified.
EXAMPLE —
Name: __________________________________
Age: ___
Sex: _ (M/F)
School: _______________________
5.2.9  Multiple instances of a field
If a label is used for multiple instances of a field (e.g. table), the label should be located above the column, or to the
left of the row.
5.2.10  Multiple pages
a) If a multiple page form must be used, each page should be identified consistently in the same part of the form
or window title area and should be in a format to ensure that the location of the page within the whole form is
apparent.
EXAMPLE — "Page 1 of 3" shown close to the title at the top of the form.
b) If the form is columnar, the labels of the columns should be redisplayed.
5.3  Fields and labels
It should be noted that many of the recommendations stated below also are covered generically in ISO 9241-12.
5.3.1  Fixed length fields
If the text entry fields are of fixed length, lengths should be explicitly shown.
EXAMPLE 1 — For non-proportional fonts, an underscore character is presented for each character that needs to
be entered by the user.
EXAMPLE 2 — For proportional fonts, a string of alpha characters is presented to depict the exact length of the
field.
©
ISO
ISO 9241-17:1998(E)
5.3.2  Required versus optional field entries
Required and optional entry fields should be presented so that the differences between them should be immediately
perceptible to any user.
EXAMPLE 1 — Underscores are used for required entries and periods for optional entries.
EXAMPLE 2 — Required entry fields have a border around them, while optional entry fields do not.
EXAMPLE 3 — Different colours or shades are used to distinguish required and optional fields, with colours that are
distinguishable on a monochrome display.
NOTE —  It is important that optional and required entry coding be distinguishable from "read-only” fields.
5.3.3  Modifiable versus non-modifiable fields
Users should be able to easily distinguish between fields that can be modified and those that cannot (“read-only”
1)
fields) by appropriate coding (see ISO 9241-12:— , subclause 5.10.1).
5.3.4  Descriptive field labels
All fields should be clearly and unambiguously labelled to describe what kind of content should be entered.
5.3.5  Distinctive labels
Distinctive words and/or codes (e.g., position, border, font, colour) should be used for entry-field labels, and the
approach used should be applied consistently throughout the form, so that entry fields will not be confused with
1)
data, instructions, etc. (see ISO 9241-12:— , subclause 5.9.2).
5.3.6  Symbols or units
Symbols or units ($, ƒ, %, mph, cm, l, etc.) should be displayed as an additional label when it is required by the user
1)
for interpretation of the data in an entry field. (Also see ISO 9241-12:— , subclause 5.9.9.)
NOTE —  The symbol or unit can be added to the column label in the case of a column of fields.
5.3.7  Cues
Cues for data entry format (e.g. for a time duration “hh:mm:ss”) should be displayed within the entry field or in field
labels. If abbreviated values are used, it should be clear to the user what the abbreviations mean (e.g. Y/N, for Yes
or No).
5.3.8  Initial upper-case (capital) letter for field labels
To facilitate readability, text field labels should begin with an upper-case letter. The rest of the label should contain
lower-case (small) letters, except for cases where the label is a logo, an acronym, or language convention requires
each word in the label to begin with a capital letter.
6  Input considerations
User input considerations include: user control of the dialogue at all times, the capability for users to recover easily
from errors, and the avoidance of requiring users to input more information than is necessary for successful task
performance or to input information that is already currently available in the system.

1)  To be published.
©
ISO
ISO 9241-17:1998(E)
6.1  General
6.1.1  Cursor movement
The user actions required to move the cursor from one entry field to the next should be minimized.
EXAMPLE — A tab key is used to jump from field to field.
6.1.2  Incomplete text entry field
If the (required) number of characters entered into the field does not fill the whole field, the user should be allowed
to move directly to the next field (i.e., do not require the user to enter blank spaces to complete the field).
6.1.3  Default values
a) Fields should contain default values wherever possible and appropriate to the task. (Also see clause 5.1.2.)
b) Text default field values should be editable by the user using conventional editing commands.
6.1.4  Switching between input devices
If appropriate to the task, the need for users to switch between different input devices when filling in a form should
be minimized.
EXAMPLE 1 — Fields that require text entry within a logical group on a form are grouped separately from those
that can be completed with a pointing device.
EXAMPLE 2 — Multiple data entry methods are available for use in the same field where appropriate.
EXAMPLE 3 — Navigation to all form fields with all input devices is provided for a given form.
6.1.5  Pointing devices
If a pointing device can be used for input in a form, it should be usable for navigation as well.
6.2  Alphanumeric text entry
6.2.1  Justification of entries
If the entries need to be justified within the field, the system (not the user) should do the justification.
6.2.2  Leading zeros
If leading zeros are needed for numeric entries, the system (not the user) should provide the leading zeros.
6.2.3  Multiple lines
If the field contains multiple lines of text, i.e., sentence or a paragraph:
a) Input area size — The size of the multi-line input area should be clearly indicated.
EXAMPLE — Borders are placed around the text area as shown below:
Data entry in this area is bounded by the
border of the field.
The text entry area cannot exceed this area.
©
ISO
ISO 9241-17:1998(E)
b) Auto wrap — An auto-wrap capability should be provided and individual words should not be broken.
c) Editing and navigation — Normal text navigation and editing conventions should be used.
6.2.4  Mutually exclusive fields
If fields are mutually exclusive, a visual cue should be provided to indicate that only one of the fields may be used.
EXAMPLE — Radio buttons in a dialogue box or the use of the word “or”.
6.2.5  Interdependency rules
The use of complex "if/then" interdependency rules among entry fields should be avoided (e.g. if "Y" is entered in
field 1, then fields 2 and 4 must be left blank; if "N" is entered in field 1, then field 2 should contain -----, etc.) or they
should automatically be handled by the system by constraining user choices and visible fields.
NOTE —  If interdependencies between fields are necessary, consider providing automatic movement through the required
completion sequence by the system and consider visually coding fields available for input due to interdependencies.
6.2.6  Text entry field area
Each text field should be large enough to accommodate the majority of anticipated entries without scrolling.
6.3  Choice entries
Choice entries are typically grouped into the following categories:
— Exclusive choice (a group of choices in which only one choice can be selected at a time).
— Binary choice (a choice between two state settings, e.g., on/off, activated/deactivated).
— Non-exclusive choice (a group of choices in which more than one choice can be selected, i.e. the choices are
independent of each other).
6.3.1  Limited entry options
If the number of acceptable entry options is limited and predetermined, a mechanism should be provided to enable
the user to view and select available options.
EXAMPLE 1 — Providing pop-up menus or list boxes.
EXAMPLE 2 — The use of soft machine controls, which are graphical representations having an explicit or
historical analogy to hardware controls or other entities (e.g. buttons, sliders, radio buttons, check
boxes).
6.3.2  Discriminable visual cues
Discriminable visual cues should be used to discriminate among different logical types of choice entries in an
application.
EXAMPLE 1 — Circles are used to indicate exclusive choices (e.g. radio buttons) and square boxes (e.g.
checkboxes) are used to indicate non-exclusive choices.
EXAMPLE 2 — Diamonds are used to indicate exclusive choices and square boxes are used to indicate non-
exclusive choices.
EXAMPLE 3 — Touching rectangles are used to indicate exclusive choice and separate rectangles are used to
indicate non-exclusive choices.
©
ISO
ISO 9241-17:1998(E)
6.3.3  Menus
If the user must select an entry option from a known set of options, a menu should be considered as the entry
technique. When a menu is used:
a) Visual cues — A visual cue that a menu is associated with the field should be provided (e.g., an arrow in the
field label or in the button surrounding the data value) unless the list of menu options is continuously visible.
EXAMPLE —
red
Colour: red  yellow
blue
green
NOTE —  Visual cues can be omitted if all of the fields have this characteristic (see ISO 9241-14).
b) Field value — The form field should present the most recent selection from the menu as the current value for
the field.
6.3.4  Lists
If the user must select one or more entries from a large and/or variable set of values, or if users can customize a
list, the use of non-scrolling or scrolling lists should be considered. When lists are used:
a) Visual cues — A visual cue should be provided that allows users to discriminate selected from non-selected
values.
EXAMPLE — Check marks or highlighting of selected values.
b) Long lists — If a list is extremely long, it should be presented in the appropriate logical order (e.g. alphabetical,
numeric, date order) and a mechanism should be provided so that users can rapidly navigate through the list.
EXAMPLE 1 — Users are allowed to skip to parts of a list by typing in the initial letter(s) of list items.
EXAMPLE 2 — Users can use a direct manipulation device to quickly access items on a list.(See ISO 9241-16.)
6.3.5  Screen buttons
If the user must select a small number of values (2 to 5) and the values become effective immediately after
selection, the use of screen buttons (see ISO 9241-14:1997, Definition 3.26) should be considered. (Also see
ISO 9241-16.)
6.3.6  Choice buttons
If the user must select among an exclusive set of choices, choice buttons that change appearance depending on
their state should be considered (e.g. "radio buttons").
a) Exclusive choice buttons should be presented in sets of 2 or more choices.
Sets of choices —
b) Default choice — If there is a default for the field, the default choice in the set should be visibly selected when
the field is first presented or an alternative has not been selected.
©
ISO
ISO 9241-17:1998(E)
6.3.7  Binary state settings
If the user must choose among multiple binary state settings, and sufficient display space is available, the use of
binary state buttons (check boxes, state boxes) that change appearance when selected (e.g. appear filled, or
contain an 'X' or check mark or other graphic) should be considered.
a) Group presentation — Binary state buttons related to a task should be presented in a group rather than as
individual items.
b) Indication of state — When the form is presented, binary state buttons should provide a visual indication of
their current state.
6.3.8  Stepper buttons
If the user must select one or more entries and display space is limited and/or the options need not be changed
frequently, the use of stepper buttons (e.g. cycle buttons, spin buttons) that cycle through a list of choices may be
considered.
EXAMPLE — A box displaying a choice and arrow buttons used to step through the choices.
If stepper buttons are used:
a) Displayed initial choice — The initially displayed choice should be the most appropriate default choice.
b) Typing values — Users should be allowed to type in values in order to quickly set a value.
6.4  Control
6.4.1  Corrections before processing
The user should be allowed to go back to the initial state of the form at any time and start over again, cancel entries,
or change any entry before the form is processed by the computer.
6.4.2  Identifying and locating errors
a) If validation checking of multiple fields detects fields in error and if appropriate to the task, these fields should be
indicated and the cursor should be placed on the first field in error and the user should be allowed to easily
1)
move through the fields in error in order to correct the entries. (Also see ISO 9241-13:— , subclause 9.4.5.)
EXAMPLE — All fields in error are highlighted by the reverse video display of these fields.
b) If there are dependencies between fields, and if it is appropriate to the task, potential errors resulting from such
dependencies should be indicated.
6.4.3  Re-entering data
If the field contains an error, the user should be required only to correct the erroneous part of the input. (Also see
1)
ISO 9241-13:— , subclause 9.4.4.)
6.4.4  Unavailable areas
Areas of the screen display not available for user input (e.g. read-only fields) should not be accessible by the user
(i.e., the user should not be able to place the cursor in those areas) and these areas should have visual cues
indicating that they cannot be accessed.

1) To be published.
©
ISO
ISO 9241-17:1998(E)
6.4.5  Easy transmission
If transmission of the form is required, the transmission of the field entries to the computer to be processed should
be accomplished by means of a simple explicit action.
NOTE —  It is important that the transmission action takes place no matter where the cursor is currently located on the form
(i.e. the user is not required to navigate to a particular field in order to use the transmission control key[s]).
6.4.6  User control
Unless it is obvious to the user, the form should state how to carry out the following actions, if provided:
 signal completion of the form and redisplay an empty form (with default values, if appropriate) for the entry of
new data;
 signal completion of the form and redisplay the previously completed version of the form or a default version
(template) of the form;
 escape from the form without changing any data in the system, e.g., by means of the "Escape" or "Cancel"
function;
use "undo".

6.4.7  Temporary save
If appropriate to the task and if system constraints allow it, a temporary save function should be provided so that
users can leave the form temporarily (because the required item of data is not available, for example) and return to
it later without having to re-enter all the data on the form.
NOTE —  If a temporary save function is provided, when the form is re-selected and there is already a put-aside form of that
type (from a previous save), it is beneficial to provide users with the option of continuing with the saved form or starting a new
form.
6.5  Field validation
6.5.1  Single field validation
If system capabilities are available, the data entry system should check the entry in each field before accepting it,
based on criteria defined for that field individually. If values in a field are defined from a predefined range or list, the
editing criteria should simply verify that the entry matches some item in the predefined range or list.
6.5.2  Multiple field validation
If there are dependencies between fields on a form, or between the field on other incidents of the same form, the
following additional validation checks may be considered:
a) Data already entered in other fields of the same form.
EXAMPLE — The user is not allowed to enter data in the field “Age of child?” if the entry in the field “Children?”
is “None” (see also 6.2.5).
b) Data already entered in the same field in other forms.
EXAMPLE — A field is a “key field” and is required to be unique. The system checks to make sure this value
has not been used before on another instance of the form.
©
ISO
ISO 9241-17:1998(E)
7  Feedback
Users need to be provided with information allowing them to control the dialogue, recognize errors, and determine
their next course of action.
7.1  Echoing
Typed-in characters should be echoed back to the user, character by character, as entered.
NOTE —  In some cases, echoing may be undesirable (e.g., during the entry of a password, non-identifiable characters such
as “ ” would be echoed back to the user instead of the actual characters typed).
.....
7.2  Cursor and pointer position
Cursor position should always be clearly visible if it is within the currently displayed portion of the form.
If a pointing device is available, the position of the pointer should always be clearly visible to the user (see
1)
ISO 9241-16:— , subclause 6.2.13).
7.3  Field errors
If a field contains an error and, if it is appropriate to the task and within the system’s capabilities, error feedback
should be provided as soon as the user completes the field (e.g., by highlighting the error, or by pro
...