HTML Child / The Page as a Contract
What happens when something fails to arrive
Networks drop, images do not load, and decoration goes missing. A well described page degrades gracefully.
It is tempting to design as though every part of a page will always arrive. In practice, parts of pages fail constantly: an image times out, a font never loads, a stylesheet is blocked, a script errors on a device you never tested. The question is not whether this will happen but what the page does when it does. A page whose meaning lives in its description keeps working, in a plainer form, because the description is the first thing to arrive and the least likely to fail. A page whose meaning lives only in its appearance simply stops making sense.
This is the practical argument for correct structure, and it is a good one to hold onto if the accessibility argument feels abstract. If the decoration never arrives, an honestly described page falls back to a readable column of text with a working outline, real links, real controls and real form fields. It is plain, but it is entirely usable. The same content described dishonestly falls back to an undifferentiated wall of text with clickable things that no longer look clickable, headings that are no longer larger than anything else, and lists that are indistinguishable from prose.
There is a related habit worth adopting: build the plain version first and enhance it afterwards. Write the content, describe it correctly, check that it is usable with nothing added, and then add appearance and behaviour as improvements to something that already worked. This is the reverse of the usual instinct, which is to build the finished appearance and then wonder how to make it robust. Starting plain is slower to look impressive and much faster to finish, because you spend no time repairing foundations that were never laid.