Spec Review/Forms

Under review:

• Forms

Joshue O Connor

• Issue1) Sections 4.10 (and the corresponding subsections) seem fine to me. My only main observation is editorial in that it seems to be a missed opportunity to educate and inform authors about some of the reasons behind best practice and the benefits of well formed mark up. This is because while the examples given are good, easy to follow and clear the spec doesn’t state why form elements and controls are marked up in the way that is demonstrated in the spec, or even mention any of the practical reasons/benefits for doing so (interoperability, accessibility, form validation etc).

• Issue 2) In section 4.10.6 The label element, the label is said to represent a 'caption' in a user interface. There is however there is no explanation of what “caption” means in this context. Is it the same as a 'caption' for a data table, or is it similar to the figcaption etc? I suggest linking to the section of the spec that describes what a caption is, and what it is for as well as its content model etc.

Michael to file bug (editorial, doesn't need a11ytf keyword) Bug 13620

• [1] http://www.w3.org/TR/2011/WD-html5-20110525/tabular-data.html#the-caption-element
• [2] http://www.w3.org/TR/2011/WD-html5-20110525/grouping-content.html#the-figcaption-element

Markku Hakkinen

Note: migrated from UA wiki 26 July 2011, may not have content added after that

HTML5 includes new input types and attributes, such as type="tel", pattern, and placeholder. These new types and attribute have usability and accessibility implicates, and guidance within the HTML5 specification is at times contradictory.

The pattern attribute

The pattern attribute specifies a regular expression against which the control's value, or, when the multiple attribute applies and is set, the control's values, are to be checked.

http://dev.w3.org/html5/spec/Overview.html#the-pattern-attribute

The pattern attribute value, in regular expression notation, is not suitable as a hint or description for end-users. The HTML specification describes methods for presenting the pattern to end-users:

When an input element has a pattern attribute specified, authors should include a title attribute to give a description of the pattern. User agents may use the contents of this attribute, if it is present, when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus.

The specification goes on to state:

When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired.

For instance, if the title attribute contained the caption of the control, assistive technology could end up saying something like The text you have entered does not match the required pattern. Birthday, which is not useful.

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred.

The lack of a keyboard accessible mechanism for displaying title content within all major UAs prevents keyboard users from accessing the pattern description. The statement "Otherwise, assistive technology would be impaired" fails to address the actual accessibility implications.

The use of the title, implied in the second paragraph above, as text for an error message, implies processing by the UA or assistive technology, and is in effect a special casing of the title attribute.

The definition of the placeholder attribute also contradicts the recommendation of using title.

Markku to file bug Bug 13635 Kelly Note: This is not the best bug just yet as it has no proposed changed text. I am entering this bug in place of Mark and thought it was higher priority to get the issues raised versus final text. Please advise if final text needs to be in by the deadline of today.

Greg Lowney

Tri-State Checkboxes

Why is there no true support for tri-state checkboxes (those with states of checked, unchecked, and mixed/undefined)? Not providing this means that authors and developers will still have to implement custom controls and behaviors for an extremely common feature.

Use case: Aidan uses speech recognition for input. When he views an interactive web page or web-based application that uses standard HTML5 controls, his speech recognition program can let him control them using standardized commands, such as checking or unchecking recognized checkboxes by saying "Check italic" or "Uncheck bold". However, when it encounters custom controls or controls with nonstandard behaviors, he has to resort to saying actual keystrokes, such as "Press tab. Press tab. Press tab. Press space." He uses a web-based text editor that provides a tri-state check box that is checked with the entire selection is italicized, unchecked when the entire selection is not italicized, and in a third, "mixed" state when only part of the selection is italicized. In one scenario, he accidentally checks the Italics check box then realizes he wants to change it back to the "mixed" state. Let's say it's implemented as an HTML5 input element with type=checkbox, but with scripting to handle the tristate behavior (perhaps as described in Shams' Blog: Tri-State Checkbox using Javascript - http://shamsmi.blogspot.com/2008/12/tri-state-checkbox-using-javascript.html); in this case the keyboard UI is not standardized, so the speech recognition utility cannot provide a corresponding voice command. In a second scenario, it's implemented as an entirely custom control.

Use case: Nadia uses a screen reader with the same web-based text editor that provides a tri-state checkbox for indicating and adjusting italics. Regardless of whether the author used an HTML5 input element with type=checkbox or if they used an entirely custom control, the screen reader has no way of determining which state it's really in, and so can't convey this to Nadia using speech.

Use case: Ryan, a keyboard user, is using the same web-based text editor that provides a tri-state checkbox for indicating and adjusting italics. Unfortunately, because each web site or web-based app has to implement its tri-state checkbox itself, they often implement entirely different keyboard UI, and so when Ryan comes to one he cannot easily figure out how to use it with the keyboard.

Recommendation: HTML5 should support tri-state check boxes and menu items so that user agents can provide standardized user interface for them and so assistive technology can provide alternative input and output for them.

Greg to file bug (noting that there is backwards compatibility issue with the boolean checked attribute) Bug 13508

Cynthia Shelly

General

• I’d like to see some discussion of using form elements (checkboxes, buttons, etc) outside of <form> tags, as is common for interactive applications.

Cynthia to file bug (will need to suggest edits later, not a11ytf) Bug 13656

Cynthia to file bug about form examples improvement DONE: Bug 13528

• Does the spec have a glossary?  There are a lot of linked terms don’t lead to a clear definition.  Some of the links seem to be circular.  (some specific examples in the notes below)

Janina to file bug on behalf of PF Bug 13641

4.10.1.1

Is it really common to wrap form elements in <p> tags?  I would have expected divs or just letting them flow within a fixed-width container.

Cynthia to file private bug DONE Bug 13530

• example uses <label><input>text</label> which is the less-preferred way to do labeling.  Examples should use <label for> and ID.

Cynthia to file bug DONE Bug 13531, depends on examples bug

• Uses <button> for submission.  Better practice to use <input type=submit> so script is not required.

Cynthia to file bug DONE Bug 13542 suggesting type=submit|reset for button element. button already has this feature. Look into whether it actually submits the form in any browsers. Janina to work with UAWG to see if there keyboard issues with button or if there UAs in which it does not submit by default

4.10.4 Fieldset

• Why is fieldset barred from constraint validation.  Why does it support validation methods if it is?

Cynthia to file bug privately

• Examples are all about disabling sections, which is a new feature in 5.  Add examples of grouping and labeling uses from prior versions.

Cynthia to file bug DONE Bug 13543 suggesting non-interactive fieldset example from HTML 4 spec

4.10.5 Legend

• This syntax is confusing.  Why are the only examples of legends that are interactive? 

<legend><label><input>text<label><legend>

Discuss a11y and aapi issue of form controls in legend

4.10.6 Label

• The second sentence here seems to contradict the first and the following example???

“The label element's exact default presentation and behavior, in particular what its behavior might be, if anything, should match the platform's label behavior. The activation behavior of a label element for events targetted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing.”

Cynthia to file bug DONE Bug 13553 noting that LC version was as desired, later edit is problematic

• Multiple labels (control.labels).  HTML 4 restricted this to one label per control.  How does this map to control name accessibility APIs?  How does it interact with ARIA name calculation?  Is it useful for accessibility? What is the use case for this?  Problems with hit testing and API mappings.

Discuss in the task force about how multiple labels should be handled

• Need to think about how this example would map to Accessibiltiy APIs

<p><label>Full name: <input name=fn> <small>Format: First Last</small></label></p> 
<p><label>Age: <input name=age type=number min=0></label></p> 
<p><label>Post code: <input name=pc> <small>Format: AB12 3CD</small></label></p> 
4.10.7 Input http://dev.w3.org/html5/spec/the-input-element.html#the-input-element'

Discuss AAPI handling of this use case

•         In general, having attributes that are only valid with certain types is confusing.  In HTML 4, it’s a common error to use alt on input other than type=img.  The design seems likely to cause more of that sort of confusion.  Can any of the attributes be made applicable to all input types, with specified mapping behavior?

Cynthia to file bug DONE Bug 13547 acknowledging there's history to work with but would like identify a path forward

• Alt.  Is it required? API mapping needs to cover interaction of label and alt. ***yes, it is required. covered later in the section***
•         Autocomplete:  how does this map to API?  Does this turn text controls into comboboxes?
• Should autocomplete be able to take a URL for a service?  How about a datalist?
•         Autofocus:  good idea to get around script issues with screen readers.  Do we know if it works?
•         “Save Button” example for formnovalidate is a good candidate for a WCAG technique [1]
•         Why are there size, width and height attributes?  Shouldn’t this be handled with CSS?  Can we make these obsolete but conforming?

Cynthia to file bug DONE Bug 13548

• Input.form what is the use case for this?  It claims to be a work-around for the lack of nested forms, but what is the use case for nested forms?  4.10.18 Association of controls and forms [2].  This looks like an authoring error. Specifying what the browser should do in case of this authoring error is fine, but why have an authoring feature to work around it? 

Cynthia to file bug DONE Bug 13549

• List.  This makes any input that is a text control into a combobox.  Type table needs to reflect that these change control type when they have lists.

Cynthia to file bug DONE Bug 13550

• Name isn’t in the table of what attributes are supported on what types.  Assume it’s on all types?  Should be listed to make it clear.
• Pattern.  This is really cool.
• Placeholder.  What should users put in here, vs. label, vs. title.  In accessibility API, I think this maps to accname, not value as current fake-placeholders do.  How does it play with other things in name calculation?  What should be read if there is a label and a placeholder

Discuss

• Required.  Also good.
• What is a value sanitation algorithm?  Please define what this is supposed to do.  Links within the section go to the top of the section.

Cynthia to file bug DONE Bug 13551

• Is the second sentence referring to immutable objects? It seems to apply to mutable, but doesn’t make sense  “Each input element is either mutable or immutable. Except where otherwise specified, an input element is always mutable. Similarly, except where otherwise specified, the user agent should not allow the user to modify the element's value or checkedness.”

Cynthia to file bug DONE Bug 13552

• “Thereadonly attribute can also in some cases (e.g. for the [3] state, but not the checkbox state) make aninput element immutable. “

Cynthia to file bug DONE Bug 13554

Is the full list of cases defined somewhere?

• “When aninput element is first created, the element's rendering and behavior must be set to the rendering and behavior defined for the type attribute's state, and the sanitization algorithm, if one is defined for the type attribute's state, must be invoked.”

These are defined with the states.  This is not clear when reading the above text, and the link goes to the top of the same section.  Can we have a generic definition of a value sanitation algorithm?

• Input type can be changed dynamically.  This is inconsistent with ARIA role.  Is that ok?  It seems unlikely that either will change at this point.  Will need to be considered for API mapping. 

Cynthia to file bug DONE Bug 13560 discuss how to handle in aapi guide and how hard we want to push this, given there's momentum from a year ago supporting this change and there's implementation - need to explore use cases

• Not accessibility, but it would be nice if <input type=email multiple> could split on semi-colon as well as comma DONE 13559
• Is there value to allowing some form of friendly name in email fields?  When you paste from email programs, this is often included, and it’s nice to be able to keep the friendly names around.  Cognitive, maybe?

Cynthia to file bug DONE Bug 13558 Discuss friendly name, cognitive load, copy/paste from email programs, etc.

• Security issues with autocomplete or pattern on password?
• Still concerning that date and time elements don’t have controls specified for them.  This seems likely to lead to inconsistent UI, which may be confusing to AT users.

Cynthia to file bug DONE 13561 will want to provide info about making control keyboard friendly, stylable, calendar popup readable to screenreaders, etc. and may need to address in aapi implementation guide

• Range says that the exact number is not important, but it renders as a slider.  There are sliders where the exact number is important. “The user agent could pick which one to display based on the dimensions given in the style sheet. This would allow it to maintain the same resolution for the tick marks, despite the differences in width.” This is very vague.  These different presentations should be controlled with CSS, not the browser.

Cynthia to file bug DONE 13657 about conflating number and range etc.

• Number’s control is a “text box or spinner control.”  Need to pick one so we know what accessibility role to map it to

Cynthia to file bug Bug 13562

Discuss balance between UA freedom to handle things as it prefers, vs impacts that has in real world on testing, author control, aapi mapping, etc. (Cynthia, Greg, UAWG have input on that)

• “The input element represents a two-state control that represents the element's checkedness state. If the element's checkedness state is true, the control represents a positive selection, and if it is false, a negative selection. If the element's indeterminate IDL attribute is set to true, then the control's selection should be obscured as if the control was in a third, indeterminate, state.

Note:

The control is never a true tri-state control, even if the element's indeterminate IDL attribute is set to true. The indeterminate IDL attribute only gives the appearance of a third state.”

Why isn’t there a 3^rd state?  This is inconsistent with ARIA.  Is that ok?

• Are radio and checkbox valid without associated labels?

Cynthia to file bug Bug 13563

• Can accept be extensible, to allow other file type filters?
• “If the src attribute is set, and the image is available and the user agent is configured to display that image, then: The element represents a control for selecting a coordinate from the image specified by the src attribute; if the element is mutable, the user agent should allow the user to select this coordinate. The activation behavior in this case consists of taking the user's selected coordinate, and then, if the element has a form owner, submitting the input element's form owner from the input element. If the user activates the control without explicitly selecting a coordinate, then the coordinate (0,0) must be assumed.

Otherwise, the element represents a submit button whose label is given by the value of the alt attribute; if the element is mutable, the user agent should allow the user to activate the button. The activation behavior in this case consists of setting the selected coordinate to (0,0), and then, if the element has a form owner, submitting the input element's form owner from the input element.”

Does this mean that it’s only a button if the image doesn’t download?

HTML 4 has this:

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

If the server takes different actions depending on the location clicked, users
of non-graphical browsers will be disadvantaged. For this reason, authors
should consider alternate approaches: 

Use multiple submit buttons (each with its own image) in place of a single
graphical submit button. Authors may use style sheets to control the
positioning of these buttons.

Use a client-side image map together with scripting.” 

Sounds like this functionality should be deprecated.  Is it often used?

Cynthia to file bug to deprecate imagemap behaviour on input type=image Bug 13566

Do some research to determine if imagemap on input type=image is used in real world

• “The alt attribute provides the textual label for the alternative button for users and user agents who cannot use the image. The alt attribute must also be present, and must contain a non-empty string.”  Needs a rewrite.  The alt attribute provides a text equivalent for the image button.  Not sure what an “alternative button” is…

Cynthia to file bug Bug 13567

• “A user agent may allow the user to override the autocompletion state and set it to always on, always allowing values to be remembered and prefilled), or always off, never remembering values. However, the ability to override the autocompletion state to on should not be trivially accessible, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences.”  Implications for cognitive.  Some users will need to set this all the time.  Also, I’m not sure what “trivially accessible” means.  I think it is advice on UI design for the browser.  Should that be in a normative section?  Is the an RFC SHOULD?  Use a different word than accessible.

Cynthia to file bug about "trivially accessible" Bug 13568

Cynthia to file bug about user override of autocomplete Bug 13569

• Is list just for making combo-boxes?  Are there other uses?  Examples using <label>foo<input></label> instead of <label for>
• Note in 4.10.7 says that readonly sometimes makes element immutable, but 4.10.7.2.4 The readonly attribute says “When specified, the element is immutable.”
• “When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired.

For instance, if the title attribute contained the caption of the control, assistive technology could end up saying something like The text you have entered does not match the required pattern. Birthday, which is not useful.

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred.”

Wow.  Title must describe the pattern?  Title is last choice for a lot of AT, right?  Shouldn’t the pattern be described in the visible label for everyone?

• Needs discussion

Greg to file bug for new global attribute named helptext or hint that would meet this use case among others Bug 13630

4.10.7.4 Common event behaviors

When the input event applies, any time the user causes the element's value to change, the user agent must queue a task to fire a simple event that bubbles named input at the input element. User agents may wait for a suitable break in the user's interaction before queuing the task; for example, a user agent could wait for the user to have not hit a key for 100ms, so as to only fire the event when the user pauses, instead of continuously for each keystroke.

Examples of a user changing the element's value would include the user typing into a text field, pasting a new value into the field, or undoing an edit in that field. Some user interactions do not cause changes to the value, e.g. hitting the "delete" key in an empty text field, or replacing some text in the field with text from the clipboard that happens to be exactly the same text.

When the change event applies, if the element does not have an activation behavior defined but uses a user interface that involves an explicit commit action, then any time the user commits a change to the element's value or list of selected files, the user agent must queue a task to fire a simple event that bubbles named change at the input element.

An example of a user interface with a commit action would be a File Upload control that consists of a single button that brings up a file selection dialog: when the dialog is closed, if that the file selection changed as a result, then the user has committed a new file selection.

Another example of a user interface with a commit action would be a Date control that allows both text-based user input and user selection from a drop-down calendar: while text input might not have an explicit commit step, selecting a date from the drop down calendar and then dismissing the drop down would be a commit action.

When the user agent changes the element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must follow these steps:

If the input event applies, queue a task to fire a simple event that bubbles named input at the input element.

If the change event applies, queue a task to fire a simple event that bubbles named change at the input element.

In addition, when the change event applies, change events can also be fired as part of the element's activation behavior and as part of the unfocusing steps.

The task source for these tasks is the user interaction task source.

• Why does color support autocomplete?  What does autocomplete on color do? 
• Random Idea: I wonder if there’s any way to support validating contrast ratios with color pickers within the same form?  Could adding pattern to color help here?

Cynthia to file bug Bug 13570

4.10.8 the button element

• “Thebutton element represents a button. If the element is not disabled, then the user agent should allow the user to activate the button.”  Should?

Cynthia to file bug Bug 13571

4.10.13 Textarea

• Anyone see issues with wrap=hard?

Greg to file bug suggesting removing because hard-wrapped text could introduce a11y problems Bug 13513

4.10.18 association of controls and forms

• Probably need some wcag techniques and failures here.  Seems like you could get pretty messy associating elements to different forms.

Cynthia to add to WCAG techniques wiki

4.10.19 autfocusing a form control

“If the user has indicated (for example, by starting to type in a form control) that he does not wish focus to be changed, then optionally abort these steps.”

Should this really be optional?

Cynthia to file bug Bug 13572

4.10.21 Constraints

This is really powerful.  Consider how this can be used to improve accessibility, and create WCAG techniques to leverage it.

Cynthia to propose WCAG techniques

4.10.22.2 Implicit submissions

“User agents may establish a button in each form as being the form's default button. This should be the first submit button in tree order whose form owner is that form element, but user agents may pick another button if another would be more appropriate for the platform. If the platform supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so must cause the form's default button's activation behavior, if any, to be run.

Note:

Consequently, if the default button is disabled, the form is not submitted when such an implicit submission mechanism is used. (A button has no activation behavior when disabled.)

If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself.”

This seems like it could cause different submission behavior on different platforms when the user hits enter.  Is that ok?

Kelly to file bug suggesting leaving open to UAAG recommendations Bug 13638 Again a bug was entered but this is still not the best bug. I also know that UAAG doesn’t currently have full text covering the topic addressed in this area. We can develop such but I don’t know how that overlaps with asking to reference something that isn’t yet done. But if the objective is to ensure the concern is at least on the table, this bug should be heading toward that objective.

discuss wherefores and whynots of form self submission