Notes from the a11y underground #2

a tortoise in an enclosure

Things that caught my interest since Notes from the a11y underground #1:

That’s almost it for #2, but first a question: feel free to provide your answer as a comment on this article.

See the Pen
read more links
by steve faulkner (@stevef)
on CodePen.


Categories: Development

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Stomme poes says:

There is a pattern I’ve been seeing, very often for “cards” (those large clickable lumps of crap, usually organised into a list, which tend to contain a buttload of content, often with various semantic markup): Developers continue to wrap anchors around these huge piles of text, then throw an aria-label with what would normally be decent, concise link text. However this overrides the buttload of text inside, which sighties get to read.

I’ve also seen, though less often, similar for paragraphs in cards even when a link is not wrapping everything, like on our national train website.

When they don’t use an aria-label, then users get superlongbooksworthoflinktext,sometimes with or without the semantics depending on how the AT deals with stuff inside links. I’ll fail long pages of prose as link text because that makes figuring out where the hell the link goes extra difficult for a group of users simply because they’re using text-to-speech software. Links should ideally be succinct and tell me clearly where the hell it would take me should I click it.

Now currently we recommend “don’t fricking do that” and say to wrap the anchor around the bit of text serving visually as the main link text (there’s almost always something that fits the bill) and use JS or maybe a complex CSS trick to make the whole area clickable. But it seems this is not scratching an itch or developers haven’t heard of this technique as often.

Offering the ability to set something as the link label for a group and the rest of the content as-is should the user choose to go read all that seems to be something developers want, but to make aria-label do that job, behaviour would have to change and it seems it would be more complex for a browser to know whether the resulting tree should then entirely replace the link (or paragraph or whatever) content with the label. This also just seems to be a problem of people not knowing how to use the tools as they currently work to have sane names, summaries and content chunks. It seems changing things to meet this need, while maybe a cowpath-paver, is sort of like changing the laws to let drivers run red lights because lots of people do it.

Joe Humbert says:

Not totally sure because these may be abbreviated snippets of code and there may be more content in the paragraphs, but the code as is:

Interesting Articles Read more

Failure under 2.4.4 A against F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that is not related to the link

Interesting Articles Read more

Potentially still a failure under 2.4.4 A against F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that is not related to the link , but it could be argued that using the article is similar to wrapping in a paragraph or list H77: Identifying the purpose of a link using link text combined with its enclosing list item & H78: Identifying the purpose of a link using link text combined with its enclosing paragraph and therefore passes