HTML 4.01 Test Suite - Assertions

Testable Assertions: Section 17 Forms


Valid HTML 4.01!


17 Forms - User-input Forms: Text Fields, Buttons, Menus, and more

Assertion 17.2-1

Reference: Section 17.2
(may) Control has both an initial value and a current value, both of which are character strings. the control's current value may be modified through user interaction and scripts.
Tests: None

Assertion 17.2-2

Reference: Section 17.2
(must) A control's initial value does not change. Thus, when a form is reset, each control's current value is reset to its initial value.
Tests: None

Assertion 17.2-3

Reference: Section 17.2
(must) When a form is submitted for processing, some controls have their name paired with their current value and these pairs are submitted with the form.
Tests: None

Assertion 17.2.1-1

Reference: Section 17.2.1
(must) A user agent may support buttons. Authors may create three types of buttons with the BUTTON element or the INPUT element: 1, submit buttons: When activated, a submit button submits a form. 2. reset buttons: When activated, a reset button resets all controls to their initial values. 3. push buttons: Push buttons have no default behavior. Each push button may have client-side scripts associated with the element's event attributes.
Tests: None

Assertion 17.2.1-2

Reference: Section 17.2.1
(must) A user agent must support checkboxes. Checkboxes and radio buttons are on/off switches that may be toggled by the user. A switch is "on" when the control element's checked attribute is set. When a form is submitted, only "on" checkbox controls can become successful.
Tests: None

Assertion 17.2.1-3

Reference: Section 17.2.1
(must) Several checkboxes in a form may share the same control name. Thus, for example, checkboxes allow users to select several values for the same property. The INPUT element is used to create a checkbox control.
Tests: None

Assertion 17.2.1-4

Reference: Section 17.2.1
(must) A user agent must support radio buttons. Radio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive. When one is switched "on", all others with the same name are switched "off". The INPUT element is used to create a radio button control. If no radio button in a set sharing the same control name is initially "on", user agent behavior for choosing which control is initially "on" is undefined.
Tests: None

Assertion 17.2.1-5

Reference: Section 17.2.1
(must) A user agent must suport menus. Menus offer users options from which to choose. The SELECT element creates a menu, in combination with the OPTGROUP and OPTION elements.
Tests: None

Assertion 17.2.1-6

Reference: Section 17.2.1
(must) A user agent must support text input. Authors may create two types of controls that allow users to input text. The INPUT element creates a single-line input control and the TEXTAREA element creates a multi-line input control. In both cases, the input text becomes the control's current value.
Tests: None

Assertion 17.2.1-7

Reference: Section 17.2.1
(must) A user agent must support file select. This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control.
Tests: None

Assertion 17.2.1-8

Reference: Section 17.2.1
(must) A user agent must support hidden control. This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create file select control.
Tests: None

Assertion 17.2.1-9

Reference: Section 17.2.1
(must) A user agent must support object control. Authors may insert generic objects in forms such that associated values are submitted along with other controls. Authors create object controls with the OBJECT element.
Tests: None

Assertion 17.3-1

Reference: Section 17.3
(author)(must) FORM: Start tag: required, End tag: required.
Tests: None

Assertion 17.3-2

Reference: Section 17.3
(must) FORM:action = uri [CT] This attribute specifies a form processing agent. User agent behavior for a value other than an HTTP URI is undefined.
Tests: None

Assertion 17.3-3

Reference: Section 17.3
(must) FORM:method = get|post [CI] This attribute specifies which HTTP method will be used to submit the form data set. Possible (case-insensitive) values are "get" (the default) and "post".
Tests: None

Assertion 17.3-4

Reference: Section 17.3
(must) FORM:enctype = content-type [CI] This attribute specifies the content type used to submit the form to the server (when the value of method is "post"). The default value for this attribute is "application/x-www-form-urlencoded". The value "multipart/form-data" should be used in combination with the INPUT element, type="file".
Tests: None

Assertion 17.3-5

Reference: Section 17.3
(must) FORM:accept-charset = charset list [CI] This attribute specifies the list of character encodings for input data that is accepted by the server processing this form. The value is a space- and/or comma-delimited list of charset values.
Tests: None

Assertion 17.3-6

Reference: Section 17.3
(must) FORM:accept = content-type-list [CI] This attribute specifies a comma-separated list of content types that a server processing this form will handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server.
Tests: None

Assertion 17.3-7

Reference: Section 17.3
(must) FORM:name = cdata [CI] This attribute names the element so that it may be referred to from style sheets or scripts.
Tests: None

Assertion 17.3-8

Reference: Section 17.3
(must) The FORM element acts as a container for controls. It specifies: 1. The layout of the form (given by the contents of the element). 2. The program that will handle the completed and submitted form (the action attribute). The receiving program must be able to parse name/value pairs in order to make use of them. 3. The method by which user data will be sent to the server (the method attribute). 4. A character encoding that must be accepted by the server in order to handle this form (the accept-charset attribute).
Tests: None

Assertion 17.4-1

Reference: Section 17.4
(author)(must) INPUT: Start tag: required, End tag: forbidden
Tests: None

Assertion 17.4-2

Reference: Section 17.4
(must) INPUT:type = text|password|checkbox|radio|submit|reset|file|hidden|image|but ton [CI] This attribute specifies the type of control to create. The default value for this attribute is "text".
Tests: None

Assertion 17.4-3

Reference: Section 17.4
(must) INPUT:name = cdata [CI] This attribute assigns the control name.
Tests: None

Assertion 17.4-4

Reference: Section 17.4
(must) INPUT:value = cdata [CA] This attribute specifies the initial value of the control. It is optional except when the type attribute has the value "radio" or "checkbox".
Tests: None

Assertion 17.4-5

Reference: Section 17.4
(must) INPUT:size = cdata [CN] This attribute tells the user agent the initial width of the control. The width is given in pixels except when type attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters.
Tests: None

Assertion 17.4-6

Reference: Section 17.4
(must) INPUT:maxlength = number [CN] When the type attribute has the value "text" or "password", this attribute specifies the maximum number of characters the user may enter. This number may exceed the specified size, in which case the user agent should offer a scrolling mechanism. The default value for this attribute is an unlimited number.
Tests: None

Assertion 17.4-7

Reference: Section 17.4
(must) INPUT:checked [CI] When the type attribute has the value "radio" or "checkbox", this boolean attribute specifies that the button is on. User agents must ignore this attribute for other control types.
Tests: None

Assertion 17.4-8

Reference: Section 17.4
(must) INPUT:src = uri [CT] When the type attribute has the value "image", this attribute specifies the location of the image to be used to decorate the graphical submit button.
Tests: None

Assertion 17.4.1-1

Reference: Section 17.4.1
(must) INPUT type = text Creates a single-line text input control.
Tests: None

Assertion 17.4.1-2

Reference: Section 17.4.1
(must) INPUT type = password Like "text", but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks).
Tests: None

Assertion 17.4.1-3

Reference: Section 17.4.1
(must) INPUT type = checkbox Creates a checkbox.
Tests: None

Assertion 17.4.1-4

Reference: Section 17.4.1
(must) INPUT type = radio Creates a radio button.
Tests: None

Assertion 17.4.1-5

Reference: Section 17.4.1
(must) INPUT type = submit Creates a submit button.
Tests: None

Assertion 17.4.1-6

Reference: Section 17.4.1
(must) INPUT type = image Creates a graphical submit button. The value of the src attribute specifies the URI of the image that will decorate the button. For accessibility reasons, authors should provide alternate text for the image via the alt attribute. When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
Tests: None

Assertion 17.4.1-7

Reference: Section 17.4.1
(must) INPUT type = reset Creates a reset button.
Tests: None

Assertion 17.4.1-8

Reference: Section 17.4.1
(must) INPUT type = button Creates a push button. User agents should use the value of the value attribute as the button's label.
Tests: None

Assertion 17.4.1-9

Reference: Section 17.4.1
(must) INPUT type = hidden Creates a hidden control.
Tests: None

Assertion 17.4.1-10

Reference: Section 17.4.1
(must) INPUT type = file Creates a file select control. User agents may use the value of the value attribute as the initial file name.
Tests: None

Assertion 17.5-1

Reference: Section 17.5
(must) BUTTON: Start tag: required, End tag: required.
Tests: None

Assertion 17.5-2

Reference: Section 17.5
(must) BUTTON:name = cdata [CI] This attribute assigns the control name.
Tests: None

Assertion 17.5-3

Reference: Section 17.5
(must) BUTTON:value = cdata [CS] This attribute assigns the initial value to the button.
Tests: None

Assertion 17.5-4

Reference: Section 17.5
(must) BUTTON:type = submit|button|reset [CI] This attribute declares the type of the button. Possible values: 1. submit: Creates a submit button. This is the default value. 2. reset: Creates a reset button. 3. button: Creates a push button.
Tests: None

Assertion 17.5-5

Reference: Section 17.5
(informative) Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content.
Tests: None

Assertion 17.5-6

Reference: Section 17.5
(may) Visual user agents may render BUTTON buttons with relief and an up/down motion when clicked, while they may render INPUT buttons as "flat" images.
Tests: None

Assertion 17.6-1

Reference: Section 17.6
(author)(must) SELECT: Start tag: required, End tag: required
Tests: None

Assertion 17.6-2

Reference: Section 17.6
(must) SELECT:name = cdata [CI] This attribute assigns the control name.
Tests: None

Assertion 17.6-3

Reference: Section 17.6
(must) SELECT:size = number [CN] If a SELECT element is presented as a scrolled list box, this attribute specifies the number of rows in the list that should be visible at the same time.
Tests: 17_6-BF-01.html

Assertion 17.6-4

Reference: Section 17.6
(must) SELECT:multiple [CI] If set, this boolean attribute allows multiple selections. If not set, the SELECT element only permits single selections.
Tests: None

Assertion 17.6-5

Reference: Section 17.6
(must) The SELECT element creates a menu. Each choice offered by the menu is represented by an OPTION element. A SELECT element must contain at least one OPTION element. The OPTGROUP element allows authors to group choices logically.
Tests: None

Assertion 17.6.1-1

Reference: Section 17.6.1
(must) Zero or more choices may be pre-selected for the user. User agents should determine which choices are pre-selected as follows: 1. If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined. The initial state has the first option selected, unless a SELECTED attribute is present on any of the OPTION elements. 2. If one OPTION element has the selected attribute set, it should be pre-selected. 3. If the SELECT element has the multiple attribute set and more than one OPTION element has the selected attribute set, they should all be pre-selected. 4. It is considered an error if more than one OPTION element has the selected attribute set and the SELECT element does not have the multiple attribute set. User agents may vary in how they handle this error, but should not pre-select more than one choice.
Tests: 17_6_1-BF-01.html

Assertion 17.6.1-2

Reference: Section 17.6.1
(author)(must) OPTGROUP: Start tag: required, End tag: required
Tests: None

Assertion 17.6.1-3

Reference: Section 17.6.1
(must) OPTGROUP:label = text [CS] This attribute specifies the label for the option group.
Tests: None

Assertion 17.6.1-4

Reference: Section 17.6.1
(author)(must) OPTION: Start tag: required, End tag: optional
Tests: None

Assertion 17.6.1-5

Reference: Section 17.6.1
(must) OPTION:selected [CI] When set, this boolean attribute specifies that this option is pre-selected.
Tests: None

Assertion 17.6.1-6

Reference: Section 17.6.1
(must) OPTION:value = cdata [CS] This attribute specifies the initial value of the control. If this attribute is not set, the initial value is set to the contents of the OPTION element.
Tests: None

Assertion 17.6.1-7

Reference: Section 17.6.1
(must) OPTION:label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label.
Tests: None

Assertion 17.6.1-8

Reference: Section 17.6.1
(should) When rendering a menu choice, user agents should use the value of the label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element.
Tests: None

Assertion 17.7-1

Reference: Section 17.7
(author)(must) TEXTAREA: Start tag: required, End tag: required
Tests: None

Assertion 17.7-2

Reference: Section 17.7
(must) TEXTAREA:name = cdata [CI] This attribute assigns the control name.
Tests: None

Assertion 17.7-3

Reference: Section 17.7
(must) TEXTAREA:rows = number [CN] This attribute specifies the number of visible text lines.
Tests: 17_7-BF-01.html

Assertion 17.7-4

Reference: Section 17.7
(must) TEXTAREA:cols = number [CN] This attribute specifies the visible width in average character widths.
Tests: 17_7-BF-02.html

Assertion 17.7-5

Reference: Section 17.7
(should) The TEXTAREA element creates a multi-line text input control. User agents should use the contents of this element as the initial value of the control and should render this text initially.
Tests: None

Assertion 17.8-1

Reference: Section 17.8
(must)(deprecated) ISINDEX is deprecated. This element creates a single-line text input control. Authors should use the INPUT element to create text input controls.
Tests: None

Assertion 17.8-2

Reference: Section 17.8
(must)(deprecated) ISINDEX: prompt = text [CS]. This attribute specifies a prompt string for the input field.
Tests: None

Assertion 17.9-1

Reference: Section 17.9
(should) Some form controls automatically have labels associated with them (press buttons) while most do not (text fields, checkboxes and radio buttons, and menus).For those controls that have implicit labels, user agents should use the value of the value attribute as the label string. The LABEL element is used to specify labels for controls that do not have implicit labels.
Tests: None

Assertion 17.9.1-1

Reference: Section 17.9.1
(author)(must) LABEL: Start tag: required, End tag: required
Tests: None

Assertion 17.9.1-2

Reference: Section 17.9.1
(must) LABEL:for = idref [CS] This attribute explicitly associates the label being defined with another control. When present, the value of this attribute must be the same as the value of the id attribute of some other control in the same document. When absent, the label being defined is associated with the element's contents.
Tests: None

Assertion 17.9.1-3

Reference: Section 17.9.1
(must) Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.
Tests: None

Assertion 17.9.1-4

Reference: Section 17.9.1
(must) To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.
Tests: None

Assertion 17.9.1-5

Reference: Section 17.9.1
(must) When a LABEL element receives focus, it passes the focus on to its associated control
Tests: None

Assertion 17.10-1

Reference: Section 17.10
(author)(must) FIELDSET and LEGEND: The start tag and end tag are required.
Tests: None

Assertion 17.10-2

Reference: Section 17.10
(must)(deprecated) LEGEND:align = top|bottom|left|right [CI] Deprecated. This attribute specifies the position of the legend with respect to the fieldset. Possible values:
Tests: None

Assertion 17.10-3

Reference: Section 17.10
(informative) The FIELDSET element allows authors to group thematically related controls and labels. The LEGEND element allows authors to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually.
Tests: None

Assertion 17.11-1

Reference: Section 17.11
(must) In an HTML document, an element must receive focus from the user in order to become active and perform its tasks.
Tests: None

Assertion 17.11-2

Reference: Section 17.11
(informative) There are several ways to give focus to an element: 1. Designate the element with a pointing device. 2. Navigate from one element to the next through tabbing order. 3. Select an element through an access key (sometimes called "keyboard shortcut" or "keyboard accelerator").
Tests: None

Assertion 17.11.1-1

Reference: Section 17.11.1
(must) CONTROL:tabindex = number [CN] This attribute specifies the position of the current element in the tabbing order for the current document. This value must be a number between 0 and 32767. User agents should ignore leading zeros.
Tests: 17_11_1-BF-01.html

Assertion 17.11.1-2

Reference: Section 17.11.1
(should) Elements that may receive focus should be navigated by user agents according to the following rules: 1. Those elements that support the tabindex attribute and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tabindex values should be navigated in the order they appear in the character stream. 2. Those elements that do not support the tabindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream. 3. Elements that are disabled do not participate in the tabbing order.
Tests: None

Assertion 17.11.1-3

Reference: Section 17.11.1
(must) The following elements support the tabindex attribute: A, AREA, BUTTON, INPUT, OBJECT, SELECT, and TEXTAREA.
Tests: None

Assertion 17.11.2-1

Reference: Section 17.11.2
(must) CONTROL:accesskey = character [CN] This attribute assigns an access key to an element. An access key is a single character from the document character set.
Tests: None

Assertion 17.11.2-2

Reference: Section 17.11.2
(must) Pressing an access key assigned to an element gives focus to the element. The following elements support the accesskey attribute: A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.
Tests: None

Assertion 17.12-1

Reference: Section 17.12
(should) In contexts where user input is either undesirable or irrelevant, it is important to be able to disable a control or render it read-only.
Tests: None

Assertion 17.12.1-1

Reference: Section 17.12.1
(must) CONTROL:disabled [CI] When set for a form control, this boolean attribute disables the control for user input.
Tests: 17_12_1-BF-01.html

Assertion 17.12.1-2

Reference: Section 17.12.1
(should) When set, the disabled attribute has the following effects on an element: 1. Disabled controls do not receive focus. 2. Disabled controls are skipped in tabbing navigation. 3. Disabled controls cannot be successful.
Tests: None

Assertion 17.12.1-3

Reference: Section 17.12.1
(must) The following elements support the disabled attribute: BUTTON, INPUT, OPTGROUP, OPTION, SELECT, and TEXTAREA.
Tests: None

Assertion 17.12.1-4

Reference: Section 17.12.1
(must) The only way to modify dynamically the value of the disabled attribute is through a script.
Tests: None

Assertion 17.12.2-1

Reference: Section 17.12.2
(must) CONTROL:readonly [CI] When set for a form control, this boolean attribute prohibits changes to the control.
Tests: None

Assertion 17.12.2-2

Reference: Section 17.12.2
(must) When set, the readonly attribute has the following effects on an element: 1. Read-only elements receive focus but cannot be modified by the user. 2. Read-only elements are included in tabbing navigation. 3. Read-only elements may be successful.
Tests: None

Assertion 17.12.2-3

Reference: Section 17.12.2
(must) The following elements support the readonly attribute: INPUT and TEXTAREA.
Tests: None

Assertion 17.12.2-4

Reference: Section 17.12.2
(must) The only way to modify dynamically the value of the readonly attribute is through a script.
Tests: None

Assertion 17.13.1-1

Reference: Section 17.13.1
(author)(should) The method attribute of the FORM element specifies the HTTP method used to send the form to the processing agent. This attribute may take two values: "get" and "post". The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Otherwise "post" method should be used.
Tests: None

Assertion 17.13.2-1

Reference: Section 17.13.2
(may) A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set. A successful control must be defined within a FORM element and must have a control name. However: 1. Controls that are disabled cannot be successful. 2. If a form contains more than one submit button, only the activated submit button is successful. 3. All "on" checkboxes may be successful. 4. For radio buttons that share the same value of the name attribute, only the "on" radio button may be successful. 5. For menus, the control name is provided by a SELECT element and values are provided by OPTION elements. Only selected options may be successful. When no options are selected, the control is not successful. 6. The current value of a file select is a list of one or more file names. Upon submission of the form, the contents of each file are submitted with the rest of the form data. The file contents are packaged according to the form's content type. 7. The current value of an object control is determined by the object's implementation.
Tests: None

Assertion 17.13.2-2

Reference: Section 17.13.2
(must) If a control doesn't have a current value when the form is submitted, user agents are not required to treat it as a successful control.
Tests: None

Assertion 17.13.2-3

Reference: Section 17.13.2
(must) User agents should not consider the following controls successful: 1. Reset buttons. 2. OBJECT elements whose declare attribute has been set.
Tests: None

Assertion 17.13.2-4

Reference: Section 17.13.2
(must) Hidden controls such as "password" will still cause a value to be paired with the name "invisible-password" and submitted with the form.
Tests: None

Assertion 17.13.3-1

Reference: Section 17.13.3
(must) When the user submits a form (e.g., by activating a submit button), the user agent processes it as follows. 1. Identify the successful controls 2. Build a form data set(a form data set is a sequence of control-name/current- value pairs constructed from successful controls) 3: Encode the form data set (The form data set is then encoded according to the content type specified by the enctype attribute of the FORM element). 4. Step four: Submit the encoded form data set . 5. The encoded data is sent to the processing agent designated by the action attribute using the protocol specified by the method attribute
Tests: None

Assertion 17.13.4-1

Reference: Section 17.13.4
(must) Forms submitted with content type application/x-www-form-urlencoded must be encoded as follows: 1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A'). 2. The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.
Tests: None

Assertion 17.13.4-2

Reference: Section 17.13.4
(must) Forms submitted with content type "multipart/form-data must be encoded as follows: 1. User agents should supply the "Content-Type" header whose value is "multipart/form-data". 2. a "Content-Disposition" header whose value is "form-data" and a name attribute specifying the control name of the corresponding control. The file name may be specified with the "filename" parameter. 3. Each part may be encoded and the "Content-Transfer-Encoding" header supplied if the value of that part does not conform to the default (7BIT) encoding (see [RFC2045], section 6) 4. If the contents of a file are submitted with a form, the file input should be identified by the appropriate content type (e.g., "application/octet-stream"). 5. If multiple files are to be returned as the result of a single form entry, they should be returned as "multipart/mixed" embedded within the "multipart/form-data".
Tests: None