I think you said the answer right there: a link to another page of a form is still a link if it’s going to another URL. And is that modal button triggered with JS? If so, <button> it up. The general guidelines at the top of the guide are a good litmus test between links, buttons, and form submissions.

Wow, thanks for sharing!

<a href="..." rel="noreferrer" target="_blank"> has the same behavior as <a href="..." rel="noreferrer noopener" target="_blank">.

Just looking above you can see how much extra work faking a link is, and that is before you consider that is breaks right-clicking, doesn’t allow opening in a new tab, doesn’t work with Windows High Contrast Mode and other reader modes and assistive technology. Pretty bad!

It is absolutely astounding how many times I run into fake links. It seems every codebase I inherit is full of them. Not only that, but Google does it all the time on their nifty little applications baked into search results. It really drives me crazy.

events triggered by the space bar fire when the key is released (or onkeyup);
events triggered by the Enter key will fire the event as soon as you press the key down (or onkeydown).

I have done testing with keyboard-only and screen reader users and while they may not know this behavior, they generally react with a bit of surprise when it is not followed. If you are trying to re-create a native control, make sure the keyboard handlers correspond. A pen where you can try it yourself.

<a id=section-2></a>
<h3>Section 2</h3>

It doesn’t make sense because you can use id attribute on <h3> to achieve the same result. But there used to be name attribute and the following pattern:

<a name=section-2></a>
<h3>Section 2</h3>

But name is deprecated in favor to id now. I’d suggest expanding logical links section with a different example featuring current links in menu or paging. This is where they’re are super convenient.