Article idea: Why you should prefer visually hidden text over aria-label

[jmuheim]

This is a followup-post to UX accessibility with aria-label .

I can't assign the article idea label myself, so I just added it to the issue title.

---

Why you should prefer visually hidden text over aria-label

As responsible developers, we test our code. One very effective way to do this is automatic feature testing, in which a scriptable browser (e.g. Selenium) is instructed to browse your website, fill out forms, click links, and to check upon the results displayed on the page.

Scripted browsers are similar to disabled users

Interestingly, this scripted browser is pretty similar to a disabled user using a screenreader, as it perceives a website in quite the same way a screenreader does, which means: "text, text, and even more text". One of the big differences, though, is that this scripted browser doesn't evaluate ARIA attributes when figuring out the contents of a page. That's because it is a replacement for a "normal" browser, not for an assistive technology. Maybe some time in the future, there will be support for this, but at the time being there isn't.

What does this mean in everyday developer life? You should stick to traditional ways of making a website accessible and avoid the use of ARIA attributes, because ARIA introduces another level of abstraction which is hard to test.

An example

Here's an easy example: I want to have a "Download PDF file" link, in which "PDF" should be an icon.

This could look like this:

<a href="file.pdf">Download <span class="pdf-icon"></span> file</a>

For assistive technologies, I want to add a label "PDF" to the icon. This could be done with an aria-label or with a visually hidden text:

<!-- aria-label -->
<a href="file.pdf">Download <span class="pdf-icon" aria-label="PDF"></span> file</a>

<!-- .visuallyhidden -->
<a href="file.pdf">Download <span class="pdf-icon"><span class="visuallyhidden">PDF</span></span> file</a>

Now using Capybara feature testing, I want to make sure that this link really exists on my page. With the visually hidden text, I can simply do this:

visit '/downloads.html'
expect(page).to have_link 'Download PDF file'

Because ARIA introduces another abstraction layer, testing the aria-label solution is much harder:

visit '/downloads.html'
within 'a' do
  expect(page).to have_content 'Download file' # The PDF icon isn't treated as text
  expect(page).to have_css '[aria-label="PDF"]'
end

The latter isn't only more to type and looks much more cryptic, it's also not as fool-proof as the first one, because it only checks that there is some anchor tag which somewhere contains the texts 'Download file' and some aria-label 'PDF', but it doesn't e.g. check for the order in which they are. It would even pass for the following:

<a href="file.pdf"><span aria-label="PDF">Download file</span></a>

This is read by screenreaders as "PDF" only, which absolutely is not what we wanted (leading to a false-positive test). But when different developers work on the same code, things like this happen very quickly, and that's the reason why it is important to test your code.

Good intentions lead to abandonment

So because testing the accessibility layer (on which ARIA relies heavily) isn't easy, I fear that it won't be done thoroughly by the typical developer, and soon be abandoned. This would fast lead to another untested layer which was introduced with good intentions and then forgotten to maintain properly. The result would be an even more confusing experience for users of assistive technologies: it's better to have no accessibility features than smelly ones.

Conclusion

So my conclusion is to only use ARIA features when there's really no traditional way (which is independent from the accessibility layer) of doing it, which for example are JavaScript widgets (all the WCAG 2.0 "4.1.2 Name, Role, Value" stuff).

[brucelawson]

I'm not firmly against this article idea, but my gut reaction is

• ARIA is the "right" way (W3C-wise) to enhance a11y; there's good support for aria-label in ATs that real, end-users use
• this article idea is basically saying not to use the "right" way, simply because one testing tool doesn't support it

I think it would make an interesting personal blog-post but not an article on dev.opera

cc'ing @Heydon (as it's a follow-up to his post and he knows more than I do about support for ARIA)

[jmuheim]

I absolutely agree with you in general. But my main intention in this post is to warn that using the "right tools in the wrong situation" will lead to more bad than good.

ARIA is a great thing as it provides solutions to problems that couldn't be solved before. But to advertise ARIA to be used in profane examples (as @Heydon's post could be interpreted) there's a very high risk that more harm is created than problems are solved.

Also, while at the time being there's no official way to hide elements visually in CSS and the well-known workaround for moving elements out of the viewport seems more like a hack than a solution, there's an (unimplemented?) CSS property speak which would allow setting content to be muted aurally (speak: none). So there seems to be awareness that something like hiding content visually needs to be possible, and just moving this problem to another accountability by relying on ARIA and introduce another layer of abstraction and complexity seems dangerous to me.

And still: ARIA isn't as widely supported by assistive technologies as one would hope today, so sticking to traditional solutions can't be wrong at the time being.

[Heydon]

I don't follow. You describe ARIA as "dangerous" because of not universal support and instead intend to focus readers' attention on the broadly unimplemented "speak: none" technique which - if it actually did anything - would solve a completely different problem (?)

The reason that a standard technique for visually hiding something but not to AT does not exist is that, in almost all circumstances, it should not. "Normal" users and AT users should consume similar content. The techniques I describe with aria-label are mostly supplementary or enhancements for a non-visual medium. I tend to avoid a parallel or separate experience using non-visual user agents.

"Sticking to traditional solutions can't be wrong in the time being."

You just argued against progress per se. When does the time being cease to be the time being?

Sent from Samsung Mobile

-------- Original message --------
From: Joshua Muheim [email protected]
Date:
To: operasoftware/devopera [email protected]
Cc: Heydon Pickering [email protected]
Subject: Re: [devopera] Article idea: Why you should prefer visually hidden text over aria-label (#271)

I absolutely agree with you in general. But my main intention in this post is to warn that using the "right tools in the wrong situation" will lead to more bad than good.

ARIA is a great thing as it provides solutions to problems that couldn't be solved before. But to advertise ARIA to be used in profane examples (as @Heydon's post could be interpreted) there's a very high risk that more harm is created than problems are solved.

Also, while at the time being there's no official way to hide elements visually in CSS and the well-known workaround for moving elements out of the viewport seems more like a hack than a solution, there's an (unimplemented?) CSS property speak which would allow setting content to be muted aurally (speak: none). So there seems to be
awareness that something like hiding content visually needs to be possible, and just relying on ARIA and introduce another layer of abstraction and complexity seems to dangerous to me.

And still: ARIA isn't as widely supported by assistive technologies as one would hope today, so sticking to traditional solutions can't be wrong at the time being.

—
Reply to this email directly or view it on GitHub.