If you own/manage this project: install the Axe browser extension[2], run it on your site, go "...oh...oh no..." and then unfortunately, take accessibility seriously and get to revising =/
Accessibility is very important, and you wouldn't want to use a palette like this as a default theme, but that doesn't mean everything has to pass every test. Many apps allow people to change themes and there's nothing wrong with offering a less-accessible one.
Personal theming (how a user themes their own tools) has no accessibility requirements. At most, this site probably should include a warning that this theme may not be suitable for some users and should be avoided if your visual needs require more contrast than the theme provides.
If they attempted to extend this to be used for public sites, then yes, it's not fit for that purpose.
...can't you just use an accessibility extension to change the color scheme of a website? This seems like a solved problem. Extensions have been able to swap CSS for ages now.
It is not the responsibility of thousands of individuals with accessibility needs to each cobble together their own solutions on a per-website basis. That would be truly ridiculous. It's why WCAG was created: so that site owners have guidelines that they can follow, and tools they can use to check compliance. If you're designing something that you want the world to use "for interfaces", then you are on the hook for making sure it passes WCAG, too. If it's a side project that you don't intend to maintain, then sure ignore WCAG as much as you want, but that is not the case here.
And, of course, you can get away with not being 100% compliant (no one can be, it's a well known limitation of WCAG) but in this case things aren't even compliant with respect to the main selling point: the palette. It's failing basic things like contrast ratios, so even people who you wouldn't even call "disabled" or "having accessibility needs" are going to have issues with this scheme (we've normalized visual disability so much that barely anyone even realizes that having glasses is literally a disability, requiring medical corrective devices) which is pretty disappointing in 2022.
There's also the wheelchair ramp analogy, but I don't think that's the same since web technology is already accessibility-friendly without publishers having to do anything. User agents can completely change the style of any web page, so they are effectively wheelchair accessible.
I admit I don't know much about accessibility issues, so maybe there's something obvious I'm missing here?
Don’t put the disabled in the position where the website itself takes extra steps just to be usable for them, old 90 year old grandma Betty with failing vision is never going to figure such things out and saying “lol just figure it out” isn’t good enough. Those extensions that repaint websites with a new color palette are ugly as crap and buggy, and anybody with the attitude their website doesn’t need to follow WCAG by default definitely hasn’t actually checked such extensions actually work. The burden of trying to make sure every such extension is compatible is dramatically harder than just making the site accessible to begin with, the entire approach is bad design, it’s harder for everybody. What you’re doing is less building a wheelchair ramp and more leaving a pile of lumber next to some stairs, building the wheelchair ramp would mean having an accessible theme be the default and maybe the OPs theme be an alternate.
The analogy I would make is actually round doorknobs vs door levers/handles. If you pay attention you will notice you don’t see doorknobs on new public buildings and that’s because of issues like arthritis. Yes somebody might aesthetically prefer doorknobs but that doesn’t justify their installation in something used by the general public. It’s fine for a PRIVATE website to be as inaccessible as you want, but not a public one.
It's always funny when people get on their virtue bully pulpit and then immediately go to ageism. Nice work.
> The analogy I would make is actually round doorknobs vs door levers/handles. If you pay attention you will notice you don’t see doorknobs on new public buildings and that’s because of issues like arthritis. Yes somebody might aesthetically prefer doorknobs but that doesn’t justify their installation in something used by the general public. It’s fine for a PRIVATE website to be as inaccessible as you want, but not a public one.
So I as an independent developer am responsible for this in all of my public code? That's asinine. My home is catered to me, if people want to visit me in my home I am not going to change my door knobs, fix my windows, redo my concrete, etc so it can happen. It's mine and out of the charity of my heart I am letting other people use it if they need it.
Where do you draw the line? It sounds like you want FAANG to be the only game in town given they're probably the only people with the budget and bodies to fulfill all of your requirements. I don't see someone repackaging firefox as "firefox with accessibility", or using an add-on, as an undo burden on taking advantage of a service voluntarily provided, and most importantly does not compel you to use it.
I'm a horrible ageist because I think vision related accessibility features are especially important for older people. I am morally below you.
>It sounds like you want FAANG to be the only game in town given they're probably the only people with the budget and bodies to fulfill all of your requirements
Have building codes caused the independent contractor to go extinct?
There are various ways to scale accessibility and make it easy like building it directly into UI toolkits, frameworks, etc. In fact the criticism in this thread isn't aimed at Joe developer making a small website, it's somebody making a tool that many developers will use that will break their sites functionality. I care much more when somebody is making inaccessible tooling that's bad than I do when an unskilled developer doesn't know how to design an accessible UI.
I don't expect every website made by every developer at every skill level no matter how old or niche it is to be accessible, I'm not insane. Yet contrast has to be one of the absolute easiest parts of accessibility (compared to say making a site screen reader compatible) and most of the excuses for not caring about it are exceedingly lame. Even for NON-DISABLED users low contrast is a hallmark of bad design and a site that's difficult to actually use.
That's my point: websites don't need any adaptations to work with wheelchairs (with "wheelchairs" being accessibility extensions/settings in this analogy). If you bring your own wheelchair, it will work with every website.
That's not true in the real world, so having laws for it makes sense.
> Don’t put the disabled in the position where the website itself takes extra steps just to be usable for them, old 90 year old grandma Betty with failing vision is never going to figure such things out and saying “lol just figure it out” isn’t good enough.
I'm not sure how to respond to this. First of all, you don't need a custom an extension per-website. You can install one extension, and it will work the same for all websites. You might not even need to install an extension, because Windows, Mac, iOS, Android, and even Gnome and KDE have tons of accessibility features built-in.
Furthermore, there are some tech-savvy grandmas out there. If Betty isn't tech-savvy, then her grandchild should've set her PC up for her. If she has failing vision, she's not going to be able to use the computer/phone at all unless someone enabled a magnifier/voice assistant/increased the font size.
> Those extensions that repaint websites with a new color palette are ugly as crap and buggy, and anybody with the attitude their website doesn’t need to follow WCAG by default definitely hasn’t actually checked such extensions actually work.
You're making a lot of assumptions here. "ugly" is personal taste, although I do think most designers would consider enormous fonts to be "ugly as crap", but it's what's required for people with visual impairments.
Also, just because a website isn't adhering to WCAG recommendations doesn't mean they didn't test it with accessibility extensions. Maybe there aren't enough resources to build a WCAG-compliant design, but a designer on the team can make a few minor tweaks so that they work well with popular accessibility extensions/features.
> What you’re doing is less building a wheelchair ramp and more leaving a pile of lumber next to some stairs, building the wheelchair ramp would mean having an accessible theme be the default and maybe the OPs theme be an alternate.
I don't think that's an accurate analogy. Like I said, a browser extension doesn't need to be customized per-website to be work. A person with disabilities is going to enable accessibility features on their device (or someone else will do it for them). Depending on the situation, that might include a browser extension as well.
...but again, I don't know much about accessibility issues. However, this response hasn't convinced me that it's unreasonable for web devs/publishers to expect users with disabilities to bring their own extensions/accessibility features.
Accessible design is beautiful design because function is the essence of beauty though. Any website that excludes part of the public is hideous. Websites that need their disabled users to execute sketchy arbitrary code to fix a UI that is physically hard to use are badly designed. "lol just run an extension" is something that sounds very simple but is FAR more complicated if you care about things like security and compatibility and aesthetics. Disabled users should get the same experience using your website, the same aesthetics, and the same security as your other users.
I don't accept rationalisation of inaccessible design in actual developer tooling or websites with a substantial amount of users. The damage caused to the disabled quickly exceeds the convenience afforded to developers once you're hitting user counts in the thousands.
I have never said "lol just run an extension". That's completely dismissing/ignoring my argument, and kind of disrespectful. It doesn't seem like you're actually trying to have a productive argument, especially since you're calling your own argument irrational:
> I don't accept rationalisation of inaccessible design in actual developer tooling or websites with a substantial amount of users ...
So if you're just trying to get into an internet slap fight with somebody, go do it with that other guy.
As a comparison, more than a third of people in LA county speak Spanish (http://www.laalmanac.com/population/po47.php). It would not be reasonable for supposedly public communications to be only available in Spanish for the #aesthetic, and to tell the 60% of the population that doesn't speak Spanish to kick rocks – and these numbers are better than the portions we're talking about.
Compare insurance designed around the idea that an expert is going to need to design an assistive technology setup: optical insurance so a professional can tell me my prescription. Or the "wheelchair" comparison: even with ramp requirements, using a wheelchair involves ongoing management by a doctor over a user's often lifelong use. (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7384540/)
There isn't a professional service that exists to unbreak the display of websites that could just have been made properly contrasting in the first place, and... there shouldn't be.
Most modern devices come with a setup process that guides users through setting up accessibility features. Extending that to installing third-party browser extensions is...complicated to say the least, but I think that's a far more effective solution to this problem than simply hoping that every website will adhere to some accessibility guidelines.
Web standards were created to be accessible basically from day 1. The user agent (web browser/client) is in control of how a website is displayed, and the user is able to change it however they want. Whether that's 10x font sizes, or increasing color contrast, it just takes a few lines of CSS (which an extension can add automatically).
> As a comparison, more than a third of people in LA county speak Spanish (http://www.laalmanac.com/population/po47.php). It would not be reasonable for supposedly public communications to be only available in Spanish for the #aesthetic, and to tell the 60% of the population that doesn't speak Spanish to kick rocks – and these numbers are better than the portions we're talking about.
I don't think that's a good example because government communications are different from private entities. Nobody has to eat at a spanish-only restaurant, and anybody can learn to speak spanish. If that restaurant doesn't speak english, then the free market will force them out of business... and if it doesn't, well, then whose to say it's not a good idea?
By contrast, a person missing both legs can't just learn to walk, so not having a wheelchair ramp is just fucked up.
> There isn't a professional service that exists to unbreak the display of websites that could just have been made properly contrasting in the first place, and... there shouldn't be.
Sure, but the likelihood of every website adopting accessibility standards is basically zero. Investing in a powerful set of accessibility tools/extensions seems much more impactful IMO than trying to coerce and/or force developers to adhere to some standards that are likely not a silver bullet anyways.
It's hard for me to square the above (my own experience) with your assertion in this thread that Nord should (essentially) not exist in its current form. If it went away or changed significantly, that would be a loss for me. I hope it stays the same, because it may not be perfect for everybody in the world at once but it is pretty close to perfect for me, at least, and I know I'm not the only one.
Now, I'm obviously talking about UI themes in the context of applications where the user can easily select different themes according to their preference. In contexts where that's not possible, application developers should aim for a design that's usable for as many people as possible, and though I don't know much about WCAG I assume it's a great way to achieve that. The question is, what is Nord supposed to be used for? Are its creators pitching it for one-size-fits-all UIs?
You strongly imply in your comments here that the answer is 'yes', but just from reading over the website linked by OP I disagree. Their pitch is somewhat vague, but lines like "Nordify your digital home" and "unify the appearance of your favorite applications" seem to say the opposite: that it's primarily intended for personalization, and not meant to satisfy the accessibility needs of everybody.
I think that's okay. Evidently having a wide variety of UI themes available, not all of which comply with WCAG, has made my life better wrt. my own (minor, IMO) disability. I don't take offense when others publish and use UI themes that don't work for me; rather, I appreciate the fact that I'm free to do the same according to my own preferences.
Heading down this path, while valiant, must be done carefully. Otherwise, Google/Apple/Microsoft/Amazon etc will be the only people with the budget to allow for full compliance to every possible disability that may effect the use of their product. I'm not convinced you understand just how much time and energy it takes out of actually delivering a product on a limited budget (in Nord's case free).
Your use of "alienate" has venom behind it that makes me think you're implying they do this deliberately to spite people with disabilities. Occam's razor.
You really need to have actual humans with disabilities look at your website to find out if it works for them.
So, wether it meets guidelines for web uis is completely irrelevant.
"Created for the clean and uncluttered design pattern to achieve a optimal focus and readability for code syntax highlighting and UI components."
There's a whole section dedicated to installing it in UI applications.
How about: "I personally don't like the palette"