anchor-has-content and aria-label / title tags?

[brandonburkett]

JAWS 11+ and ChromeVox has the ability to read aria-label as well as title tags on anchors. Wouldn't this satisfy the "anchor-has-content" requirement? Example usecase is a background image for "scroll to top".

Thank you in advance!

[ljharb]

Without having visible text on that link, how can you guarantee the image is understandable (to a sighted user, even)?

[brandonburkett]

In this case, it is up or down chevrons (user triggered programatic scrolling up or down). Shouldn't be a big deal for sighted or keyboard only users, but thought title + aria-label would cover the content req for screen reader users.

Understood it is an edge case, but it could be cool if aria-label or other attributes could satisfy the rule or we could config it to check aria-label similar how we can configure anchor-is-valid (with specialLink) to support Link with to="".

[gregwhitworth]

This isn't an edge case, this is accessible content and is in accordance with the name computation which all browser should implement and pass to the relevant AT upon event firing. Specifically section D from computing text alternative:

Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

Personally, I think if you're going to have a rule that determines the a11y of contnet via rule it will need to follow the same heuristic that UAs do to determine name computation which has to take into account styles, markup and content.

I hit this same issue on my site using, here is my usecase:

The markup is the following:
<a href="https://github.com/gregwhitworth" target="_blank" rel="noopener" title="follow me on github"></a>

Upon using a screenreader - tested with both NVDA & Narrator - you hear "follow me on github". Now to your point regarding images for understanding the chevron - that statement holds true for ALL imagery on the web. This content is accessible and the chevron that @brandonburkett provided is a common UI/UX paradigm that users are used to.

I think a bare minimum change here is to look at anchors and see if they have a non empty title, aria-label attributes.

Thanks :)

[ljharb]

Hmm, seems like a keyboard-only user might not see that title popup.

[gregwhitworth]

@ljharb Can you clarify for me - which keyboard users are you referring to? Because a sighted keyboard user would see the github logo, a non-sighted keyboard user would hear the description of what the sighted user is seeing.

[ljharb]

Seeing the github logo isn't sufficient to provide "follow me on github" context; they may never have seen the logo before, even.

[gregwhitworth]

@ljharb Wait, what? If a user hasn't seen the Github logo before why would they follow me on it? The page is called "Follow" which tells sighted, low sighted and unsighted users that this page is where you can follow me. If they have a twitter account they'll have heard the name or seen the logo to associate with them, thus creating a meaning to follow me there. The same holds true with Github and I don't think that scenarios where iconagraphy can be utilized the argument for "users not knowing" what the UI/UX paradigm means suffices for it is/isn't accessible.

To understand you completely, you're saying that this content is not accessible because it doesn't have the word "Font Size", "Bold", "Italic", "Quote", "Code", "Link", etc underneath of them?

[gregwhitworth]

@ljharb One thing I would like to add - even though you and I disagree here - I appreciate your effort in this and think what you're striving for is good; it just doesn't align with the spec and to some extent will almost be impossible to define a heuristic for since some of the meaning will be provided by surrounding content and context.

Thanks for your time.

[ljharb]

@gregwhitworth i'm saying that i shouldn't have to click on the link to understand what it's for. And yes, in general, textless iconography is pretty much always a crapshoot in terms of how accessible/intuitive it is for all users - if i have to hover over it with a mouse, or hear it with a screenreader, or "try it and see", to know what it does, it's not good design.

Note that I'm not contesting at all that the spec allows this, nor that perhaps this plugin should - I'm pushing back on the use cases.

[gregwhitworth]

@ljharb My issue is the contesting for "good design" - according to your statement if I add the name "Github" somewhere visually then the content is now accessible and good design. But that is just as ambiguous to a user that does not know what Github is - they are not aided in seeing the name "Github" nor "Facebook" or "Twitter", as it's a lack of knowledge of these things that is making them ambigous, not that they aren't accessible by AT. And with that I'm not sure how to resolve it besides adding in a very long description that details what Github and Facebook are.

Note that I'm not contesting at all that the spec allows this, nor that perhaps this plugin should - I'm pushing back on the use cases.

Oh, I thought that's what you were doing. I think it would worthwhile to follow the name computation specification in this case. I apprecaite your feedback on my usecase and design of them. I'm going to leave this thread now :)

[ljharb]

No, I'm saying it should visibly say "follow me on github" so i know why i want to go to github. I also am more likely to know what github is than i am to recognize the logo. I agree that if i don't know what github is, i won't care, but the logo isn't enough info for me to decide that.

[bkardell]

This is maybe not a super helpful comment...

I really wish there was a hard/fast answer here, and feel like some of what we consider passable is merely a legacy problem we've created for ourselves. For example, @gregwhitworth's example of toolbar formatting buttons in a WYSIWG editor more or less maps to what happens in the aria practices example - nevertheless, I regularly find myself not being able to interpret icons, even in those contexts, and when it is not evident to me how to access the text that I know is available for screen readers via the keyboard or touch screen, I find this personally rather frustrating and unfortunate.

That said, I think I do feel like the only thing you can say for sure here is that it must have an accessible name and while even that is impossible to do 100% accurately from just looking at source code, there are a bunch of ways to get it and it feels like considering any potentially valid accessible name does still catch the more definitive 'thing' you can say with the least false positives?

[backwardok]

Given that the spirit of this rule is that links have an accessible name, I think it makes sense that there's support for aria-label and title given that it's part of the calculated name, as @gregwhitworth has mentioned previously. It's worth pointing out that a lot of iconography can make more sense in context, and that highlighting them out of context here naturally can make it seem like there is insufficient information for a user to know what that icon means. That's not to say that there shouldn't perhaps also be extra affordances for users on what the iconography means, but that providing an accessible name via aria-label or title should be valid under this specific code check.