For whoever is interested in this, here's code analysis:

• Vimium excludes all elements matching [aria-hidden=true],[aria-hidden=""]
• some pages use a blank and transparent <a aria-hidden> as a cover of a card
  • I think their intent is to make the whole card become clickable for a real mouse
  • usually, the card also include a normal <a href> behind the cover <a>, to make screen reader happy
  • but a side effect is the behind <a href> won't get hover effects (like the underline on mouse hover)
  • some website turns to use CSS rules to simulate such underline
• before v1.65, Vimium shows hint markers for behind <a href>s.
• since v1.65, when Vimium tries to find topest elements, it gets the cover <a aria-hidden>, and this element is not the behind <a href>, so the behind one is thrown away.
  • some other buttons (e.g. the "like" button) are also excluded by this rule

What Vimium C does now: its master branch now skips an [aria-hidden] element if its children is empty, and then behind <a href> might be matched as wanted - not ensured, though.

Why does Vimium exclude aria-hidden elements? In my experience, sites tend to use it to hide content for non-visual assistive programs (screen readers). But Vimium is a visual tool, so I think it makes sense for Vimium to not care about aria-hidden.

(In my own extension, Link Hints, I don’t care about aria-hidden and I have not noticed getting worse hints because of that. BTW, I also use .elementFromPoint and do get a lot of hints in the problematic sites mentioned above, so I think this is fixable in Vimium without reverting.)

According to specification https://www.w3.org/TR/using-aria/#fourth , [aria-hidden="true"] should never be on focusable elements, so the fact is that those websites have misused this feature.

Great discussion everyone, thanks for the help. So there are two proposals: hint elements with aria-hidden=true, or mimic Vimium C's more complex change (commit). I'm inclined to just start ignoring aria-hidden because it's a simple and understandable strategy, and leans towards false positives rather than false negatives, as @gnarendran suggests. @gdh1995, is there a prominent case that motivated you to implement the more sophisticated "cover detection" logic?

I tried this out in #3505 (take it for a spin) and the guardian and google news are much more usable now.

Um, it's just because I didn't what it would be if aria-hidden check was removed, and I'm used to add lots of checks to hack few elements.

@philc I tried #3505 and it seems good (didn't notice any missing hint) when used on guardian.co.uk and news.google.com. There are slight differences from 1.64.6 like some hints being positioned at any given link's image (if present) rather than its text, but I guess one will get used to it! Thanks a lot for looking into this. Regards.

Closing this now that I've merged #3505. Feel free to resume discussion if you find undesirable effects. Thanks everyone!