Why is this always the first comment on any new UI library that's in a beta level release? I get it, there are blind users, but they're honestly less than 0.1% of the population.

A good UI library should definitely be accessible once it's in a mature release, but that's a fair bit of extra work to do up front when things are likely still in a state of flux; and since there's no guarantee there's even sufficient interest in Yet Another UI Library to get an upswing in usage, it's very possible no blind user will ever be exposed to a site powered by this in production at all, ever.

I'm not trying to say we should ignore blind people overall, but this comment is always in the top spot on every single new UI library and it's rather tiresome. How about some actually constructive criticism on the structure of how this library actually works?

> A good UI library should definitely be accessible once it's in a mature release

I doubt that you can add a good accessibility layer after everything else is done and the absence of a plan is telling. Which is fine, if the author doesn't know or doesn't care, it's ok, it's his time and his project after all. But if you plan to build something with it you should question yourself: "is it accessible?".

In my opinion the parent question was perhaps a bit harsh but legit.

>How about some actually constructive criticism on the structure of how this library actually works?

Well, accessibility is deeply about how it works, not so much something that can be tacked on afterwards.

Plus I think this is something constructive to consider.

"More than 3.4 million (3%) Americans aged 40 years and older are either legally blind (having visual acuity [VA] of 20/200 or worse or a visual field of less than 20 degrees) or are visually impaired (having VA of 20/40 or less) (Eye Diseases Prevalence Research Group, 2004)."

The percentage goes up sharply with age.

My daughter is a power user with a retinal disease. Being constantly marginalized as an unimportant case kinda sucks.

It's undeniably true that accessibility is a basic necessity rather than a feature. But is it fair to expect accessible features on an experimental technology?

it's fair to expect them to talk about how accessibility can be added, whether they do so immediately or not.

It's fair to bring it up.

Exactly. Accessibility is a huge investment of time and adds a lot of technical debt if done incorrectly, really doesn't make sense until the entire library is somewhat mature and starts being ised in production at large enterprises. Can't believe OP is complaining about screen readers in a beta release.

IMO, it's just a formulaic, virtuous sort of comment. An easy bikeshedding criticism. That's why we always see it on everything.

Again, me and you and everyone else definitely want production apps to be accessible! And yeah, it might rule out the selection of an immature library like this one for a larger scale project that has more concerns about missing out on the potential user base that have accessibility concerns. Fair enough.

I'd say it's too late then. You have to make at least some assumption beforehand, otherwise you'll have to rewrite huge portions of your lib. Sorry, I kindly disagree.

It's like adding unit tests AFTER you've written everything. Just don't do it.

>It's like adding unit tests AFTER you've written everything. Just don't do it.

Funny you say this, because that's exactly what I do :)

I don't start unit tests on a new project/library until I flesh out most of the major components as I'm sure I'd be rewriting things multiple times as I'm iterating in the beginning. My guess is this method isn't uncommon....

Yeah, I know - that's how it's mostly done. I guess a Mish-Mash might make some sense? Because, often, I see people in my team creating "ConsoleApplication1"-kind of projects, so that they can build their components and already test them. That's when I mostly say "write a Unit test instead."

According to a 2011 study by Google, there are on average more people with just low vision/blindness online than there are Canadians online, and visual impairment is just one kind of disability.

Are you saying that being a Canadian is a disability????

It looks like it's very similar to Vue, except that instead of <script type="application/javascript"> it's <script type="application/x-go"> and the special HTML attributes are prefixed with "vg-" instead of "v-".

That is: It's lower-level than something you would ask to support ARIA standards. It will support them if the markup you write for your Vugu components supports them. Vugu doesn't ship any built-in components or anything.

There is nothing in the Vugu project which will prevent proper accessibility standards from being used (as others here have mentioned it will output whatever you ask it to). It's a valid point that examples should include such features where relevant.

Considering it outputs what you tell it to output, you can add aria-* all you like. This doesn't have a corresponding UI component library, it's a lower-level library for creating components.