About aria-hidden
Attribute aria-hidden hides the element from the accessibilitiy tree and it dominates everything else, so normally the element isn’t supposed to be read or found at all by the screen reader.
However, the button is still focusable with tab, and the screen reader has normally to find something to read when reaching the button.
At the end, you have a contradiction: the button shouldn’t be read because of aria-hidden, but something still have to be read when the button takes the focus (otherwise the user don’t know what he/she has just landed on).
Most screen readers decide to read the value or the label despite it being hidden, but since it’s a contradiction, they can choose to do whatever they want. That’s an undefined behavior, not specified anywhere officially in the standard, and won’t be ever specified since you aren’t supposed to do it.
Note that your button can be correctly reached with tab, but will be ignored when navigating by other means, for example by arrow keys, or from button to button, or when listing all available buttons on the page.
That’s an extremely confusing behavior to be avoided at all cost.
Never make a focusable element aria-hidden
About replacement text
It’s usually not a very good idea to replace a text label by another text label. Blind people won’t find it problematic, but there are other kind of screen reader users.
For example, those who have dyslexia, or some remaining sight, will be very happy to read “A” with their eyes while the screen reader would read “B”.
Those who are using voice control will also be very happy to read “A” visually, say “Press A” to activate the button and notice that it doesn’t work, because the label is “B” and you have in fact to say “Press B” to make it work.
Since “B” isn’t displayed anywhere visually, it’s impossible to guess it, unless you are also a screen reader user.
Many voice control softwares indeed base their commands on the label, and not the text actually displayed on screen. This is the correct thing to do, and it allows button icons to call them by their text label when the label is correctly specified.
It’s also not totally clear whether braille displays should display the label, or visible text. Most will take the label. Same confusing question if we imagine devices able to transcript text into sign language, or another form of expression… in any case you will confuse anyone able to read both at the same time.
Replacement text or label is meant to replace an image, an icon, or any non-text element by some readable, operable, accessible text,
not to replace some accessible text by another text.
Back to your input case
Please remove aria-hidden on your button, you should have understood by now that it’s just bad and non-sense here.
I imagine you wanted to do this:
Or this:
Which you can also do with as follows :
However, given what I explained above, you now know that it’s a bad idea as well.
If the “visible content on screen” is an image, then yes, sure, add some label ! That’s very good ! Otherwise it won’t be accessible. But if it’s already text, don’t replace it by another text.
Otherwise said,
Makes perfect sense, it’s very good ! Note that alt is preferable to aria-label in this case, per the first rule of ARIA (don’t use it unless you really need to).
But the following is a bad idea as explained above:
IF you want to have richer content than a simple text or a simple image with its alt text, you can’t do it with .
have been precisely made for that.