The Nómada Tasks board already draws itself, filters, sorts and responds to clicks. But Marta still cannot do the most elementary thing: create a task. The backlog is the one in data/backlog.js and that is that. Adding a task means a form, and a form is much more than a few <input>s: it is the point where data you do not control comes in, where everything arrives as text, where you have to decide what is validated in the browser and what in the model, and where accessibility stops being a detail and becomes essential —an error message that can only be seen in red does not exist for someone who cannot see the screen. In this lesson you will build the complete creation form, with two-layer validation, accessible messages, on-the-fly validation with debounce and correct focus management. It is the last piece of Module 6.

1. The creation form: semantic HTML
2. The field attributes
3. Reading values: value, FormData and Object.fromEntries
4. Everything arrives as text
5. The submit event and preventDefault
6. Native HTML5 validation
7. Native validation versus JavaScript validation
8. Business rules live in the model
9. Showing errors accessibly
10. On-the-fly validation with input and debounce
11. Submitting, resetting and returning focus
12. Nómada Tasks: view/form.js
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

We start with the markup, because a well-written form solves half the work before you touch any JavaScript:

The decisions that matter:

• Every field has its <label for="…"> pointing at the control's id. This is not optional: it is what makes a screen reader announce "Title, text field, required" and what lets you activate the field by clicking the label. A placeholder is not a substitute for a label: it disappears when you type and many readers do not announce it.
• name on every control. It is the key under which the data will appear in FormData. Without a name, the field simply is not submitted. And here we have made them match the property names of Task (title, estimatedHours, dueDate), which is going to save a lot of work in section 3.
• <fieldset> with <legend> groups related fields and gives them a common name, which screen readers announce when entering the group. It is essential with radio groups and highly recommended in general.
• aria-describedby connects the field with its hint text, so that it is read along with the field's name.
• role="alert" on the error container: when you put text in it, screen readers will announce it immediately, without the user having to go looking for it.
• novalidate on the <form> turns off the browser's error bubbles, but it does not turn off the validation API: we can still query checkValidity(). That is what will let us show the errors with our own design and with the accessibility we want. We will come back to it in section 6.

Modern HTML has far more validation capability than people usually use:

Two details that are often forgotten:

• type="number" does not prevent typing letters in every browser, but it does make input.value return an empty string if the content is not a valid number. It is behavior that surprises people: the field looks like it has text and value is empty.
• disabled excludes the field from submission; readonly includes it. If you need to show a fixed value and have it arrive with the submission, use readonly.

There are three levels, from most manual to most automatic.

Level 1: field by field.

It works, but every new field is two more lines and an id that can go stale.

Level 2: form.elements. Every form has a collection of its controls, accessible by name:

It is convenient for reaching a specific control without looking it up with querySelector.

Level 3: FormData + Object.fromEntries. This is the idiomatic form:

Here you collect the dividend of having written name="estimatedHours" instead of name="hours": the object's keys already match the properties the Task constructor expects.

Two limitations of Object.fromEntries worth knowing:

• With repeated names, it keeps the last one. A group of checkboxes with the same name requires data.getAll('tags'), which returns an array with every value.
• Unchecked checkboxes do not appear in FormData. They are not false: they are simply not there. You have to account for their absence with ?? false or query the checked property.

Look at the output above again: estimatedHours is '4', the string, not the number. It is the same boundary you already saw with dataset in 06-02 and the whole reason for lesson 01-07.

That last case is especially treacherous: '4' > 40 is converted to 4 > 40 and gives false by coincidence; but '9' > 40 also gives false, and '10' > '9' gives false because it compares strings. Any numeric validation over unconverted text is a time bomb.

The solution is an explicit boundary conversion function, with Number (never parseInt, which accepts '12abc' and returns 12):

A warning about Number with the empty string: Number('') is 0, not NaN. If a required numeric field is submitted empty and the model expects a number, 0 would pass the conversion and fail later with a confusing message. That is why the HTML's required and the model's validation complement each other.

And a note about type="date": its value is always a 'yyyy-mm-dd' string, exactly the ISO format Nómada Tasks uses. There are also input.valueAsNumber (milliseconds) and valueAsDate (a Date object), but for us the string is ideal, because it is what the model stores.

A form's submission is listened for on the <form>, not on the button:

Without preventDefault(), the browser does what it did in 1995: it serializes the form, navigates to the URL in the action attribute (or reloads the current one) and your whole application starts over. It is mistake number one with forms and it produces the baffling symptom of "the page flickers and nothing happens".

Useful details about submit:

• It fires with Enter inside a text field, not only when the button is pressed. It is a convenience users expect: do not break it by listening for click on the button instead of submit on the form.
• A <button> inside a form is type="submit" by default. A button that does something else needs an explicit type="button", or it will submit the form by accident.
• event.submitter tells you which button caused the submission, useful when there are several ("Create" and "Create and duplicate").
• type="reset" fires a reset event and empties the fields; it is cancelable too.

The browser comes with a complete validation engine, and wasting it is a frequent mistake. Every control has:

The validity object has one flag per kind of failure, and this allows precise messages:

At form level:

And setCustomValidity lets you add an error of your own to the native engine:

Golden rule with setCustomValidity: it has to be cleared. If you set a message and do not delete it when the user corrects things, the field stays invalid forever and the form will never submit, with no clue as to why.

In CSS you can react to validity with pseudo-classes:

:user-invalid is preferable to :invalid because it only turns on after the user has interacted with the field. With plain :invalid, every required field shows up in red as soon as the page loads, before anybody has typed anything: a hostile experience.

The correct answer is not to choose one: it is to use both, in layers.

1. HTML layer: required, min, max, pattern, type. Cheap, works without JavaScript, guides the user while typing and makes phones show the right keyboard.
2. View's JavaScript layer: your own messages, when to show them, accessibility, cross-field rules.
3. Model layer: the real business rules, which have existed since Module 5 and which are not duplicated.

And a fourth layer that is not optional in a real application: the server. All the browser's validation can be bypassed with the DevTools in ten seconds. It exists to help the user, never to guarantee data integrity. Nómada Tasks does not have a server yet; it will in Module 7.

This is the most important architectural decision of the lesson. Look at what Task already knows how to do since 05-02 and 05-03:

• R1: Board.add rejects duplicated ids.
• R2: the constructor throws ValidationError if the title is empty.
• R3: the estimatedHours setter demands a number between 1 and 40.
• R5: the initial status is 'pending'.
• R9: tags are normalized and deduplicated.

It would be a mistake to rewrite all of that in the view. If you did, you would have two copies of each rule, which would go out of sync with the first modification, and Module 8 would have to test them twice.

The right thing is to try to build the task and catch the error. The view does not validate business rules: it limits itself to translating the model's error into a message on screen.

That error.field is gold: the ValidationError you designed in 05-02 already carries the name of the field that failed, so the view knows exactly where to put the message and which field to move focus to. Designing the errors that way, months before there was an interface, is what makes them fit now without any effort.

The ids are generated by the closure from 03-04, which is still the right way of not exposing a global counter:

What is left are the validations that do belong to the view, because they are not domain rules but rules of this specific form: that the due date is not earlier than today, that the tags field does not bring more than five, or any check that depends on the relationship between two fields.

An error message has to satisfy four things. If it fails one, there are people who cannot use your form:

1. Be associated with the field, with aria-describedby, so that it is read along with it.
2. Mark the field as invalid, with aria-invalid="true", so that it is announced as such.
3. Announce itself when it appears, with role="alert" on the general summary.
4. Move focus to the first field with an error, so that keyboard users do not have to hunt for it.

And a fifth requirement that is not technical: color cannot be the only signal. A red border with no text says nothing to somebody who cannot distinguish red.

Note the care taken with aria-describedby: it can contain several space-separated ids, and the field already had the one for its hint text. Clobbering it with setAttribute('aria-describedby', errorId) would make the hint disappear. It is a small detail with real consequences.

And the focus move, which happens only once, to the first error:

Validating only on submit is frustrating: the user fills in seven fields and finds out at the end that the second one was wrong. Validating on every key is just as annoying: "the title is too short" pops up as soon as the first letter is typed.

The balance that works:

And for expensive or noisy validations —a search for duplicated titles, for instance— a debounce is applied: wait until the user has stopped typing for a while before acting. It is implemented with the closure from 03-04:

A trace of what happens if Marta types "Buy white ink" in one second:

Thirteen keystrokes, a single validation. With local data the saving is symbolic; with a check against a server (Module 7) it is the difference between thirteen requests and one.

Do not confuse debounce with throttle: the first waits for the events to stop; the second runs at most once every X milliseconds, and is the right choice for scroll or resize. Both techniques are studied in detail in Optimizing JavaScript Performance.

An accessibility warning about debounce: with role="alert", every text change is announced. If you validate a field on the fly while the user types, the screen reader will interrupt constantly. That is why the on-the-fly messages go in the field's <small> (with aria-describedby, which is read when the user reaches the field) and only the submission summary uses role="alert".

When the submission goes well, three gestures separate a careful form from a careless one:

• reset() returns every control to its initial value from the HTML, not to the empty string: that is why <option value="medium" selected> becomes selected again. It also clears the :user-invalid state.
• Returning focus to the first field lets you create several tasks in a row without touching the mouse. If you do not, focus stays on the "Create" button and the user has to go back with Shift+Tab seven times.
• The confirmation must be perceivable by everyone. Text appearing in a container with role="status" is announced without interrupting; a silent animation is not.

Remember also to clear the previous errors on every submission: if you do not, fields that have already been fixed stay marked.

The complete module, which brings the three validation layers together:

And the final wiring in app.js, with the module's complete cycle:

Try it. Create "Buy white screen-printing ink", Lucía, high priority, 4 h, 10 October, tags "screen-printing, storeroom". The card appears in the "Not started" column, the counter goes from 3 tasks · 25 h to 4 tasks · 29 h, and the summary from 6 tasks · 5 open · 45 of 48 h to 7 tasks · 6 open · 49 of 52 h. Then try submitting with an empty title: the summary announces the error, the field is marked with aria-invalid, the message appears under the label and focus jumps to the field. And try entering 60 hours: the HTML's max="40" catches it before it reaches the model, and if you bypassed that with the DevTools, the estimatedHours setter (R3) would reject it just the same. Two layers, the same rule, a single definition.

• Forgetting preventDefault() on the submit. The page reloads and all the state is lost. If your form "flickers and does nothing", this is the reason 90 % of the time.
• Listening for click on the button instead of submit on the form. It breaks submitting with Enter, which many users take for granted.
• Using <button> without a type for actions that do not submit. Inside a form, the default value is submit. Any auxiliary button needs type="button".
• Using a placeholder instead of a <label>. It disappears when you type, it is not always announced and it cannot be clicked. The label is mandatory; the placeholder is an extra.
• Not converting the values. Everything arrives as text: '4' > 40 gives false by coincidence and '10' > '9' gives false through string comparison. Convert with Number() in a normalization function.
• Forgetting setCustomValidity('') when things are corrected. The field stays invalid forever and the form never submits, with no visible clue.
• Clobbering aria-describedby. It can contain several ids; overwriting it removes the reference to the hint text. Add and remove ids while preserving the others.
• Duplicating the business rules in the view. If Task already validates the hours range, the view must not repeat it: it must catch the ValidationError and use its field and its message. One rule, one place.
• Marking everything red on page load. That is what plain :invalid does. Use :user-invalid, which waits for the user to interact.
• Trusting client-side validation. It is bypassed with the DevTools in ten seconds. It is help for the user, not a guarantee; the guarantee comes from the server (Module 7).
• Tip: make the names match the model's properties. Object.fromEntries(new FormData(form)) then produces an object almost ready for the constructor, and you save yourself an entire mapping.
• Tip: test your form with the keyboard only. Tab, Shift+Tab, Enter, Escape. If you can fill it in, submit it, fix an error and submit it again without touching the mouse, it is well made.

Add a <select name="reviewer"> to the form with the same people and a cross-field validation: the reviewer cannot be the same person as the assignee. It must show as an accessible error on the reviewer field, be revalidated when either of the two changes, and not prevent both from being left unassigned.

Add under the notes field a counter "120 / 200 characters" that updates as you type and warns when fewer than 20 are left. It must use input, must not interrupt screen readers on every key, and must apply a debounce to the announcement. Explain which combination of aria-live and debounce you chose and why.

Prevent the creation of two open tasks with the same title (comparing without distinguishing case or superfluous accents). Decide with reasons which layer this rule lives in, implement it there, and validate on the fly with a 400 ms debounce, showing the warning before the user presses "Create task".

Exercise 1

Two important decisions. The first: setCustomValidity is used, which integrates the rule into the native engine and makes the submission's checkValidity() loop detect it with no extra code. The second: we listen on both fields, because the error can appear or disappear when either of them changes; validating only the reviewer would leave a stale error if the user fixes things by changing the assignee. And the reviewer.value !== '' lets both be left empty, exactly as the exercise asked: "unassigned" and "no reviewer" do not clash with each other.

Exercise 2

The chosen combination is aria-live="polite" plus a 500 ms debounce, and the reasoning is this: polite makes the reader wait until it has finished whatever it is saying before announcing the change, instead of interrupting as assertive or role="alert" would. But even being polite, updating the text on every key would queue dozens of announcements. The debounce guarantees that it is only announced when the user pauses, which is exactly the moment the information is useful to them. The warning class, by contrast, is applied immediately: it is visual information, it costs nothing and it interrupts nobody.

Exercise 3

The rule "there cannot be two open tasks with the same title" is a business rule, not a presentation one: it stays true even if the task is created from a script, from an import or from the server. It therefore lives in the model, alongside R1.

The key is that the view asks the model (board.hasDuplicateTitle(...)) instead of reimplementing the comparison. If tomorrow it is decided that done tasks also count, or that punctuation should be ignored, a single function is changed and both the on-the-fly warning and the rejection at submission behave the same way. The normalize('NFD') followed by stripping the diacritics is the standard way of comparing "Café signage" and "Cafe signage" as equal.

With this, Nómada Tasks is complete as a browser application. You know how to write a semantic form: every control with its <label for>, its name —made to match the model's properties, which saves an entire mapping—, its <fieldset> and <legend> for grouping, its aria-describedby for the hints and its validation attributes (required, minlength, min, max, step, pattern, type="date", type="number"). You know how to read the values at three levels, from element.value to the idiomatic Object.fromEntries(new FormData(form)), with the two limitations worth remembering: repeated names require getAll, and unchecked checkboxes simply do not appear. And you have it engraved that everything arrives as text, with '4' > 40 and '10' > '9' as reminders of why a normalization function with Number() is not optional.

You have mastered submit with its mandatory preventDefault() and its details —it fires with Enter, buttons are submit by default, event.submitter tells you which was pressed— and the two ways of validating, which do not compete but stack. The native one contributes checkValidity, reportValidity, the validity object with one flag per kind of failure, setCustomValidity (and the obligation to clear it), novalidate to keep the API without the browser's bubbles, and :user-invalid instead of :invalid so as not to dye the page red before anybody has typed. The JavaScript one contributes control of the message, of the timing and of accessibility, plus the cross-field rules. And above both stands the architectural decision that organizes the whole project: business rules live in the model. The view does not reimplement R1, R2, R3 or R9; it tries to build the Task, catches the ValidationError and uses its field and its message to know where to put the message and which field to move focus to. Designing that error with a field property, two modules before a screen existed, is what makes it fit today without a line of glue.

You know how to show errors that exist for everybody: aria-invalid="true" on the field, the message linked with aria-describedby —preserving whatever ids were already there—, a summary with role="alert" that announces itself, focus moved to the first field with an error, and a signal that does not depend on color alone. You know how to validate on the fly at the right moment —when leaving a field the first time, and on every key only to remove errors already shown— and to damp the noise with a debounce built from a closure from 03-04, telling it apart from throttle and bearing in mind that an undamped aria-live turns a screen reader into a machine gun. And you close the cycle with the three final gestures: reset(), focus to the first field and a perceivable confirmation.

This brings Module 6 to an end. You have covered the whole DOM: what the tree is and how the browser builds it; how you select with CSS selectors and how you manipulate text, attributes, dataset, classes and styles; how handlers are registered and what the Event object brings; how an event travels through the three phases and how delegation with closest() and data-id lets you serve a whole list with a single handler; how nodes are created, inserted and removed without opening security holes or memory leaks; how the cycle state → render → event → new state → render is organized with key-based reconciliation; and how user data is collected and validated. The model from Modules 1 to 5 has not changed a single line in the process: it is still pure JavaScript, without one mention of document. That boundary is what will make Module 8 possible, when you test the model without a browser.

And now open the DevTools, create three tasks for Iván, mark two as done, filter by Lucía… and press F5. Everything disappears. Back come the six tasks of data/backlog.js, the 48 h, effort 124, as if Marta had never done any work. The application looks beautiful and remembers nothing, because everything that has happened lives in the memory of a tab you have just reloaded. Worse still: even if it did remember, Marta, Iván and Lucía would each work with their own copy, with no way of seeing what the others are doing. Missing are the two halves that turn a page into a product: storing the data in the browser so that it survives a reload, and talking to a server so that the board is the same one for the whole team. That is Module 7: Browser APIs, which starts with Local and Session Storage —where the toJSON and the static fromJSON you wrote in 05-03 will finally show what they were there for.