Exercise 2: Why Declaring Accessibility Support Is Different From Just Implementing It — Possible Solution
================================================================================================================

Chapter 2 covered the real, concrete work of actually making an app
accessible - adding VoiceOver labels, combining a row's own separate
accessibility elements into one coherent announcement, supporting
Dynamic Type so text properly scales with the user's own system
setting. All of that is real, genuine work done inside the app's own
code, verifiable by actually turning on VoiceOver and using the app.

The Accessibility Nutrition Label is a separate, later step: a real,
structured field in App Store Connect where that already-completed
work gets explicitly declared on the app's own public product page,
before a user ever downloads it at all. Without that declaration, a
user genuinely relying on VoiceOver or larger text has no real way of
knowing, while browsing the App Store, whether this specific app will
actually work well for them - they would only find out after
downloading it and trying it themselves.

This is directly analogous to writing real, working code and then
separately documenting it: the code being correct and the
documentation describing it accurately are two genuinely different
things, and skipping the second one means real, working functionality
stays effectively invisible to anyone deciding whether to use it in
the first place. Declaring the Accessibility Nutrition Label is what
makes Chapter 2's own real work visible and discoverable before
download, not what creates the accessibility itself.

ANSWER: Chapter 2's own work is what makes the app genuinely
accessible; the Accessibility Nutrition Label is a separate, later
declaration that surfaces that already-real work on the App Store
listing itself, so a user can know before downloading whether the app
will actually work for them - the label documents the accessibility,
it doesn't create it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This draws a clear, concrete distinction between the underlying
accessibility work (Chapter 2) and its public declaration (this
chapter), explaining specifically why skipping the declaration leaves
real, working functionality invisible to the exact users who would
benefit from knowing about it.