[whylo]

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

[blooalien]

> "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.

[AndrewSwift]

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.