Front-End Exercise 2

Practice discovering accessibility issues and reporting them clearly in English.

Exercise #2 · Accessibility Audit — Missing Labels

Front-end · Accessibility · Speaking

Assignment & Scenario: You are testing a login form during a sprint review. Visually it looks fine, but it has no labels or alt text. Your job is to reproduce the issue, think aloud, and report the accessibility bug as if speaking to a developer.

Live Demo (intentionally inaccessible)

Try navigating with a keyboard or screen reader. Then describe what happens out loud.

<!-- Minimal inaccessible example you can reuse elsewhere -->
<form>
  <input type="text" placeholder="Enter username">
  <input type="password" placeholder="Enter password">
  <button>Login</button>
</form>

<!-- Issues:
- Inputs rely on placeholders (not read reliably by screen readers)
- No <label> elements linked with for/id
- Button would have no accessible name if replaced with an icon-only control -->

🎤 Speaking Instructions (in-class) how to perform

Title (1 sentence): “Login form missing accessible labels.”
Environment: “Chrome 127 on Windows 11, keyboard navigation; screen reader on.”
Steps to reproduce:
1. Open the Accessibility Audit page.
2. Move focus through the form using Tab.
3. Run a screen reader and focus each input.
Expected vs. Actual:
- Expected: Each field is announced with a clear label (e.g., “Username”, “Password”).
- Actual: Inputs are announced generically (e.g., “edit text”) or rely on placeholder text that disappears.
Impact/Severity: “High — users of assistive technologies cannot log in.”
Recommendation: “Add <label> elements with for/id; if icons are used, provide an accessible name via visible text or aria-label.”
Hand-off: “I’ll attach a short screen recording and open a ticket with WCAG references.”

📖 Vocabulary definitions

accessible — usable by people with disabilities.
screen reader — software that reads aloud on-screen content.
label — text linked to an input field that describes its purpose.
placeholder — hint text inside an input; not a substitute for a label.
assistive technology — software/hardware that helps people access digital content.
alt text — textual description for images.
ARIA attributes — HTML attributes (e.g., aria-label) that improve accessibility semantics.
focus order — the order in which elements receive keyboard focus.
keyboard navigation — operating the UI via keys (e.g., Tab, Shift+Tab).
visible label — on-screen text that names a control.

🧩 Collocations natural pairings

add descriptive labels
provide alt text
test with a screen reader
improve keyboard navigation
follow accessibility guidelines
remove barriers to access
ensure proper focus order
announce the control purpose

🗣️ Idioms & Phrasal Verbs natural speech

fall through the cracks — be overlooked (e.g., “Accessibility often falls through the cracks.”)
point out — highlight an issue.
talk through — explain step by step.
rule out — eliminate a possible cause.
see eye to eye — agree on an approach.
clear up — resolve confusion or a problem.
check out — test or review quickly.

🧪 Model Answer (spoken style) example

“The login form has an accessibility issue. When I open the page and run a screen reader, the input fields are only announced as ‘edit text,’ with no context. I expected the fields to be labeled as ‘Username’ and ‘Password.’ This is a serious problem because users with visual impairments cannot log in. The severity is high. I recommend adding proper tags linked with the for attribute, or using aria-label attributes. That would clear up the issue and make the form accessible to everyone.”