Thank you very much! 🧡

My pleasure, I'll fix those tests. They all passed for me locally so I'll take a look unless you're aware of any specific reason they're failing. they're fixed now.

@kivikakk sorry, automerge got disabled when I pushed the fix to the test.

No problems :) thank you again!!

@davemackintosh I'm a little confused by this change. Doesn't this make the header link unusable? From my testing there is no way to grab the link to that specific header.

GitHub doesn't add header links in their issue description/comments, but they do in rendered files, like a README. Today I can hover over the Related projects link in the comrak README and copy it's link so that I can paste it here: https://github.com/kivikakk/comrak#related-projects

But from my testing, inert kills that ability.

Exactly which accessibility tools are having a problem? I do think there are some things that need to get done to make header accessibility better, but I'm not sure this one is correct.

We've been discussing this exact problem over in GitLab (with screen readers, as mentioned in the original issue here #573), where we're seeing the same problem. It's been inactive for a couple months, but we actually need to get back to it.

Thanks for bringing this to our attention, @digitalmoksha!

I am not the target audience for screen readers (my accessibility needs run the "other" way; it's hearing I struggle with), so I will need to rely on your (pl.) experience and connection with users to determine the best solution.

In the meantime, should we revert?

It's my understanding that this prevents screen readers from incorrectly jumping about as clicking to the anchor gives the target focus and the inert property prevents the focus. I'm happy to be wrong about this though.

The problem is indeed as @digitalmoksha describes it; the anchor is intended not only as a destination, but a clickable element which links to itself. This permits end-users to get an easy reference to that anchor.

Here's an example as seen on GitHub:

With inert, the anchor and anything within it (the 🔗 SVG on GitHub, for instance) cannot receive events and cannot be interacted with.

Might it not be sufficient to set aria-hidden="true" on these anchors instead? This would exclude them and their children from the accessibility tree (as inert does) without affecting their usability from this point of view.

The aria-hidden="true" is already added to those links in

There was an idea about putting the text inside the link

Change

<h2 data-sourcepos="5:1-5:18" dir="auto">
  Expected result
  <a href="#expected-result" aria-hidden="true" class="anchor" id="user-content-expected-result">
  </a>
</h2>

to

<h2 data-sourcepos="5:1-5:18" dir="auto">
  <a href="#expected-result" class="anchor" id="user-content-expected-result">
    Expected result
  </a>
</h2>

I don't know if that would fix it or not. I'm failing at really testing this out on my system.

Another idea is was using aria-labelledby on the link, but would require the id to be moved from the <a> to the <h2>

<h2 data-sourcepos="5:1-5:18" dir="auto" id="user-content-expected-result-text">
  <a href="#expected-result" aria-labelledby="user-content-expected-result-text" class="anchor" id="user-content-expected-result">
  </a>
  Expected result
</h2>

I do think we will need to revert this while we find a better accessibility solution.

The aria-hidden="true" is already added to those links

hah. Good on me for checking first.

I will revert. I think we need a clearer idea of what unpleasantness is being caused --- i.e. what actually is happening for screen reader users, as I'm still unclear on what the original issue describes ("can't handle the anchors [...] as they retain focus when you go to them"). Does it mean the reader doesn't continue automatically after following an anchor? (I am assuming this would be desirable.)

I wonder if moving the id to the heading element might be a solution, if it means the anchor doesn't take focus and prevent further reading. But again, I am not the target demographic, I do not use the software in question, and we need discussion with affected users to understand and improve the situation.

In the meantime, you can add this snippet to your website to naively (enhance to your own desire to avoid false positives) remove the inert attribute

document.querySelectorAll("a[inert]").forEach((node) => {
  node.removeAttribute("inert");
});

@kivikakk I see you made the revert. Should we cut a new release?

Indeed :) Done; v0.40.0 (!).