As for the rest, I'm frustrated because you're partially right but also kinda defeatist and that makes me sad.
I went checking and found a long history of discussion about accessibility in Godot's GUI toolkit (because the Godot editor is built in the Godot engine). It's an active topic, spanning multiple tickets over years. Their stance has evolved dramatically over time, but they appear to be putting real effort into improving the situation. Here's what I think is the current tracking ticket: https://github.com/godotengine/godot-proposals/issues/983
Accessibility isn't a feature of Godot...yet, but it's obviously something that's important for mainstream adoption of serious software, especially non-audio-visual experience software. And it's obvious that people in the community care and are both asking for it and working on it.
If anything we need to keep doing this and revisiting it over and again and keep improving it, testing it, giving feedback, contributing. Because for as many applications that wouldn't benefit from this approach, there are as many that would.
Maybe what the community needs is a real-world application which would benefit from these accessibility features to help drive adoption and development.
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
Screen readers can still (badly) work on web sites that haven't been made with accessibility in mind. And if you find you need to add proper accessibility to a web or native app, you can. With something like godot, you might have to rewrite the entire GUI to get accessibility working properly.
> - Using Electron does not give you accessibility in any way.
Yes it does. Electron gives you basic out-of-the-box crossplatform support for accessibility, just like chrome. And you can tweak the screen reader output the same way you would a website. See: https://www.electronjs.org/docs/tutorial/accessibility
> - What laws?
EU: According to the first google result, by September 23 2020 all websites and mobile apps must be accessible to everyone, have a public accessibility policy, provide a feedback mechanism for users to report inaccessible content and provide a link to the enforcement procedure:
https://siteimprove.com/en-au/accessibility/eu-web-accessibi...
California (govt): As of July 2019 all websites made by the state of california must be accessible: https://www.levelaccess.com/california-passes-new-digital-ac... . There's similar results at the US federal level.
> - I don't know of any business doing general purpose commercial applications that has faced any issues with that.
You don't know anyone who's faced issues yet. Momentum behind these laws is growing in most countries, bolstered by the 2008 UN Convention on the Rights of Persons with Disabilities - which requires countries to "Provide information in accessible formats and technologies appropriate to different kinds of disabilities in a timely manner and without additional cost". In the US and Canada the law currently only requires government websites to be accessible, but its not a safe bet to assume things will stay like that.
We are talking about web apps, not web sites.
> the screen reader output
The screen reader is not supported or useless on most web apps.
Again, we are talking apps and their GUI (web and native), not sites or documents.
> With something like godot, you might have to rewrite the entire GUI
Again a "might". I don't see any reason why you need any "rewrite".
> laws
Those are not for general purpose commercial apps as I wrote, only for public or specialized apps.
> You don't know anyone who's faced issues yet.
So then it is fear mongering, aka FUD.
> Provide information in accessible formats and technologies
Information, not GUI on apps.
Public information, at that.
It is simply impossible to require at the moment accessibility for web apps or native apps.
It does not even make sense for a huge amount of software. For example, an image editor or the vast majority of games cannot be accessible for a blind person with current technology.
Accessibility is critical on information and documents, not on common apps. That is why things like websites using fancy web frameworks just to display text is bad because they tend to break it. Nobody is discussing that, you are conflating apps with documents.
Forget about the fear-mongering - think about the actual people with disabilities though.
If you're in the public sector, or have customers in the EU or Australia, you might get sued or fined if your app isn't accessible.
Weirdly even in the US you might not be in the clear for internal tooling. My understanding is its illegal to refuse to hire a blind person because they're blind. If you hire someone who's blind and they can't do their job because your internal tools are written in Godot, you might be leaving yourself open to discrimination suits. Not a big deal when you're a startup, but it will matter at google / fb / etc. I'm sure google has blind employees today who care a great deal about being able to do their jobs.
That sounds like a legal minefield, with more mines added over time.
In short, if you aren't making a video game or a toy, it seems like good advice to use tools that work with accessibility.
(I am not a lawyer. This is not legal advice.)
1. There is no law on the horizon that will require any accessibility for general purpose commercial apps.
2. Further, one can add accessibility features on Godot or other engines if needed. No technical limitation whatsoever.
3. If such laws came to be in a decade or two, engines and frameworks of all kinds will most likely support those features on their own.
4. The only case you can make against Godot is that someone has a company which hires people; and finds a blind person that is as productive as a non-blind to the point they are the best candidate for the job; and the company is in a country with such laws; and someone is an asshole that does not want to hire such person even if they are the best; and the position requires to use Godot tools; and the tools are non-accessible to begin with; and that someone does not want to spend the money to make them accesible; and the rejected candidate sues you and wins the case.
No business will even think about such an scenario. In an ideal world, they would. In the real world, they don't. And I am siding with the blind person in such a case and hoping such a company is busted in that case. But the case is extremely rare.
Even if they widen the scope, EU commercial laws on this kind of thing (e.g. content filters) tend to be only applied to companies over a certain revenue level (10m euros for the content filters).
Also, EU regulation is enforced differently to US regulation. EU regulators tend to ask nicely the first time, and only impose fines if it's a repeat offence, or the company has flat-out refused to do anything about the problem.
In other words, even if the regulation scope is widened, anyone building their GUI with Godot will probably have enough revenue and be given enough time to rebuild it completely before they'll reach the point of "business-killing" fines.
<of course, being accessible is a good thing in its own right, and I'm glad Godot appear to be doing something about it>
The Americans with Disabilities Act, however, is applicable to private businesses; though (unless things have changed recently) there is currently an unresolved three-way split in federal circuits about high it applies to website with the Third Circuit saying it doesn’t, the First, Second, and Seventh Circuits saying it does generally, and the Sixth, Ninth, and Eleventh Circuits splitting the difference and saying it does if their is sufficient nexus between the website and a physical location of business, and the California State Courts seem to (in applying the state Unruh Civil Rights Act, which includes among it's triggers ADA violations) holding that it is at least applicable in the nexus case.
Fairbanks points out that there's risk in every design. How much it should influence your architecture depends on how much it matters to your project.
He uses the example of installing a mailbox. You shouldn't approach that with the same level of planning you'd use to architect a building. They're similar projects in some sense, but risk with the former is so much lower that it isn't worth it.
In this case, for some projects, the risk of low accessibility might be significant enough that it should be high priority. For others, dependency churn or framework bloat might be higher. Or tooling capabilities. It depends on what you're building.
No biggie if one of them is opengl based and might be expensive to add accessibility to it...
Oh, and stop spreading fud in general, you might use an accessibility-friendly toolkit and still end up with a practically unusable for visually impaired ppl UI, just as you can make a custom coded UI screen reader friendly...
Just be honest, accept that UI dev will eat up at least 50% of your resources if you wanna do it right, don't cheap out on it, embrace re-writes and maintaining multiple versions of similar functionality things, and stop being afraid of new tech...
I haven't learn much about Godot yet (but I will after this post), but Flutter solved accessibility in declarative widget UIs in a way that might be a good example for others.
Isn't this also the case with Google's Flutter on iOS by default?
The solution is, as far as it is possible, to add accessibility to these frameworks.
Something somewhat common in videogames is to add one or several colour blindness colour palettes to the games.
I don't like this constant reinvention of wheels. Look at Blender, it also has its own, mice UI and many other specialized graphical, image and audio apps have. Flutter also renders its widgets.But none of them is as universal and flexible as those big, battle-tested frameworks.
They are no shortcuts, proper UI is a complicated thing.
For quick, simple UIs, you may like Tk or Python's module Tkinter [1]. It is capable of creating pretty fast UIs with little code. Gitk [2] Git UI is written in Tcl + Tk.
[1] https://www.tutorialspoint.com/python/python_gui_programming...
In addition to the tracking issue mentioned elsewhere, I'm also aware of this project which has the goal of improving accessibility within Godot--both for playing games made with Godot and also for making games in Godot (which is one benefit of the editor being built with the engine itself):
Nothing in software is irreversible
>>Godot doesn't display native widgets, so it has no support for accessibility,
Then it would be better to evangelize adding accessibility support into Godot.
>If you want to use this in a business, either for an internal tool or for an application you sell, this is a horrible idea. There are some laws mandating accessibility, a
That largely depends on the type of application and the target. There are some LOB applications that would never need accessibility because the jobs they are for require sight and/or hearing for safety reasons. For example if you are building a LOB application that is used on Factory floor with large machinery
If you're making something for free or for fun, then let curiosity guide you. Bureaucrats like yourself can comment all you want. I'll be making applications.
Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
> Do you know of cases where not implementing accessibility really did become a big financial hazard?
"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
The 50 lawsuits, filed in November, say the colleges are in violation of the Americans With Disabilities Act, as their websites are not accessible to people with disabilities. Camacho uses a screen reader and said he experienced barriers when trying to access the colleges' websites."
Source: https://www.insidehighered.com/news/2018/12/10/fifty-college...
What if tomorrow some change of parameters makes my business impossible? I'll go out of business. That's always an option.
Dealing with every possible risk ahead of time generally isn't an option.
> "Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
This is referring to public websites, which arguably are covered by the ADA.
I'm looking more of a story like "We wrote all our software without regards to accessibility. Then we got sued. It bankrupted us."
If this was a real problem for software in general, why is there no cottage industry of shady lawyers using people with disabilities to sue software vendors in particular? There's obviously lots of software that is not accessible, or not accessible enough.
Yes and no one can sue you for going out of business. But you can be sued for violating a law while your business is in operation.
> Dealing with every possible risk ahead of time generally isn't an option.
No you need not if you use standard software development tools that do it for you. You would need to worry about it if you plan to implement everything on your own.
> If this was a real problem for software in general, why is there no cottage industry of shady lawyers using people with disabilities to sue software vendors in particular? There's obviously lots of software that is not accessible, or not accessible enough.
When there is a clear law that states that you have to make your software accessible you have no choice but to implement accessibility. For personal use you need not. For open source projects, the implementation rests on the shoulders of those using the project for end-user facing software. You can get away with it for a while, just like you can get away with using pirated software. But then law will catch up anyways. Just because there is no precedent set doesn't mean that it is legally allowed. Would you want to be the first test case? A scapegoat? I bet not!
As far as why there are no cottage industry of shady lawyers: Maybe those shady lawyers have bigger fish to catch. Maybe there isn't much awareness about it in the legal circles. Could be variety of reasons why.
The belief that you just need to use "standard toolkits" and accessibility "just works" is wrong.
> When there is a clear law that states that you have to make your software accessible you have no choice but to implement accessibility.
There is no law that mandates implementing accessibility for all commercial software.
> As far as why there are no cottage industry of shady lawyers: Maybe those shady lawyers have bigger fish to catch. Maybe there isn't much awareness about it in the legal circles. Could be variety of reasons why.
...or maybe the law doesn't actually say what you think it says.
Toolkits provide you the tools to do accessibility right. Toolkits don't do your accessibility for you. That is the biggest difference. You just misunderstood what I said.
> There is no law that mandates implementing accessibility for all commercial software.
Wrong! It applies to all software. Period.
"The Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design in September 2010. These standards state that all electronic and information technology must be accessible to people with disabilities.
The ADA differs from Section 508 regulations, which are an amendment to the Rehabilitation Act of 1973 and apply to all information technology, including computer hardware, software and documentation."
In fact, the DOJ clarifies it further that accessibility is paramount and that even though the regulatory process isn't complete on paper doesn't mean that the software should remain inaccessible in the meantime.
'"The Department is currently developing regulations specifically addressing the accessibility of goods and services offered via the web by entities covered by the ADA. The fact that the regulatory process is not yet complete in no way indicates that web services are not already covered by title III."'
Source: https://www.interactiveaccessibility.com/services/ada-compli...
> ...or maybe the law doesn't actually say what you think it says.
It does. Read it.
In that case the main complaint seemed to be that they had more of an obligation because they were receiving federal funding.
1: https://www.nytimes.com/2015/02/13/education/harvard-and-mit...
2: https://www.thecrimson.com/article/2019/12/2/Harvard-settles...
Not sure what are you saying here. Are you saying that while it might become a law, companies that can't find the money to comply don't need to comply in such cases..? Or that it hasn't happened yet, so it's not bound to happen?
I'm asking.
Often times, people make claims based on what they think should be happening. That doesn't mean it is happening.
Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform.
This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).