The end result is a link after each heading with a clear description for screen readers, but only show a # (or whatever you want) visually. Makes sense!
So first pass ended up looking like this:
A potential issue with this pattern is that if that markup ends somewhere that you don’t control the styling like an RSS feed or browser reader mode, those links will be visible in their entirety. Here’s an example heading in NetNewsWire:
Or in Safari’s Reader View with only “#” visible, which is a little weird:
None of these are deal-breakers, but I started exploring alternatives.
Turns out after I initially implemented this, Amber updated her original article with an alternative markup pattern where you make the entire content of the heading a link, like so:
That has simpler markup, a larger click/tap target, no additional elements to worry about in other contexts, and the accessibility seems reasonable. The one drawback is you can’t put another link inside the heading, but I don’t really do that here, so that pattern seemed like a win.
One problem: here that is in Safari Reader View, or more precisely, isn’t there because now it doesn’t render those heading tags:
Well that’s worse! It’s not just me as you can see that same pattern in action on MDN Web Docs or the The Web Almanac and those pages don’t have headings in Reader View either.
(I’m checking in Safari 14.0.3 on macOS 11.2.3, for what it’s worth.)
That worked! Although it isn’t a link, the heading content is back in Reader View:
I futzed around with it some more and it seems like the class on the span isn’t necessary. Just so long as the link has any other element around the text, it seems to show up in Reader View. So, the final pattern you want is: