Material: getting aria-label missing warning on input with aria-labelledby

[opadillaintegrify]

version 0.11.0
Console shows:

ARIA: Attribute " aria-label ", required for accessibility, is missing on node:
<input ng-model="question.Number" type="number" aria-labelledby="intQuestionCompleteTimeLabel" ng-change="setMinutes()" class="ng-pristine ng-untouched ng-valid md-input" id="input_9" tabindex="0" aria-invalid="false">

HTML:

<div flex>
            <div id="intQuestionCompleteTimeLabel" class="int-label">{{question.Label}}</div>
        </div>

        <div layout="row" layout-align="start center">
            <md-input-container flex>
                <input ng-model="question.Number" type="number" aria-labelledby="intQuestionCompleteTimeLabel" ng-change="setMinutes()">
            </md-input-container>
...

It shouldn't be throwing that warning.

[EladBezalel]

Please provide a CodePen or Plunkr that demonstrates this issue. Here are some starter demo templates that you can use/fork:

• CodePen template
• Plunkr template

[opadillaintegrify]

http://plnkr.co/edit/PK9Bip

This one shows the warning getting thrown on an md-button with aria-labelledby set.

[opadillaintegrify]

http://plnkr.co/edit/tinBqF?p=preview

This plunkr shows the warning getting thrown on an input type=number with aria-labelledby set.

[marcysutton]

That's definitely a valid use case, it just isn't supported yet–the utility only checks for aria-label. It could check for aria-labelledby and validate it matches an ID in the DOM, though that would require walking up the tree a bit. If that proves to be too costly for performance, it could naively check for the attribute but not validate it.

[bathos]

Ran into this with md-select, too. For the time being, should I just ignore the material warning, or is using aria-label alongside adding aria-hidden to the original text (that would then be duplicative) a sensible workaround?

[lyschoening]

+1

[ManishaSBhalerao]

You need to add a label to the input or add a placeholder. It is just searching for the input definition.

[osv]

I have same problem with ngTranslate in next situation:

        <md-button ng-click="vm.edit(vm.model)">
          <span translate="WZ.EDIT"></span>
        </md-button>

[bathos]

@osv This issue is about lack of support for cases where aria-labelledby is used instead of aria-label, but I think what you're describing might be a different problem?

@marcysutton I think the ID check sounds reasonable; isn't ID the least expensive of all selectors? The naive check would be okay too, but as a person who has accidentally screwed up IDs for things like this in the past, I think the non-naive check could be helpful.

[ThomasBurleson]

This issue is closed as part of our ‘Surge Focus on Material 2' efforts.
For details, see our forum posting @ http://bit.ly/1UhZyWs.

[rainabba]

Wow. 2017 and I'm seeing the same issue, landed here researching, only to find out this issue goes back more than a year and based on what @ThomasBurleson shared, it looks like this is because Angular 1.x was set aside for Angular 2 (which like many others, I'm not messing with).

Perhaps it's time to revisit this issue? My console looks absurd with all these ARIA messages (from md-checkbox and md-select).

[rainabba]

Thanks to the following, I've at least quieted the console: https://github.com/angular/material/issues/3441#issuecomment-249796426

[EladBezalel]

@rainabba the best solution is to solve the aria issues, and not ignore them.

This still might be an issue and in case that's bothering you, we would really love your help and will appreciate a pr.

[rainabba]

@EladBezalel I don't know what the "aria issues" are though? I'm not doing anything with Aria. Every instance of md-checkbox and md-select throw these errors as the OP indicates. Since I don't know anything about "ARIA" nor am I trying to use related features, I wouldn't have a clue where to start debugging.

[EladBezalel]

So i suggest you to read about it - ARIA@MDN

TLDR; Accessibility, all various of people use your app, do it.

[rainabba]

I think you misunderstand. The ARIA issue is with the components, not my code (disregarding the discussion of whether I should be implementing or not). I am not trying to use ARIA. The components/directive is. Since I'm not familiar with ARIA, I'm not going to be effective at troubleshooting THIS code and whomever is responsible for these components messing with ARIA would be best to investigate. Someone who knows something about it would be better still. Since I don't care about it at this point (or that it's spamming my console), quieting it is fine with me.

[marcysutton]

I think the OP was noting the label warnings didn't respect aria-labelledby, which is a valid way to expose an accessible name for interactive controls. If you have aria-labelledby on an element and you're still getting the warnings, that sounds like a bug. The utility originally only checked for textContent and ariaLabel, IIRC.

If you have no labeling at all and you're getting the warnings, try adding labels to them and see if that clears it up. You can try verifying them with the aXe chrome extension: https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

[EladBezalel]

@marcysutton Thanks for jumping by!

@rainabba ARIA is not a problem with the components, we require to have aria properties on all our input components and buttons so it will be accessible to whomever needs, also it's REALLY easy to use and the best way to not getting this errors is to actually use ARIA and not mute it..
This issue with aria-labelledby is important and i encourage to get a pr for supporting it.

[bathos]

@rainabba

I am not trying to use ARIA.

From the Material Design perspective, that’s a bug. It’s issuing warnings for that reason.

Since this stuff is kind of tied up with an ethical stance, "I don’t care about this, I want to turn it off" may not generally be met positively, though there are certain cases (e.g. some video games) which use web technologies for UI, but can’t really be made accessible in a meaningful way. From your description, though, it sounds like your input elements may just be missing corresponding <label> elements or aria-label properties.

This ticket is about a specific case where there’s a false positive for the warning, not about suppressing the warnings themselves.

[rainabba]

Back to this today in another code-base. I hear what you guys are saying about accessibility, but that's not the point here and I feel the point is being missed. Harassing users and developers in the console is not a productive or useful way (especially as noisey, cryptic and unreadable as that message is) to encourage or enforce productivity.

TL;DR

Feel how you want, but the fact this conversation is happening proves it's a real issue. In my opinion, there isn't more conversation due to the fact that prior to this issue being filed, there was nowhere to discuss such an issue because nobody has ever done something like this in a major library.

TLDR; Accessibility, all various of people use your app, do it.

As has already been pointed out, some apps aren't concerned with accessibility for good reason. In my case, our users quite literally CANNOT require anything providing visual assistance because they COULD NOT do this job as it requires handling and reading paper by the 1,000's of pages. The computer is only 1 tool needed to do the job as is the case through most of the world (outside that which developers live in and become biased by). If someone can't do one part of a job, the rest is irrelevant and so accessibility is really NOT the issue so many would like it to be made out as. Don't get me wrong, as someone who's had broken hands/arms and a leg, I appreciate the efforts, but necessity and ROI trump ideals.

Of course, many multimedia applications (such as WebVR, which I also play in) also would be pointless to enhance with accessibility meta so I think this practice is further demonstrated to be far too aggressive.

If you guys want to continue to be the first to use this approach, at least make the message more meaningful. For someone not using (or needing) ARIA, that message couldn't be more cryptic and unhelpful. Perhaps provide one of those awesome, enhanced errors messages that link back to the Angular site with details from the error.

Until then, perhaps you can explain why this behavior exists (supposedly because accessibility is so important to EVERYONE), yet so does this [helpful] behavior: https://github.com/angular/material/blob/e06284aa4745dd7323a872a0a9290fd026747e30/src/core/services/aria/aria.js#L39 ?

Seems like a contradiction that needs resolved.

[marcysutton]

@rainabba are you unable to accomplish something specific with disableWarnings, or do you have a recommended update to the error message? I don't understand what you consider to be unresolved.

[rainabba]

@marcysutton Sorry. I was able to "resolve" the issue using the disableWarnings function, but twice now I've come up on this, had to research, then add code to stop the warnings from making a mess of my console.

Perhaps provide one of those awesome, enhanced errors messages that link back to the Angular site with details from the error.

Here is an example of what I was referring to there. Such a link that landed me on a page saying something akin to...

"You're here because we have a VERY strong opinion on you failing to use the aria-label attribute on one of our md- components."

...then explain what is expected to resolve the warning either by implementing the label per some accessibility docs (and link) OR by using the disableWarnings function.

That would at least have saved me the time of googling, creating (or contributing to in this case) a github issue, figuring out what's going on with Angular, Material Design, Aria and this error, etc......

The irony here is that the method being used is totally counter-productive because it's encouraging the quicker fix (so I can do my job) and wastes time I could have been putting towards learning and implementing the latest accessibility practices.

[marcysutton]

I don't think there's anything to fix here then. The feature isn't going to be removed, and you have an affordance to disable the warnings. A framework has to support a lot of different use cases (and encourage accessibility)–if you have to toggle an option to get it to work the way you want then that's a fair trade-off. Or, you could just label your buttons.

[rainabba]

@marcysutton Can't help but notice how we could swap a couple words here and this is like any other religious "discussion" where one side has tunnel vision based on their values and the other is trying to explain how the rest of the universe (and most people) don't really care except when the spotlight is on them. Question is, which of us is really which here :)

I'll leave it at that. Regardless of what we think, the fact that someone can now search the "warning" and find this thread quickly (unlike when I first hit the issue last year) means most developers who hit this are already far better off.

[marcysutton]

Accessibility is about disabled people not being able to use the internet, it's not a "religious discussion". Frameworks have a responsibility to encourage accessibility–the disableWarnings option came about based on feedback from folks like you.

To keep this on topic: would a better error message make this feature better? I genuinely want to know. It was difficult to sift through the rest of your comments, which contained many opinions.

[marcysutton]

Also @rainabba, you should open a new issue for the error message thing if that would help. This issue was related to aria-labelledby not getting picked up, as we mentioned multiple times.

[heck4]

Here is my solution for resolving this without disabling warnings. I'm using Angular 1.4.8.

<md-checkbox aria-label="." ng-attr-aria-label="{{input.label}}" ng-attr-id="{{input.id}}" ng-attr-name="{{input.name}}"><span ng-bind="input.label"></span></md-checkbox>

The aria-label="." attribute is a temporary placeholder that the warning logic feels is a non-empty label. This is later replaced in the digest cycle using the ng-attr-aria-label attribute.

For whatever reason, I couldn't get ng-attr-aria-label to run before the warning logic ran, so I used the placeholder as a workaround.

[marcysutton]

@heck4 have you tested it to make sure the aria-label works with assistive technology? If you've got a demo somewhere I could take a look.