Comment by whylo | Hacker News Reader

Comment by whylo | Hacker News Reader

Parent Full thread

From the FAQ:

> Svija pages are fully-readable by screen readers, and you can add special text for each page in Svija Admin, visible only to screen readers.

I tested the accessibility with a keyboard and screen reader. With a keyboard, when you press the tab key, focus should usually go left-to-right, top-to-bottom. On this page the first link you tab to is 'Request Access'. From there the tab key goes backwards, to FAQ, Examples etc, then up to Vibe, Blazing Speed etc. Then it jumps down to the footer, does the same reverse order, then jumps all over the place.

The buttons in the main content to trigger animations aren't focussable at all, so aren't accessible without a mouse or touchscreen.

I explored the page with NVDA (a free screen reader) and found a number of sections and links where what was read out was different to what was shown in screen. It looks like you have a hidden HTML DOM that's exposed to screen readers and I assume this is out of sync somehow with what's on screen? I also got a bunch of links that didn't appear on the screen at all.

Exploring with the NVDA elements list (Insert+F7) shows a lot of junk in the Links list - links with text like 'id1584143858', 'UCmfF3YOMVyRcd0m-WpMUZ2g' etc. The Buttons list doesn't show the animation trigger buttons (because they're not marked up as buttons) and the Landmarks list is empty, meaning no easy way to jump to nav, header, footer etc.

Browser zoom is completely broken. The page looks the same at 500% zoom as it does at 100%.

Accessibility is important, and it's really disheartening when new page-building platforms like this pop up that clearly haven't been audited by an accessibility specialist or run past a disabled person who uses assisitve technology, especially when they specifically give the impression they're accessible as the FAQ answer does

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.

Right now I'm just trying to make an interesting platform to explore what's possible with SVG.

Please believe me that when we are able to move forward, accessibility is very high on our priority list.

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.

Thankfully not _quite_ as broken as the days of Flash

Reply on news.ycombinator.com