ndarilek

This is cool. I just posted the link on a blind gamers' Discord. I don't do much D&D--really want to change that at some point--but they're frequently complaining about D&D Beyond being an accessibility dumpster fire and looking for something else.

I poked it a bit, and really appreciate that command output is automatically spoken under NVDA. I don't imagine that is accidental. :) Thank you.

Now you have me wondering what web-based command lines I might build. Maybe a crazy idea, but have you thought about adding external command support somehow? Accessible map representation is vastly unexplored, and it'd be fun to build that in the context of initiative.sh somehow. Maybe a web service, or a wasm module if you want to be one of the cool kids.

I could also see this being an embeddable widget in something like a Matrix room. Give everyone a shared context that all their commands can reference, maybe with different permission levels. The context might share all characters with the DM, each character with its own player, a representation of the map which they could move their character on in turn, etc. I've probably just scope creeped the hell out of your project, but this is really neat and I'm intrigued.

Because I want it to look good (or at least OK) and work on mobile.

Blind screen reader user and game developer here.

As of a recent release, egui pushes out some events that I'm able to consume and provide TTS feedback for. You can find a simple Bevy example with a bit of event coverage here:

https://github.com/ndarilek/bevy_egui_a11y

In my game, I'm able to use this for buttons, checkboxes, and single-line text edit fields. Sliders are a bit wonky but I'm hoping to eventually get those working better as well. Much of this development is needs-driven for me, and as of now I only need these few widgets. I certainly wouldn't complain if coverage improved, though. :)

Before anyone jumps on me about screen readers not being the accessibility end game, I do know that. But as a totally blind developer myself, I can't easily work on solutions for low vision, high contrast, etc. And for my needs (simple keyboard navigable game UIs for games targeted at blind players) it works well enough, and should hopefully get better soon.

For true cross-platform accessibility with integrations into native APIs, we'll need something like https://accesskit.dev.

Same. I've been using Bevy to experiment with some accessible game mechanics for the past few months now. The speed from which I can go from "I really want map exploration to report this and that detail on an entity, based on this and that characteristic," to code that just works and does what I want, is astounding. The degree to which I can then optimize that code, to only run it when this or that component changes value for instance, is also amazing. And when some Bevy subsystem or other isn't up to my standards, I can plug in some other library, add a few components in my game, and more or less forget about the details of the lower-level integration. It's an amazingly productive engine. If it'd launched a year earlier, I'd probably have built my just released game in Bevy rather than Godot.

Funny you should say that. I'm a blind screen reader user, and assumed this was some new 7-inch laptop. Since I don't need a huge screen, I'm always on the lookout for small, performant laptops. Seems this one is anything but. :) Glad I read the comments first.

This is a surprisingly personal legal battle for me.

I'm totally blind. For a long while now, iOS has been the mobile accessibility leader, and unless you as a blind person have some specific reason to use Android, you're encouraged to use iOS.

Back in 2009 when Android accessibility was a joke, by which I mean as a developer I found major API issues within a few hours of development, I wrote one of the first and most popular Android screen readers. I think it was at least the first to be publicised even before TalkBack, where by "publicised" I mean TalkBack wasn't in Android's release notes, but I at least had an APK installable via tinyurl and posted to a mailing list. I quite literally had nothing else to do with my time at that point in my life, and Android 1.6 had an accessibility API, so on a lark I started writing a screen reader. The project has since died out, but for a long while, Spiel was a thin on Android.

iOS won't let me do anything like that. Further, iOS won't even let me code for it unless I use MacOS, and while MacOS has some decent accessibility features, it's been a royal pain in my ass to code on. I could elaborate, but to keep this comment brief, take it as a given from a subject area expert that developing on MacOS as a blind person is worse than any other platform I've used to date. And that's saying something, since Linux is my primary platform, and there are a number of blind developers who won't touch it with a 10-foot pole. I don't want to claim that coding on MacOS under VoiceOver isn't possible, but it's more difficult than it needs to be.

Yes, these are two huge corporations slugging it out, and it's hard to muster much sympathy for Epic. But I wouldn't be the developer I am today if it weren't for Android's openness letting me build a screen reader, and its further openness letting me build an accessible GPS navigation app which I've hacked on in some form for around a decade now, and which I've come to rely upon. It bugs me to no end that the more accessible mobile platform is so locked down such that a budding blind software engineer handed an iPhone can't code for it using JAWS or NVDA. So Apple is handing blind people internet-connected mobile computers with all sorts of sensors, and telling them the only way they can develop for these devices is by using a sub-par development environment that's going to fight them every step of the way and, likely, turn them off of software development more broadly. Then maybe we wonder why we don't see more blind software engineers?

So, go Epic. If they start being asses later then of course I'll oppose that, but if they have a big enough saber to start breaking up Apple's stranglehold on the most accessible mobile platform, they've got my support 100%. Hell yeah, the web wouldn't have been possible under Apple's rule. And while I respect those of you who want more secure devices and a curated experience, don't under-estimate the harm caused by locking blind developers out of one of the most accessible computing environments they're ever likely to get. No, jumping through certificate hoops to install something that will expire after a week isn't anything near what I'm asking for.

And to those of you who say "Just tell your blind friends to use a Pinephone," I wish I could, but Linux accessibility infrastructure has no support for touchscreens and touch events. Any of you millionaires reading this interested in funding that development? ;) Serious question, I'll work to put you in touch with the right folks.

Will it be possible to temporarily turn off example.com, let its absence propagate across the network a bit, then turn it back on under a new server? Synapse has been good to me, but I know Rust more than Python, and Conduit's use of Sled is one less moving part for me to maintain for my single-user server. Looking forward to migrating to a lighter server I can potentially hack on, and would rather not change the underlying DNS infrastructure much.

Wow, native English speaker and I didn't even get the pun until this comment. I thought it was a stupid play on "What app should we message each other on?" and thus kind of a silly name. But folks use it regardless.

Careful about calling something a dumb justification. It's often the simplistic-seeming features that expose unforseen privacy issues, in large part because today's internet is such a complex place. In the end, it may turn out that privacy concerns are unjustified. But dismissing them out-of-hand isn't wise.

Do you have an automated way for turning it off when you're on home wifi? Trying a similar setup, and it isn't immediately clear other than via manual activation how to not use Wireguard in that situation.

Thanks.

Nice, should be good enough for now for me. Is there a GitHub issue or something I can watch for updates?

Haven't looked at Ghost in a while. The subscription system looks neat. I'd recently considered launching an indie game development site for a very niche style of gaming (audio-only) that could probably benefit from a Patreon-style model, but my margins would be so low that the Patreon cut would be hefty for little to no network effect benefit, and I know better than to try rolling my own.

Is there any mechanism for both subscription tiers and pay-what-you-want? So maybe I had a $5 tier and a $10 tier, and if someone wanted to pay $7 then they could and get the $5 benefits?

I'll research this myself when the 3.0 Docker image becomes available, but thought I'd ask first. Not even sure if Stripe supports that functionality, or if it does, how hard it'd be for me to add and contribute back.

Thanks for making Ghost.

Sometimes it's about taking what you can get, even if the solution is only partial. As a blind woodworker, I can't route a pattern laid out on flimsy material, but make a wooden template and I'm fine. So for more complex projects, we'll have someone make us a template we can trace, but we're still doing most of the work.

Granted, I'd love a solution that doesn't require sighted help. For this case, some sort of color identifier app might help. Given that Lego's color palet probably doesn't span too widely, this would probably be an easy weekend project.

They're just so easy to work with, and while directions are great, they're not strictly necessary to at least make something. Compare that with the handful of model cars I tried playing with, which had so many screws/bolts/gears that weren't at all interchangeable. I wanted to play with those, but doing so required me borrowing someone's eyeballs to get the thing built, and that deprived me of some of the fun of having a toy like that.

As an adult, I derive similar pleasure from woodworking and other crafts, but it's challenging enough to do that as a normal kid, to say nothing of also contending with folks who can't/don't support you because they don't know how or are too afraid. So, in the end, you have either legos or the simplest snap-together models to satisfy your building urge.

Even as an adult, I have a soft spot in my heart for legos. I've considered using them as snap-together cases for custom electronics projects, but haven't delved into them enough to know what sets would work best for that application. And as much as I like them, I really don't want to buy some castle or spaceship set just to build custom cases for my DIY doorbell or assorted RPIs. :)

Minor nit, but as a blind person who does various types of crafting (woodworking, most recently) I do care how things look. If I was building a lego set for fun only, I may not, care, but I wouldn't say it is "obvious" that I wouldn't.

Anyhow, only noted because I encounter that sentiment often enough to call it out. "You're blind, so obviously you don't care if you get the garrish hot purple cell phone, if you've got the laptop with the cracked screen, ..." :P

My girlfriend uses a wheelchair. She is physically incapable of turning on and off most of her lights, meaning if someone leaves a light on, she's stuck with that light left on until someone can turn it off. She can sort of use her thermostat, but not terribly effectively. Alexa has been an accessibility gamechanger for her, and I dislike kneejerk reactions like this one about as much as I dislike the fact that accessibility is so integrally tied into the Alexa ecosystem such that you've got this devil's bargain of increased accessibility and increased privacy loss. You can't have one without the other.

I'm blind and in a similar boat, but at least I can tie all my appliances into my Home Assistant instance, and never have to worry about being stuck out of reach of a keyboard or phone. Even so, as a blind person, finding accessible weather websites is an absolute pain in the ass. I can get daily forecasts, no problem, but sometimes I need an hourly forecast to plan bus commutes, and nothing beats "Alexa, what's the hourly forecast at 4 PM" for getting a quick answer without having to check half a dozen sites searching for actual textual information vs. a damned infographic or radar display.

I'd love to build her a Mycroft-based setup, but she doesn't need a cluster of RPis and USB microphones hanging around on her desk, and even so that ecosystem isn't ready yet. I say that as someone who literally spent days piecing together a HassOS Mycroft addon and hardware setup that barely hears his commands from a few feet away and triggers all sorts of false positives, and even so I don't think its weather skill does hourly forecasts. I own an Alexa as well, but it stays unplugged unless I need it.

TLDR: It sucks, but don't just classify all Alexa owners as dumb and deserving of victimhood.

Edit: Rereading your comment, I see that you don't really believe that. Apologies for the kneejerk reaction of my own, but I've seen this reaction enough from folks who do that I was finally tempted to speak out about it. I really wish there was an accessibility-oriented privacy-focused voice assistant, or at least, I wish I could pay more to Amazon to opt out of their more invasive practices.

Oh good, glad RLS performance got a boost. Unfortunately my Postgraphile implementation for that project was replaced with Drupal, but I'm glad RLS performance is less of a concern under version 10 and up.

Thanks for this. Lots of developers fall into the trap of discarding concepts because they aren't Facebook/Google scale solutions. The app on which I used Postgraphile/RLS was likely to have only a handful of users, so I thought more about solving the problem effectively than about whether the solution would scale, so RLS seemed like an airtight system. Knowing that it kills performance puts things into perspective. It at least suggests which tool might be best for which job. :)

Thanks for these explanations!

As a blind person who works more productively in a text editor than a web interface[0], here are a few things that might help: * Give me the ability to enter JSON directly in the permissions screen. I'm sure the query-builder is visually nice, but I can accessibly edit JSON strings better than you can accessibly visually render them, so let me just give you a string and have your interface validate it. Maybe just parse it, then transpose the values directly onto the form inputs in the visual interface. * Give me a command to validate YAML migrations without applying them. This could even be a --dry-run flag to `hasura migrate` telling me what SQL would run and the JSON for my new/changed permissions. * Some basic documentation on hand-coding migrations would help. I can sort of reverse-engineer them by pouring over the file formats, but the time taken to work more slowly in the web interface hasn't quite inspired me to take more time learning the undocumented format. :)

I'll see about filing these as issues soon if I can remember to do so. :) Either way, thanks for a cool product! Even if it frustrates me to use, tools like Hasura really hit a pain point for me in building apps.

0. Obviously that isn't universally applicable, but it is easier for me to solve logic problems than "why is my CSS all weird?" problems. Tools like Postgraphile and Hasura make it possible to test more of an app's functionality by writing just SQL rather than lining up my ORM with my language with my SQL schema. I guess just as Node supposedly reduces context-switching by placing more logic in a single language for front-end developers, tools like Hasura and Postgraphile let backend developers focus mostly on SQL when building out the app logic. And while I can't make something look good, damn can I think through how it should work and how someone might break it. :)

Good points, thanks. I keep forgetting that RLS is a fairly recent Postgres feature--2016 or so if I'm not mistaken.

Out of curiosity, what is the rationalle for abandoning RLS?

In a previous project, I used Postgraphile and enjoyed it. Sure, RLS and PLPGSQL were a bit awkward, but I knew they were well-tested and had lots of eyes on them, so I felt comfortable that if an RLS policy blocked access to a row, then that particular role wasn't getting access. I also enjoyed working with a text-based format that more clearly fit within my other workflows of, well, working with other text-based formats. :)

Another part of it is that I'm blind, and Hasura seems to make doing things outside of its web interface somewhat painful. Sure I can write a YAML migration by hand, but the YAML migration format seems more machine-friendly than user-friendly. Yesterday I needed to create a function, and the SQL web interface wasn't showing me the line number on which my function had an error. Ultimately I dropped to the psql command line, cut-and-pasted the function in manually, and right away got back the line number and fixed the issue.

Please don't get me wrong. I'm not trying to hate on Hasura. But the fact that I can't just drop to a non-YAML text-based format and throw down a few checks to secure my tables has been an endless source of frustration for me. So if there is a non-NIH reason for abandoning RLS in favor of a separate security system, then maybe knowing that might help me be a bit less annoyed. :)

That's fair. I accept that isn't what you meant. Thanks for confirming it, and apologies for the implication.

Fair point. On one hand it makes me a little sad to see parades rained on. On the other, I assume folks want some degree of criticism if their ideas have some sort of flaw. On the gripping hand (such a useful metaphor, that) if we're going to tolerate some amount of politely-phrased negative feedback, then we probably shouldn't sweep some of it under the rug because it isn't the "acceptable" kind of feedback. Not that you are doing that, mind you. But it seems like some of that may have happened here.

Full disclosure: I know Matt and think he's a good guy, and he reached out to me wondering if he'd done something wrong. And I can actually kind of see both sides of this situation. But unlike him, I know I'm kind of a hard-ass about access issues not because I want to be, but because today's cool idea might be tomorrow's "no job for you, Nolan," and not because anyone wants that, but well, what do you tell someone who wants to work for a company but can't because most of the tools they use aren't accessible, so you literally can't do the job they need? And yes, this has happened to me before. And we can sit around and talk about privilege or who is at fault all day, which may certainly be a worthwhile discussion to have, but at the end of the day, the discussion I most want to have is "are you going to change your company's workflow to account for the fact that I'm qualified to do this job but can't as things stand?" and the answer is usually "nah, easier to find someone else, sorry."

So that's where Matt and I are coming from, and I wish folks hadn't piled onto him for trying to express that. And while I'd like to be nice and polite about that, well, what do I get when I am? A cookie? I'll try to pay the rent and do fun stuff with that cookie, thanks. :P

Enough novels from me. Got stuff to do. :)

I don't think it'd be salt in a wound--or at least I wouldn't see it as such. I do wish someone smarter than I am could come up with an accessibility backend to map GUIs to accessible HTML interfaces. So just as QT apps push accessibility objects to Linux/Windows-native accessibility APIs, something could push either ARIA-enhanced <div>s to the browser, or could just output fully-accessible HTML. So instead of QT rendering to a canvas, it could render to another target that just happens to be HTML elements. Substitute any other GUI toolkit with an accessible object representation for QT in my previous paragraph to get a sense for the scope of the problem.

I've just never dived into how those particular APIs work mainly because, well, there are so many problems needing solutions, and I happen to be focusing on others. Surely I'm not the only one to have thought of this, though, and on the off-chance that I am, the best thing I can do is keep mentioning it until someone else decides it's worth trying. :)

Thanks, a thousand times this. :) Even though this particular codebase doesn't bother me at all, my perception of the responses in this thread does bug me, and I appreciate that someone less emotionally attached than I am has both gotten it and taken the time to try explaining it.

Can we just agree that Matt was pointing out a gap and leave it at that?

I know more than most people that there is a cost to making things accessible. Do you not think that I get the dumbed-down, PR/support-filtered version of that response every single time I reach out to a company and tell them that a thing my company is using is unusable by me? :)

But I think we, by which I mean everyone in this thread, can acknowledge that without implying that our needs aren't worth considering because there aren't many of us, or that they aren't worth considering because no one immediately knows how. If that isn't what folks have done here then I'll own my misunderstanding, but folks could have just acknowledged the comment rather than criticizing him for having the audacity to suggest that I too might want to appreciate the technical achievement for myself..

And FWIW, I kind of resent having my disability, which no amount of learning or software upgrades will fix, lumped into the same category of English proficiency or IE 6. That does feel a bit condescending. Saying "well, some people can't upgrade their browsers" is in an entirely different league than a visual disability that no amount of upgrades or night classes can fix. I'm not saying that switching browsers or learning a new language are possible for everyone, but short of gene editing, there is no way for me to eliminate my blindness. I'm not upset about the examples you chose, but would like to politely suggest that you reframe how you think about these issues. :) Thanks, and not in a snarky way. :)

And again I ask, when someone else produces some technically great achievement and people pile on about the design looking bad, why is that treated any differently? Why isn't that raining on the parade?

In a parallel universe, someone might have said "You're right, it isn't accessible. That wasn't my goal, and if this ever does take off then I might have to investigate other options."

But that isn't what happened, it's a bit of a double standard, and that double standard has real consequences for some of us. The bulk of the pile-on doesn't seem to be coming from my friend, but rather from a bunch of folks criticizing him for daring to politely suggest that there's another perspective worth considering.

If your response is "because more people care about the visual design of a technically sound concept than whether it is accessible because looks matter," then I'd agree with that, and we can just leave it there without casually dismissing an entire group of real people who matter. But again, that isn't what happened here.

I wish I could post web apps I've made here without contending with the half dozen "your design sucks" comments I'd likely get. But if I got them then I'd expect them, and that frustrates me to no end.

FWIW, I'm not actually all that upset. I'm kind of used to this, actually. And I know you're just trying to explain why things are what they are, which is exactly what I'm doing. :)

Also, on a note directly applicable to this example, if you think hammers are unusable by folks without arms, might I suggest the documentary Right Footed? I can't say whether or not she uses a hammer without arms, but she flies a plane and drives with her feet, so I can't imagine her not using a hammer if she didn't want to.

It feels a bit inspiration-porny at times, and my girlfriend and I both cringed quite a bit while watching it, but I think it makes the point I'm trying to much better than I am. Please don't dismiss a challenge out of hand because you can't imagine in 15 seconds of thought how it might be overcome.

"you" being a generic term applicable to anyone reading this, BTW.

Sure, but in the context of building a visual layout tool, for someone to say that it shouldn't or doesn't need to be accessible to a blind person because OMG, visual! completely misses the point that it can be, and that other tools before it are. To say "I didn't have time to focus on accessibility because I was struggling with the challenges of making a Java codebase run under wasm" is one thing, and a thing I myself can relate to, having banged my head on wasm's challenges myself. To say "there's just no way to make a visual layout tool accessible to folks who can't see, so I'll just throw up my hands and give up" is another entirely. And I don't think that's what OP is doing, but I do think it's what some in this comment thread are advocating, and that's what bugs me.