Challenge 3: Identify Redundant or Conflicting ARIA — Possible Solution
====================================================================

(a) <nav role="navigation">
    -> REDUNDANT

    The <nav> element already has an IMPLICIT ARIA role of
    "navigation" built in — this is exactly the same landmark role
    covered in Chapter 2's landmark table. Adding role="navigation"
    explicitly changes nothing at all; the element already announces
    itself as a navigation landmark without it. This mirrors the
    chapter's own <button role="button"> example precisely — pointless,
    though not actively harmful, since the explicit role matches the
    implicit one exactly.

(b) <a href="/settings" role="button">
    -> CONFLICTING

    This element has a REAL href attribute, meaning it's a genuine,
    functional link that will navigate the browser to /settings when
    activated — but role="button" tells assistive technology to
    announce and treat it as a button instead. This creates exactly
    the contradictory-signals problem the chapter describes: a screen
    reader user hears "button" and reasonably expects an action with
    no navigation, a keyboard user might expect Space (not just Enter)
    to activate it as buttons typically support, but the actual
    underlying behavior is still "follow this link" — the announced
    role and the actual behavior no longer match, which is confusing
    at best and actively misleading at worst.

(c) <div role="tablist">
    -> GENUINELY NECESSARY

    Unlike (a) and (b), there is NO native HTML element that expresses
    a tab interface (a tablist/tab/tabpanel pattern) — this is exactly
    the case the chapter's tip box calls out as ARIA "genuinely earning
    its place": when no native element covers the pattern at all, ARIA
    roles like role="tablist" (along with the accompanying role="tab"
    and role="tabpanel" on the related elements) are the correct,
    necessary tool, not a workaround being reached for prematurely.
    Note that using role="tablist" alone still isn't sufficient for a
    fully accessible tab component — Chapter 8 covers the complete
    pattern (including the keyboard behavior a real tablist needs,
    which — as this chapter's broader lesson emphasizes — ARIA roles
    alone still don't provide automatically).

WHY THIS WORKS AS AN ANALYSIS
--------------------------------
The distinguishing test in each case is: "does a native element/attribute
already express this exact meaning?" (a) has an exact native
equivalent already built in (redundant). (b) has a native element
expressing a DIFFERENT meaning that now contradicts the added role
(conflicting). (c) has no native equivalent whatsoever, which is
precisely the condition under which this chapter says ARIA is the
correct tool to reach for.