See my reply to whylo: I agree wholeheartedly that accessibility is important, but I can't devote engineering resources to it until I have a product that's compelling in its own right.

SVG is XML, a screen reader would be able to access it.

Just being XML doesn't make something accessible - I tested with a screen reader and found a lot of issues: https://news.ycombinator.com/item?id=33520364

It's actually worse ;-) because the pages are constructed in Illustrator, the order of text is all messed up.

Elements that are drawn first are higher in the SVG, but that only means that they're in back in Illustrator — not that they're higher on the page.

It's pretty common to have a page where the header of the page is modified last, making it the last element in the SVG.

Right now our planned solution will require server-side analysis of text size and placement.

More long-term, we will use HTML for text and SVG for everything else. But that will require an editing program that doesn't yet exist.

You can set the tabindex property on SVG elements just like you can do on HTML, then you could setup an understandable navigation.

The point was that this kind of page is not invisible to screen reader but you still need to think about accessibility and put some effort into it, just like a normal html page.

Thanks for the tip, I will look into it. I didn't know that was the case.

It will actually be pretty easy to set up.

I don’t doubt it, that kind of issue with navigation sequence is easy to mess up if you don’t prioritize it. I just meant that it being SVG is not inherently invisible to screen readers in the way that Flash was. It still means that they need to put some effort into organizing the navigation.