Does aria-label prevent the inner content being read out by assistive devices?

Question

The MDN docs say you should use aria-label like this:

<button aria-label="Close" onclick="myDialog.close()">X</button>

I don't have access to a screenreader, but I've seen comments on Stack Overflow suggesting that an aria-label does not replace the inner content, it only prefixes it. So in the above case it would read out "Close X", which is obviously not ideal.

Is this true? If so, what's the solution? I'm guessing it would make sense to wrap the inner content with an [aria-hidden=true] element, like this:

<button aria-label="Close" onclick="myDialog.close()"><span aria-hidden="true">X</span></button>

...but I'm cautious because I can't test it on a real screenreader.

Answer 1

In most situations, the aria-label will be read out instead of the link's text.

This is actually a standard test scenario, and has extensive test results on powermapper: https://www.powermapper.com/tests/screen-readers/labelling/a-aria-label/

On the test results page, you can also hear the screen reader output.

Answer 2

FINAL EDIT

Instead of relying on blog posts or misinterpreting specs, I think it's better to actually test things rather than come to a conclusion and trying to remember everything about ARIA.

You can test what the accessible name of an element is, for eg if you use Google Chrome (hopefully other browsers include accessibility testing tools):

1. Open dev tools (eg F12 on Windows).
2. Select the element (with the pointer or ctrl + shift + c )
3. Click the Accessibility tab (here you can view the Accessibility tree, ARIA attributes and Computed properties.

Answer 3

This is what happens in Microsoft Edge and Internet Explorer, using the Windows Narrator:

• When the Narrator is reading the text and finds a button in the middle of it, aria-label is in fact prefixing the content, like this:
  [content before button] [ aria-label value] [text inside the button tag] [content after button] .
• When the user focuses (or clicks) the button, the narrator only says the aria-label value, and not the content inside the button, like this:
  [ aria-label value] "button".

Hope this helps.

Answer 4

I came across this while fine-tuning an app to better support the JAWS screen reader.

I hope to help anyone else who comes across this question by pointing out that macOS has a perfectly functional screen reader built in called VoiceOver (VO) which can be activated with cmd+F5.

Alternatively, macOS users can install Windows ( https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ ) through free software like VirtualBox ( https://www.virtualbox.org/ ), which is perfectly adequate for testing with the likes of NVDA and even JAWS if you or your organisation are willing to pay for the licence fee.

The moral of my answer is that you CAN just hop over to a Windows machine to check it works not just on a screenreader, but also the myriad Windows web browsers that I'm sure a varying percent of your visitors use - web dev DOES work like that.

UPDATE: while I understand the down votes due to my answer not actually answering callum's question, I feel comments such as on "Mar 22 at 11:41" have a negative impact on the community and need addressing. If I have opened just one developer's mindset to cross-OS and accessibility testing it was worth it.