BleepingComputer.com: when assisting members with issues, do you have to sound like you're writing from a script?

Hi again, guys,
Sorry for the two-day delay. Yesterday I had a boat load of science to read and then some Literature crap as well for homework. I'm here to tell you that in the Blind Programming mailing list I'm on, there is a current thread going on dealing with the accessibility of MBAM specifically, but it is also for general accessibility issues due to the addition of non-standard windows controls. I posed the question you guys had about moving to standard controls being a vector for malware, and my fellow listers thought I was strange. One guy was like, standard controls being a vector for malware, huh? What the heck are you talking about? They corrected me in saying that Malwarebytes Corporation is probably using the nonstandard controls to prevent users from automating the program with something like AutoIt (*.AU3) files, and not because they're worried about malware. And not to mention, there's definitely a way to make controls, either standard or nonstandard, accessible. It's called folks being lazy and leaving the customizations up to us. I'm sorry if that sounds harsh, it's just that my mission (hence my site and the Raeder24 community), is to try, with help from others, to get companies to realize the benefits of making their programs accessible to all parties, blind, sighted, whatever. And did you know that MBAM's written in Visual Basic? That's a good sign that accessibility should have been a priority. And not to mention, it'll only take them a second to label the controls if they're using VS as their IDE. I didn't ask them, because I told you, they ignore me when it comes to that subject. I just wanted to give you that update as promised.

Thanks guys,
Chromebuster

Hi again,
I'm just following up on this topic. I was wondering if you need me to do anything, or what is the scoop now?

Hi chromebuster,

Since this topic has gone a bit off-topic, lets recapitulate things here, not only for you, but for everyone who might be in a similar situation.

When you are getting help with malware removal at BleepingComputer and for some reason cannot follow the directions because you are depending on utilities like screen readers, best is to specify this clearly to the helper. By doing so, you can work with your helper in such a way that 1) you will be able to execute the directions and 2) your helper will get the information necessary to determine what is needed to resolve the problems.
In malware removal we use a variety of tools, highly dependent on infections and operating systems. Furthermore, we are a voluntary staff. I think you can understand why it would be impossible for us to make sure that all fixes we use are screen reader compatible as a rule.

Regarding the case of many (commercial) tools not being accessible, there is very little BC can do about this. The problem is being discussed at MBAM, but it is not depending on BC what will be done about it if anything.

Okay thanks. Again, I'm sorry if I seemed pushy or harsh. All I really give two dangs about on this board is that you folks don't leave accessibility in the dust. That you guys follow with my beliefs. I can understand if you're not going to talk to folks for me, for that's a little cowardice, is it not? I think that in order to get my mission accomplished, I've just got to keep pushing at folks. about the only way. I'll check again AT MBAM, and see if I see that post and maybe it has had some replies and I just didn't see them.

I would just like to comment that as a technician of many years, that sometimes it is impossible to do fundemental troubleshooting with the aid of screen readers and other specialized equipment, as machines need to be diagnosed without these drivers loaded or be run in a service mode or from a boot medium which may not even load an operating system compatible with your screen reader, such as a ram test boot disk.

I wouldnt expect a person who was sight impared to be able to utilize many sight dependant tools in the real world effectively either, such as a surface mount soldering iron (I even need to use a magnifying glass to be able to use one of these), or a RJ-45 crimp tool, as you would need to be able to see the points you were soldering or the color codes on wires you were crimping a connector to.

This being said, as long as there is a common framework and standards for screen readers, I think developers should write software to these standards as far as it is possible. In the real world of software development, it's commonplace to find drivers written only for one specific operating environment, making the hardware specific only to that environment. So for instance, a screen reader with drivers only available to windows would inherantly not work on a RAM testing disk that boots from a linux kernel without all the windows API dependencies that the driver has.

Working toward standardized hardware and software specifications for accessability devices would be the most direct approach to implimenting these devices acrossed the board. Such as keyboard and video devices having a "basic" functionality standard upon which they can interoperate without the need for specialized software or API's upon which to depend.

I'm not a software developer, and I'm not familiar with the state of the accessibility hardware market as it is. Perhaps you can tell me more, is there a need for standardization or do standards exist on a hardware level that software could be adjusted to match on it's I/O functionality, such as communication with a standard serial device using a standard protocol?

I appreciate your devotion to your cause. I am interested in it.

Thanks for bringing it to my attention.
Gabrial

This post has been edited by Gabrial: 28 September 2010 - 08:39 PM

I've never investigated into the accessibility of hardware and standards for that. I've always taken it as common knowledge that it is simply too difficult to have screen readers loading directly or below the operating system. After all, we don't want too many things loading at preboot time, now do we? I was just conversing with a guy from Dell about this too, and developers of such proposed software and hardware would still have to worry about company specific diagnostic tools, such as Dells TSA diagnostics used for hard drive integrity checking. It is also understood by blind folks that preboot environments are generally not accessible. My concern is with the most basic software that runs from the inside of the operating system. Eye-candy has become such a necessity these days, that simple button clicks and fields that mark buttons and controls to label them are overlooked, avoided, or unused due to the fact that companies choose to have their developers write all of the code by hand. That's why they make IDES. So that some of the labeling stuff can be taken care of by simple dialogs. Companies miss this. And thanks for your support of this cause.