Front-End Exercise 5

Ctrl+Speak · Front-End QA Speaking Exercise

Practice describing validation issues and proposing fixes clearly in English.

Exercise #5 · Form Validation — Submit Never Enables

Front-end · Forms · Speaking

Assignment & Scenario: You’re testing a signup form. Product expects the “Create account” button to enable when the user enters a valid name, a valid email, a password (8+ chars), and checks the Terms box. However, the button remains disabled even with seemingly valid input. Your job is to reproduce the bug, think aloud, and report it as if speaking to a developer.

Live Demo (intentionally buggy)

Try signing up with a normal email (e.g., alex+test@company.info) and check Terms.

<!-- Minimal buggy snippet you can reuse -->
<form novalidate>
  <input id="email" type="email" required>
  <input id="pwd" type="password" required>
  <input id="agree" type="checkbox">
  <button id="submitBtn" disabled>Create account</button>
</form>

<script>
// BUG 1: overly strict email regex (rejects '+' and long TLDs)
const EMAIL = /^[\\w.-]+@[\\w.-]+\\.[A-Za-z]{2,3}$/;

// BUG 2: wrong checkbox ID queried
const agreed = document.getElementById('agreed'); // should be 'agree'
</script>

🎤 Speaking Instructions (in-class) how to perform

Title: “Submit button never enables on signup form.”
Environment: “Chrome on Windows 11; default viewport; no extensions.”
Steps to reproduce:
1. Open the page.
2. Enter a full name.
3. Enter an email like alex+test@company.info.
4. Enter a password ≥ 8 chars.
5. Check the Terms box.
6. Observe the Create account button state.
Expected vs. Actual:
- Expected: Button enables when all fields are valid and Terms is checked.
- Actual: Button stays disabled; errors may persist despite valid-looking input.
Impact/Severity: “High — blocks account creation; users cannot proceed.”
Recommendation: “Relax the email regex to allow ‘+’ and longer TLDs; fix the checkbox selector to use #agree; keep native type="email" semantics and consider aria-live for error updates.”
Hand-off: “I’ll attach a short screen recording and the regex test cases used.”

📖 Vocabulary definitions

validation — checking whether user input meets rules.
regex (regular expression) — a pattern used to match text.
selector — a way to find elements in the DOM (e.g., #agree).
disabled state — UI control is inactive/unusable.
error messaging — feedback shown when validation fails.
semantics — meaningful HTML that conveys intent and behavior.
aria-live — attribute that announces changes to assistive tech.
edge case — an uncommon input or condition (e.g., long TLDs like .museum).

🧩 Collocations natural pairings

enter valid credentials
trigger validation
relax the regex
attach an event listener
surface an error message
update the button state
cover edge cases

🗣️ Idioms & Phrasal Verbs natural speech

tighten up / loosen up — make rules stricter / more lenient.
trip up — cause an unexpected failure (“The regex trips up on ‘+’ emails.”)
rule out — eliminate a possible cause.
zero in on — focus on the main cause.
talk through — explain step by step.

🧪 Model Answer (spoken style) example

“Title: Submit button never enables on signup form. Environment: Chrome on Windows 11. Steps: enter a full name, use an email like ‘alex+test@company.info’, type an 8+ character password, and check Terms. Expected: the Create account button enables. Actual: it stays disabled. Impact: high, users are blocked from signing up. Likely causes: the custom email regex rejects legitimate addresses with ‘+’ and long TLDs; also the script queries ‘#agreed’ instead of ‘#agree’ so the Terms checkbox is never detected. Recommendation: relax the email regex (or rely on type="email" and server-side validation), query the correct checkbox ID, and consider aria-live="polite" for error updates. I’ll attach a short recording and regex test cases to the ticket.”