For a prototype, sure, accessibility might not be top of the list. But everything about the way this is advertised makes it sound like a production-ready product ('it's a stable, rock-solid product') and your FAQs are actively misleading people by implying that it produces accessible output.

It's also orders of magnitude harder to make an inaccessible product accessible than it is to build it in an accessible way in the first place

> "It's also orders of magnitude harder to make an inaccessible product accessible than it is to build it in an accessible way in the first place"

I see so many developers these days make this mistake not only with accessibility, but also with security ("We'll make it secure once it works"; and then it never happens for whatever reason, and by the time it becomes of critical importance it'd take a near complete re-write to "make it secure"), or cross-platforming ("We'll port it to other platforms after we complete the Windows version"; and then down the road they discover they've built on top of a ton of Windows-only middleware and support libraries, painting themselves into a Windows-only corner they cannot escape without a near total re-write). Planning / thinking ahead is a super-important part of the design stage for pretty much any but the simplest of software.

I understand your point. From my point of view, people who visit our site are mostly people whom I've had some contact with or who read about us in a context like HN, so I don't feel people are being misled.

I could be more clear about the product being a prototype — we talked about it amongst ourselves, and decided that it would be better to be as positive as possible in presenting the product.

I seriously doubt that anybody who uses it will be confused in thinking they're building something they're not.

I have a hypothetical question — where does one draw the line when introducing a new technology? A text-based website can be fully accessible, but a movie is not held to the same standards. You don't (as far as I know) create a separate version of a movie with less flickering, or less movement, to enable more sensitive people to be able to enjoy it.

If I am creating a new type of technology that enables animation or other effects, I feel as though I am responsible to handle accessibility as well as possible, but without sacrificing the final product.

I'm probably repeating myself at this point… if I had my way, I would be writing a new editing program to produce hybrid SVG/HTML pages, where the accessibility and other text-oriented issues wouldn't even come up.

However, I don't have the time or the funding right now to write a new editor, so I'm attacking it as best I can with the only program that works, Adobe Illustrator.

IF I can get users, and IF I can get funding, then it will be relatively easy to add accessibility features. Despite what you say about orders of magnitude harder to add accessibility after the fact, these pages are relatively simple.

Right now I could write a script to convert SVG to HTML based on text size and placement on the page. I haven't done it because there are more basic issues like page resizing that need attention, and because I felt that building animation would be more likely to generate interest than saying "look, you can build boring SVG sites that are completely accessible!"

Anyway, I appreciate your taking the time to write. I will try to include more context in our future communication.

Along with the "What about accessibility?" FAQ answer being misleading about the current state, I have two additional concerns:

- Special text only for screen readers: This should not be a primary method of making a site accessible. Hidden text is often incorrect, or maybe it was correct and then someone updated the page and it no longer matches. Out-of-site, out-of-mind is unfortunately often true in this case, and should really be more of a last resort.

- Accessibility is about so much more than screen readers. My first concern for a platforms like this is people who struggle with animations - either feelings of vertigo or nausea, or just finding movement very distracting. Are prefers-reduced-motion settings respected? Does this encourage authors to create content in a way that has a minimal motion fallback that still works? Is it easy for users to stop animations?

Unfortunately, the accessibility challenges here are significant. I'm sure work will be done later to try and improve it, but you will be limited by previous decisions to patching in solutions as best you can. And that rarely results in a truly usable, accessible experience.