Exam practice

• Event: something that happens, which a program can react to. Example: a button being clicked; typing in a box (input).
• Listener (event handler): a function the browser runs each time an event happens. Example: button.addEventListener('click', split); makes split the listener for clicks on the button.
• The DOM (Document Object Model): the tree of objects the browser builds from a page’s HTML, from which it draws the page; a script changes the page by changing it. Example: message.textContent = 'Saved'; changes a paragraph object, and the page shows “Saved”.
• NaN: “not a number”, the result of a calculation that has no number as its answer. Example: Number('abc'), or 120 + undefined.
• Specification: a list of what an app must do, written so it can be checked. Example: “gives each person’s share in whole rupees”.

const marks = [72, 65, 80];let total = 0;for (const m of marks) {  total = total + m;}if (total > 200) {  console.log('Well done');} else {  console.log('Keep going');}

marks never gets a new array, so it is const; total changes, so it is let. The total is 217, so it prints Well done.

cba. Each time round, the new letter is joined in front of the word so far: 'a', then 'ba', then 'cba'. The loop reverses the letters.

let count = 0;const countText = document.querySelector('#count'); document.querySelector('#plus').addEventListener('click', function () {  count = count + 1;  countText.textContent = count;});

The number is kept in a variable, count; each click changes the variable and then shows it on the page. (Reading the number back from the page, Number(countText.textContent) + 1, also works, but keeping the data in a variable is clearer.)

save() with brackets runs the function at once, when the line is reached, as the page opens, and passes what it returns (nothing, undefined) to addEventListener. So the browser is given no function to run on a click. The fix is to pass the function itself, without brackets: button.addEventListener('click', save);.

A box’s value is always a string. '2' + '3' joins the two strings: '23'. Turn each into a number first:

answer.textContent = Number(a.value) + Number(b.value);

Now 2 + 3 gives 5. A careful app also checks that neither box is empty and that neither gives NaN, and shows a message if so.

• innerHTML treats the text as HTML. If what was typed is really HTML with a script in it, the browser would run that script, and if the text is shown to other users (a comment, a message), it runs in their browsers too: cross-site scripting. textContent always shows text as plain text, so nothing in it can run.
• The page’s JavaScript runs on the user’s own device: anyone can read it (and so find a password hidden in it) and change it or skip it in their own browser. Only a check on the server, which the user can’t change, can be trusted.

Any four of:

• A <label> for every box: the screen reader says what to type in it.
• Real <button>s for everything to tap: they can be reached with Tab and pressed with Enter or Space, and are announced as buttons.
• Messages in an element with role="status": when the answer or an error appears, the screen reader reads it out.
• Alt text on every picture: the screen reader says what it shows.
• Headings in order: the user can jump through the page’s parts.
• Words, not only color, for right and wrong: a screen reader can’t say colors.
• A sensible Tab order, from the HTML’s order: the keyboard goes through the app as it is read.

A model answer (any brief with these parts, sensibly filled in, is right):

For: the owner of a small grocery shop, and helpers who are new to the till.

Their task now: working out the change in their heads or on paper, which is slow in a queue and sometimes wrong.

Where: at the counter, on the shop’s phone, in a busy, noisy shop, with one hand often full; in Nepali or English.

It must: take the bill and the money given, in rupees; show the change in large numbers; say “not enough” if the money is less than the bill; say which notes and coins make up the change; work with one thumb and with big buttons; keep no record of customers.

Values:

• Privacy: does it store anything about customers? (It shouldn’t need to.)
• Honesty: could it ever round in the shop’s favor without saying so?
• For everyone: can a helper who reads only Nepali, or an older owner with poor eyesight, use it?
• Safety: what happens if it is wrong? Should it show the sum too, so a person can check?

The app is right for ordinary whole numbers (24 kg), but not yet correct overall: it shows a long string of digits (2.916666666666667) instead of rounding its answer to a sensible 2 places, and it doesn’t check its inputs, so an empty box gives a believable but wrong 0, and a negative weight gives a negative answer instead of a message. Next the team should: round the answer it shows (for example toFixed(2)); check for an empty box, NaN and numbers of 0 or below before converting, with a message that says what to type; run all four tests again, plus new edge tests (0 kg, a very large weight); and then test with real users, such as shopkeepers, to see whether it does its job: is it quicker than what they do now, and do they need the answer in kg and dharni both ways?