Challenge 2: Explain Why Step 2 Should Happen Before Step 3 — Possible Solution
====================================================================

WHY SEMANTIC HTML SHOULD BE FIXED BEFORE KEYBOARD-SPECIFIC FIXES
----------------------------------------------------------------------
Converting div-based "buttons" (like the Cart control) to real
<button> elements FUNDAMENTALLY CHANGES the page's keyboard behavior
before any keyboard-specific work has even started: a native <button>
is automatically part of the tab order and automatically supports
Enter/Space activation, per Chapter 2's own point — none of which the
original <div onclick="..."> version had. This means the page's ACTUAL
tab order, and the total NUMBER of genuinely keyboard-reachable
elements, both change as a direct result of Step 2's fixes.

If Step 3 (skip link and focus trap) were attempted FIRST, against
the ORIGINAL div-based markup, it would be built around an incorrect
picture of the page's keyboard structure — for instance, a skip link
built to jump past "the first 4 keyboard-focusable elements" would be
targeting the wrong count entirely once several div-based fake buttons
become genuinely focusable after Step 2 converts them to real
<button>s. Similarly, a focus trap's boundaries (which elements count
as the "first" and "last" focusable elements inside a modal) could be
calculated incorrectly if some of the modal's own interactive elements
are STILL div-based fakes that aren't actually part of the tab order
yet when Step 3 is being implemented.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly reflects the capstone's own closing tip box: "fixes can
interact." Step 2's changes aren't isolated to how elements LOOK or are
announced — they change the actual, structural keyboard behavior of the
page (what's in the tab order, what responds to Enter/Space) that Step
3's work directly depends on and builds upon. Doing keyboard-specific
work against a page whose underlying semantic/focusable structure is
still broken risks building Step 3's fixes around numbers and
assumptions that are about to change once Step 2 is properly applied —
exactly the kind of sequencing dependency that makes step ORDER in this
methodology meaningful rather than arbitrary.