I’ve been thinking about this a bit and the main concern I’ve had is around accessibility. The web has had a lot of iteration over time to make it relatively easy to build applications that are well suited for use with screen readers and other assistive technologies. Have you done any testing along those lines with the Godot UI tools?
There it is. Thanks. I agree, accessibility should be considered. It's actually extremely difficult in mobile games as engines like Unity have almost no accessibility support whereas UIKit does a really fantastic job.
In any case, I'm definitely for making a site mostly accessible (I've encountered edge cases where it is weird) and if current screen readers support most JS, then I'd test for accessibility, not necessarily all-stop lack of JS.
Unfortunately on the topic of accessibility you're likely going to need to design for people, but build your site to validate. I don't have much experience using screen readers, but from what I can tell they're going to need at minimum well build HTML.
A tool like this might produce a UI that looks right on the surface. But what about things like accessibility (e.g. for blind users with screen readers) that even many human developers don't get right?
Ensuring that websites are accessible is important work. I used to work at a company where the CTO personally dedicated several sprints to refactoring the display layer code to better support screen readers. From what I remember, it was a bit of a tedious process, but nonetheless one appreciated by all of their customers who had disabled staff.
Tools like this could save a lot of time and make the web more accessible.
I wish there was a unified back end for accessibility that screen readers could plug into and other accessibility automated tools.
Their domain use cases are close in use but not the same. However, automation for testing has money behind it. Perhaps the use case could be bridged where both domains could benefit.
This looks cool - is there anything about accessibility testing - how well it works with screen readers for example? I couldn't see anything in the docs.
That you for this valuable advice! I have to admit that I have never worked on accessibility before (apart from writing meaningful HTML). Will definitely look at improving screen reader support when I get to it.
You could try to integrate it with whatever a screen reader does to read the text on buttons to its user. As a bonus, all your UI tests double as accessibility tests.
I'll break out a Win10 PC and give it a shot, although it seems like ipads and iphones get most of the accessibility credit. I was also fooling around with those sorts of features on a Chromebook.
I can't help but wonder if simply reading the screen is the wrong answer. It's as if the important thing is to understand the screen and then explain it without the need for any visual/location kind of concept. Another angle would be to write a completely audio-based alternative interface for important websites.
No doubt people a lot smarter than me have spent a lot of time on these issues, but I'm pretty dissatisfied with what I've seen so far.
Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps more accessible, that many developers miss? And secondly, do you know of a way to quickly simulate the experience a visually impaired person has without learning/using a screen reader? (As a solo developer, I don't have the time to dive too deep)
80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perform the manual testing need to be experts in semantic HTML and ARIA to be able to identify problems and create reports. That means that semantic HTML remains important.
Oh you mean screen reader? That's confusing, but yeah screen reader is absolutely a vital accessibility feature. I have no idea how lwn handles that.
Back when I was still writing HTML I was actually very keen on making accessible websites. But the last 10 years I've used frameworks and sadly have no idea how accessible the output is.
While teaching web dev, do you put any focus on accessibility for users with disabilities and other special needs? Is your platform accessible to students using assistive technology like screen readers? You're possibly offering something here which could have an impact on the high unemployment rate among disabled people, many of whom are lacking skills or opportunities to obtain them. Would be happy to talk with you more about this if you're interested - full disclaimer: accessibility and usability are my dayjob :)
As someone who has worked extensively with JavaScript web apps specifically geared towards accessibility, I can say that without a doubt the two major screen readers work with JavaScript. There are some quarks that you have to deal with but they do work, the issue is that not many developers take the time to test with them and make the necessary tweaks to get them working correctly. The biggest one being ensuring that the tab orders on elements match the flow of the application dynamics.
Before doing screen reader testing on complex web components, what I see as some kind of lack box testing where you test your whole screen reader + browser stack, it is useful to have a look at what the browser passes to a screen reader. Especially Firefox has a very nice accessibility tree panel in the devtools these days. In my experience, the more visual tree that is shown there is also easier/faster to read for users that are not blind and are not that quick when using screen readers.
Also, keep in mind that something that technically works correctly with screen readers is just the beginning. User testing might reveal lots of issues you wouldn't think of yourself. And yes, I know that resources are usually limited and there is not much room for user testing, especially testing with screen reader users and other groups that have some kind of disability. I recently worked as the accessibility lead of a mobile COVID exposure notification app that had a very simple UI and a hard accessibility requirement. We had the luxury to do extensive user testing and even in this simple interface we found lots of small changes that improved the experience for screen reader users.
Accessibility. Screen readers allegedly support JS - I don't use one - but I think we can agree it's a harder problem to solve than HMTL.
Not to get too much on my high horse, since you're clearly in an area where there's no way you could ever support vision impairment, the problem with ignoring vanishingly small portions of an audience is that the same people tend to be in that portion all the time and never get anything. For apps that aren't expecting interactions more than every ten seconds, it's so easy to just give them flat HTML.
reply