Fab's AutoBackup 7 Pro - a must have tool for techs

@fabs,

No, that's really not how screen readers work. It's not an OCR process. You could have everything be black on black or white on white, completely inaccessible to vision, but if the coding is done to accessibility conventions, what's exposed to the screen reader is still there. Screen scraping, as was once done, has not been done in quite some time now because accessibility standards make it unnecessary. And once anyone starts coding with accessibility in mind from the outset, it's just really easy to make and keep things accessible. Retrofitting it is the nightmare, and even that's probably less nightmarish for a UI such as the one you have, as most of the controls are directly amenable to having things like labels, alt-text, etc., associated with them. I can't figure out what, exactly, the opening screen where you pick Backup/Restore/Transfer is, because although I can see it, and point and click on it, it's as if it's not even there for a screen reader. The screen reader is interacting with a window that's clearly active already that lies underneath that initial choice screen.

In any case, I do think this is a discussion better conducted privately, which I'm happy to do. I do know you care about these things, which is the main reason I brought it up in the first place. It's unlikely to be a quick fix.
 
By the way, at least in the USA, if anyone's curious about certain other frequently quoted laws and standards related to computer accessibility, Section 508 of the Rehabilitation Act of 1973 is one often-referenced statute (with standards that go with it). ADA stuff tends to spin off from Section 508 stuff.

There's also a lot of bleed-over these days between WC3/WCAG standards and Windows due to the prevalence of "web apps that don't really appear to be web apps" from the end user's perspective, but certainly are from a developer's perspective.
 
@britechguy
I've started looking at how to make apps that comply with screen readers and it appears that there is a lot of work to do on the interface. Today, it is clearly not usable using keyboard only. This and some other rules such as alternative texts, tab stop orders...
Today, this is nothing like that. It will take a while
 
Today, this is nothing like that. It will take a while

Which I knew before asking. But you can never get what you don't ask for and, as the old saying goes, "A journey of a thousand miles still begins with a single step."

You've now taken that first step. Who knows how long the rest of the journey may take. But I had to ask you to set out on it otherwise it might never have occurred at all.
 
Last edited:
Whether @fabs rewrites the UI for screen readers might depend on how big the AutoBackup Home & Office market is. I'm not sure if there'd be much need for screen readers for Pro customers.

Maybe the easiest solution is to write a script that runs in a terminal window with text prompts/output then runs autobackup with command line options. I'm sure screen readers would work well with that.
 
Often it's easier to do that than it is to understand the original version.

Particularly if you were trying to be "too clever by half" and were of the foolish mind (at the time) that commenting is for those with a weak mind.

I learned lessons early on that:

1. Code ultimately "compressed" in C syntax is virtually impossible to understand later if you were really, really trying for brevity versus clarity.

2. Even code not so "compressed" becomes non-obvious over time. That paragraph-length comment giving the birds-eye view of what the code in a given file or function does at the top, with stategic very brief comments interspersed in the code, is incredibly helpful.
 
I'm not sure if there'd be much need for screen readers for Pro customers.

It would certainly be a small market, but it's larger than you might think. IT work is one of the things that someone who can't see, and who is appropriately trained and motivated, can do very well indeed. Most of the coders who create screen readers themselves have never seen their own code in the literal sense of "see."

But if you (the generic you) are in the coding biz these days, and trying to serve a wide market, it really is worth learning to code with accessibility in mind as standard operating procedure. Particularly since Microsoft, Google, and a number of the other big players have been doing this for some time now, and it's become a baseline expectation in many circles (whether there's a huge market for it or not - it's one of those "things should be accessible on principle" things, since it's not onerous to achieve if it's built-in from the start).
 
Well,
I'm looking at my UI right now and I'm struggling A LOT. A simple clickable label does not have anything like a "tab stop" feature, so, they cannot get keyboard focus. Same thing for clickable images (the ones in th upper right corner for example that are used to open user's manual, about box, input license informations…).
I have to replace any of these in the UI if I want to make it screen reader compliant and it will take a huge amount of time. Indeed, while I'm doing this, I cannot develop anything new.
 
Adapting Fab's 7 for screen readers is definitely a lost cause as I did not design it for accessibility at all. There is way too much work to do on this one as there are dozens of graphical controls that I would have to change and adapt behavior.
Fab's 8 is currently in development and I'm almost rewriting it from scratch. At least, I can do this work on what I've already done with it. Since it's at its very beginning, it's not as painful as adapting V7 is.
No, don't ask me when I would release it, I just don't know each day if I'll be able to write a single code line, so, I can't tell !
 
Adapting Fab's 7 for screen readers is definitely a lost cause as I did not design it for accessibility at all.

The following is not aimed at you, specifically, but that is the problem when it comes to accessibility: retrofitting it is an absolute nightmare in almost every case.

It really does need to be baked-in from the outset, and it's not that hard to bake-in if you're aware of the basic techniques and use them, consistently. That's certainly what's going on in "the majors" at the moment as they've insisted on using the design and coding idioms necessary to have accessibility as part and parcel of what's being produced. And, even then, there's the occasional unlabeled control or similar because someone was in a rush. But fixing something like that is trivial when the entire accessibility infrastructure is in place and you have to add something to that infrastructure that you forgot, not add the infrastructure itself.

It's no shock that this is something that can't be done until a major rewrite or a "start from scratch for the next version" situation. I never intended for this to become an immediate, and fast, pursuit. The seed, however, has now been planted.

There are also PR benefits from being able to state that one's software is fully accessible, too.
 
Back
Top