I'm working on making a video game using the standalone node-webkit/nwjs and thought the clean look of Material Design might fit well for the UI. I saw the reasoning #600 was closed but @marcysutton stated:
I don't think this is a good idea anymore. If it comes up again and we can make a good case for it, we'll reopen.
I was curious if this is a good case for disabling warnings? Apologies if I come across as entitled, I'm just trying to wrap my head around this. For a web site/app, I totally get the need for ARIA. I'd like to make my game(s) accessible but some genres just ... aren't? So, having an accessible menu system/UI on top of an inaccessible game just doesn't make sense to me.
Hi, the warnings are part of Angular Material, not ngAria鈥搕hat is a separate module. I understand your sentiment, but I still don't think it's a good idea to disable aria-label warnings. It's easy to add text alternatives, and they eliminate the warnings. So why not add them, and make part of your UI accessible? Disabling warnings still isn't justified in the amount of developer time required to support it, when that "feature" would undoubtedly be used to create inaccessible web apps.
If there are bugs with the utility (like #3441), it is so much better to add support for known use cases like Angular Translate, rather than allowing warnings to be disabled completely. We want to know about those kinds of use cases. What do your buttons look like, do you have a demo? It would be helpful to see the markup and identify if there's an easy fix.
My bad re: ngAria vs. Angular Material; I knew that, just didn't convey myself properly.
I can certainly add aria-labels to make part of my UI accessible; I'm just unclear as to who that benefits in this particular situation. That is, I don't know what kind of disabilities I'd be helping. Say I'm making an intentionally difficult Quake clone. Playing it requires responsive motor skills and the ability to see fine details (to overcome the difficulty) & hear (as auditory cues will tell the player what to expect shortly). I'd like the Main & Pause menus to look like the default styled Material Design (a md-whiteframe in the center of the screen with md-buttons like Begin, Save, Load, Exit, etc. If my game already assumes the aforementioned abilities, I feel like having to add the aria-labels isn't benefiting anyone but only inconveniencing me.
I'm not sure I understand the logic that the feature "would undoubtedly be used to create inaccessible web apps". Any resourceful/lazy developer can comment out the code generating the warnings, ignore them, or monkey-patch disable them with:
var oldWarn = console.warn;
console.warn = function(arg1) {
if (arg1.startsWith('ARIA:')) return;
oldWarn.apply(console, arguments);
};
console.warn('ARIA warnings disabled.');
I looked at the code that generates them; I can't agree it'd take a lot of effort to maintain the feature. It seems like a simple change of an else to an else if to me.
Having an official solution would be nicer than hackishly disabling the warnings. I think they already serve their purpose: "Hey, you should be considerate to those less privileged." For those developers who choose to implement it, it continues to serve as a reminder to accidentally missed UI controls. For those who don't, it's just intentionally inconveniencing them with easily-bypassable console.warn spam and potentially driving them away from Angular Material.
I don't have a demo; the buttons/controls are default styled. The markup is simple and the fix is easy: add aria-labels or monkey-patch console.warn.
Just voicing my agreement with @OlsonDev
I am building a desktop app using Electron, and I have no idea how ARIA could possibly benefit any user of it?
I've read the warning, I would sincerely consider and certainly follow it if I was building a website, but I'm not, and I don't want extra console clutter.
There are contexts out there which render the ARIA enforcing strategy irrelevant.
Sorry, support for ARIA and accessibility is a core feature of Angular Material. I understand the inconvenience of seeing warnings in the developer console -- that is in fact by design. If you are committed to shipping an app that does not meet ngAria's tests for accessibility, you can still do so. End-users will not see the Dev Console warnings.
...but I'd encourage you to find a way to clear them by making your app accessible. :)
I would like to add my use case here. My project is running on embedded Linux. It would be impossible for the user to even make use of aria-labels. Besides, it's for a product that requires vision to use it. It is like adding accessibility for software running on heavy machinery.
@itsmejustind I agree. There are lots of legitimate cases where being forced to use aria at gun point is annoying as hell. I don't want to see 50 damn aria messages clogging my console either.
For anyone reaching this trying to find a solution, the best I can offer is a Regex filter in google chrome.
Add ^(?!ARIA) to the filter in your console and it will hide the junk.
@DevVersion - let's provide a global config to disable all aria warnings. It should be a manual opt-out.
Most helpful comment
@DevVersion - let's provide a global config to disable all aria warnings. It should be a manual opt-out.