Question about accessibility concerns (u-mention)

[brycewray]

Lighthouse downrates "mention-of"-type webmentions beginning with <a class="u-mention" with the following message in the Accessibility category:

Links do not have a discernible name
Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users.

I have mitigated similar problems with the webmention images with aria-label= HTML, but it appears the <a class="u-mention" stuff — which, in my particular case, is rendered in ${mention.content.html} — is pre-injected with the content.html item from the JSON supplied from brid.gy by webmention.io. So, is there a way to augment the received content.html on the receiving end (other than altering the received JSON which, of course, would last only until the next time it's accessed)?

The specific page where I saw this is https://brycewray.com/posts/2020/05/battle-ios-email-heavyweights/. The HTML that Lighthouse complained about is:

<a class="u-mention" href="https://brycewray.com/posts/2020/05/battle-ios-email-heavyweights/"></a>
<a class="u-mention" href="https://buff.ly/2Apdj8Z"></a>

... and the original JSON returned is:

{
      "type": "entry",
      "author": {
        "type": "card",
        "name": "andrewcanion",
        "photo": "https://webmention.io/avatar/pbs.twimg.com/ee30c20aac4cc016ecf5355185bf9764ce6f446109ceb81d7a27fbb3c1cf1ae3.jpg",
        "url": "https://twitter.com/andrewcanion"
      },
      "url": "https://twitter.com/andrewcanion/status/1261291376626434053",
      "published": "2020-05-15T13:44:32+00:00",
      "wm-received": "2020-05-15T14:22:40Z",
      "wm-id": 796662,
      "wm-source": "https://brid-gy.appspot.com/post/twitter/BryceWrayTX/1261291376626434053",
      "wm-target": "https://brycewray.com/posts/2020/05/battle-ios-email-heavyweights/",
      "content": {
        "html": "If you want power email management on your mobile device, this is the review to read.\n<a class=\"u-mention\" href=\"https://brycewray.com/posts/2020/05/battle-ios-email-heavyweights/\"></a>\n<a class=\"u-mention\" href=\"https://buff.ly/2Apdj8Z\"></a>\n<a href=\"https://twitter.com/brycewraytx/status/1261067012031369216\">twitter.com/brycewraytx/st…</a>",
        "text": "If you want power email management on your mobile device, this is the review to read.\n\n\ntwitter.com/brycewraytx/st…"
      },
      "mention-of": "https://brycewray.com/posts/2020/05/battle-ios-email-heavyweights/",
      "wm-property": "mention-of",
      "wm-private": false
    },

So I guess I'm wondering whether there's some API-related way to auto-add HTML that would mitigate automated tools' concerns about accessibility in this and other, similar cases. Thanks!

[snarfed]

hmm! sorry for the trouble. if i understand this right, the problem is that you're rendering bridgy's webmention source html directly on your site, verbatim - via webmention.io - and lighthouse is complaining about the links that don't have link text?

generally the burden of rendering webmention content into good HTML falls on the receiving site, including sanitizing it, making it accessible, etc. afaik webmention.io does some sanitizing - aaronpk/webmention.io#13 - but probably not other modification for accessibility etc.

for this example specifically, here's the source tweet:

the "empty" links are both to the link in the quoted tweet,
https://buff.ly/2Apdj8Z. i could put the actual buff.ly/2Apdj8Z in the link text, but then it would show up twice in the actual comment text, directly after If you want power email management on your mobile device, this is the review to read., which isn't really right here.

at a higher level, bridgy's source webmention HTML itself is primarily designed for computers, not people, so when it hits a tradeoff like this, it prioritizes compatibility with webmention receivers such that the resulting webmentions displayed on the receiving sites look right.

so, i'm not sure i see a concrete change here i'd make. feel free to suggest something though! also cc @aaronpk.

[aaronpk]

Is there some sort of aria attribute to tell browsers or screen readers that this link should not be navigated to? That'd be the simplest thing I could think of to fix it. I don't really have anything I can do on the receiving end for this either, except for maybe just straight up removing <a> tags that have no text inside, but that feels wrong.

[brycewray]

@aaronpk @snarfed All good points. I suppose the simplest answer (and perhaps the best, also) would, indeed, be to go with the text-only version.

[snarfed]

aww, that would be sad! the links and other formatting markup on the HTML are valuable and useful. don't throw them out just for an automated tool's complaint that's imho spurious anyway!

[aaronpk]

I think the best thing here is for bridgy to include aria-hidden on those empty <a> tags to indicate that they do not have any human-meaningful content. (I'll likely have to update webmention.io to allow that attribute through its sanitization process but we can get to that later.)

[brycewray]

@snarfed I’ll think about some options before I go there. 😄 The original versions of the code I borrowed for this purpose had some HTML-sanitizing functionality but I decided — for reasons I don’t fully recall now — to avoid using it; perhaps I can reevaluate that.

[snarfed]

@aaronpk sure! will do.

[brycewray]

@snarfed @aaronpk Much obliged, gentlemen!