I used Wt about a year ago for an application at work. I was able to write a GUI program that could be accessed at a web address or with a native Qt application, and Wt was equivalent enough (API-wise) that I was able to template between the two. Really neat actually. There was one place where the GUI was defined and you could choose whether you wanted web, native, or both! Only stumbling block was when I needed some opengl (webgl), but with a fairly minimal abstraction I was and to get that working in both two.
Wt felt very polished and worked exactly as I expected.
The Qt port for WebAssembly still has zero accessibility support, e.g. for blind people with screen readers. Assuming Wt is using standard HTML form controls, it shouldn't get in the way of accessibility. Of course, the app developer still needs to follow good accessibility practices, such as labeling images and not conveying information through color alone.
While it is unfortunate, in 30 years of software development that has never been a requirement for the projects I have been involved unless the customer was some kind of governmental institution and made it part of the acceptance criteria.
So unless there is a mindset change, that will keep happening.
Maybe the mindset change has to come from developers. That is, maybe developers are obligated to implement accessibility regardless of what the customer says. Remember, this isn't just a checkbox on a compliance form; it determines whether some people can do their jobs, complete their education, access essential services, etc.
Depends pretty much on your jurisdiction, then in many countries even if that is required by law, trying to make a lawsuit out of it will lead nowhere, as most countries aren't so lawsuit friendly as US.
Assuming that there is a court willing to hear it, probably by the time it reaches the first audience there is a new website in place.
Unfortunately the Qt demos all take 8-10 seconds to load on a phone for me and several of them fail with out of memory even on high end devices like a Pixel 4 XL. Certainly I'd expect a Pizza Ordering app to work on mobile (and to not show a flash style loading spinner for 10 seconds).
WT is doing all the logic server side so the client ends up being lighter weight and will work on more devices, and with better performance.
A lot of the comments question the use case but I think your story captures the ideal use case, a hybrid C++ / web app where you want to or need to share some of the functionality between web / c++ sides
It's not a bad way to build a web interface for a C++ application that needs to be configured over an intranet. It makes tying "click on a button on a web site" to "run an administrator action on my application" very easy, and you can use your Qt muscle memory to lay out a simple admin interface with relatively little mucking about.
You can do all that with CGI scripts or whatever, but if you already have a bunch of C++ running on the server it isn't nuts to use Wt to build your CRUDy admin interface.
In addition, I have used the templating in the library and it works really well. Let the UI/UX people do their thing and get the best performing back end.
But for a modern-C++ developer, Qt is so outdated... it's based on what the language was like 20 years ago. I would really rather not be limited to writing UI that way.
Wt felt very polished and worked exactly as I expected.