Why the function row misbehaves more than any other part of a keyboard
The top row is the only part of a keyboard where three separate systems get a say in what a keypress does. The keyboard firmware decides whether the key sends F6 or "volume up". The operating system claims some of what is left — F2 renames a file in Explorer, F1 opens Help. Then the browser claims more still: F5 reloads, F11 goes fullscreen, F12 opens developer tools. By the time a keystroke reaches a web page, several layers have already had the chance to take it.
That is why "my F keys don't work" is usually not a broken keyboard. On most laptops the top row defaults to media and brightness control, and sending an actual F-key requires holding Fn — or toggling Fn Lock so the behaviour inverts. If pressing F5 changes your screen brightness, the switch underneath is working perfectly; the firmware is simply sending a different code.
This page calls preventDefault() on the whole function row, which stops the page-level actions — F5 will not reload while you are testing. A few shortcuts are handled by the browser itself before any page sees them, and no website can cancel those: F12 opening developer tools in Chrome is the usual example. If a key does something instead of lighting up here, that is the reason, and the workaround is in the troubleshooting notes below.
The navigation cluster to the right of the function row has its own quirks. Print Screen is the notable one: on Windows the operating system grabs the press to capture the screen, so browsers commonly report only the release and never the press. Insert does not exist on Mac keyboards at all. If you are working through a full layout rather than just this row, the main keyboard test covers every key at once, and the laptop keyboard test is built around the compact layouts where the function row is most heavily shared.