Requests for comment/Clickable section anchors

This is a request for comment regarding clickable section anchors.

Background
Currently, by using wikimarkup such as == Hello ==, it's possible to create an HTML header (in this case, an &lt;h2&gt;). This header can be referenced by an HTML id (in this case, the id would be "Hello" and the anchor would be "#Hello"). Currently, besides the table of contents box (if it's present on the page), there's no way to easily retrieve/re-use this anchor.

Considerations

 * The hover state is not sufficient ("dying") due to use on touch screens (iPads, smartphones) etc.
 * What's dying is these simple minded approaches. Always optimise for the appropriate platform and take best practices into account. There is nothing wrong with hover. For accessibility a focus and click event should be attached as well (which automatically makes it work on touch devices) and one can further optimise for touch devices by supporting it with a click-and-hold, drag, press/click, swipe or whatever makes sense. --Krinkle (talk) 02:42, 20 January 2013 (UTC)
 * What's to say that in the future touch screens on such devices won't support hover states when your finger is near the screen (and not pressed yet)? Lack of support for hover might just be a transitional period for this type of devices, it's hard to say.
 * The [edit] link may be replaced by an icon or be moved to the other side.
 * RTL and LTR must be considered in any implementation.
 * Some headers on wikis contain links to other pages or URLs.
 * Mobile has collapsible headers with (dropdown) arrows and functionality applied, interaction design solution needs to consider this.
 * [edit] --> [edit | edit source] on VisualEditor enabled wikis; is this still true anywhere --VEckl (WMF) (talk) 02:33, 24 March 2016 (UTC)
 * Some users get annoyed with animation as they scroll down/through an article
 * Screen readers should not be affected negatively, as in reading an anchor link element out loud on every heading – compare Option 1 and 2. Uncertain about Option 3
 * Balancing discoverability and distraction, also ensure color contrast is WCAG 2.0 level AA

Option 1
Another [bracket] element for the anchor link.

 Header &#91;#&#93; edit

 Header &#91;#&#93; edit

Drawbacks:
 * Added complexity next to every header, when we want to draw focus to the [ edit | edit source ] links.
 * Adding to that contra argument, the edit link is the most important link for the concept of a wiki, it has and should have an exceptional position in the user interface. --VEckl (WMF) (talk) 01:42, 23 March 2016 (UTC)

Option 2
Toggle visibility of a clickable symbol (paragraph: ¶, link symbol:, ..) in the content margin when hovering a heading.

Seen on:
 * Here on MediaWiki, using the HeadAnchor gadget (1st section, last item). (MediaWiki:Gadget-vector-headanchor.js and MediaWiki:Gadget-vector-headanchor.css)
 * Python documentation
 * GitHub repo readme

 Header edit

 Header  ¶ edit

Drawbacks:
 * How would click-to-togggle-visibility work for touchscreens?

Option 3
Just make the header a link? This would be trivial to implement, presumably.

 Header edit

Drawbacks:
 * some headers already are or contain links.
 * degrades readibility
 * typographically "bad"
 * Inconsistency between this (a link which links directly to itself), and all other wiki links.