Ask HN: Any other blind devs interested in working on dev tools for the blind?
Just lost my fourth job this year. I can't definitively claim it is because of my blindness, I may just not be very good at software development. But one thing is for sure, there are many dev tools that are either hard or impossible to use if you're blind. I'm looking at you JIRA, GitLab, Chrome Dev Tools, etc.
I'm tired of feeling helpless. I want to build tools that make my life easier. Any other blind devs in the same boat who would be interested in collaborating?
137 comments
[ 4.3 ms ] story [ 225 ms ] threadThe world can certainly use more open source accessibility standards, protocols and tools.
Send me an email; my address is in my profile.
If you have an interest in Braille and have software development skills there might be something to do there. The UI program that drives our prototypes is open source and available on GitHub. https://github.com/Bristol-Braille/canute-ui
We have plans to open source the hardware as well.
If you want to add support at a lower level, our current USB protocol is outlined in this repository. It is a a dev-kit I knocked together to allow some Google engineers to write drivers for BRLTTY (and thus for ChromeOS). https://github.com/Bristol-Braille/canute-dev-kit
A super-rudimentary basic version will be something I finish when I've the time in the coming months. I was hoping to get some interested from the blind community and get ideas for further OSS work involving that general space (editors).
As a partially sighted developer, I generally use a screen reader for web browsing and email, but read the screen visually for my actual programming work. So I don't have significant first-hand experience with the accessibility (or lack thereof) of development tools. But some of my totally blind programmer friends have expressed some frustration with the accessibility of some tools, especially web applications. They generally use Windows with NVDA (http://www.nvaccess.org/). At least with NVDA, you can write add-ons (in Python) to help with specific applications and tasks.
To be candid, I have no idea what it feels like to be blind and have never paid much attention to accessibility other than reading a tutorial or two and making sure I use alt tags on my images. The main reason for that is that I'm lazy and based on my experience, most developers are in the same boat.
Now, if there was a service which would spin up a remote VM session inside my browser (a bit like BrowserStack or SauceLabs do) with all screen reader software setup and no screen (only audio), it'd make it a lot easier for me to experience my software as a blind user. There should probably also be a walkthrough to help new users use the screen reader and help them get started. If you're lucky, you could turn this into a business and it could indirectly help you achieve your goal of making better software for the blind by exposing more of us to your issues.
Anyways, I know you probably have more pressing issues to solve and I hope I didn't come across as arrogant, just throwing the idea out there.
The cheapest way to do it would probably be using the Orca screen reader for GNU/Linux, probably combined with the MATE desktop (forked from GNOME 2) so one doesn't have to worry about 3D acceleration in the VM, which will presumably be hosted remotely on a cloud provider somewhere. The main technical challenge that springs to mind will be capturing all keyboard events in a browser window. This is particularly important because screen readers tend to rely on esoteric keyboard commands, which repurpose keys like CapsLock and Insert as modifiers. I don't know if this can actually be done in a normal web browser.
Anyway, just throwing out my quick thoughts on this. I don't currently have time to pursue it further myself.
See- https://www.pyimagesearch.com/practical-python-opencv/
I've been working on a search engine for lectures (https://www.findlectures.com) and accessibility is an area I'd like to explore, but it's tough to know how to test something as an end user would see it.
"The web site has a off white background with black text. There is a horizontal menu at the top that fills the screen 95% horizontally and 10% vertically. The horizontal menu has a navy blue background with white text. There is a logo on the left of the horizontal menu filling 25% of the screen horizontally and 5% vertically. There are five menu items to the right of the logo image in the horizontal menu."
That's probably a little more verbose than it needs to be. But it could be a combination of CV, tapping into the renderer and traversing the DOM in order to best describe a page. Then if my screen reader isn't cutting it and I'm feeling lost I can just have the current view described to me.
I'm genuinely curious noe: how would the descriptions of color help?
- Context in places where color is used to relay information but the designer failed to provide alternative means of gaining that context without sight. For instance, if a text field is "grayed out" to indicate a certain state on the field, but that state isn't independently communicated by a screen reader.
- The ability to more easily describe the page to a sighted person.
From what I've read, screen readers are typically played at a very high speed (once you get used to it) - I don't know how you'd know things like that without advice from the people using them.
The second question is how you're supposed to navigate if you can't see the text well or at all - this might require adding features to the HTML to integrate with the screen reader.
I can visualize what my website looks like already, so if I shut my eyes I'd just be navigating it in my head.
You could make the $99 renewing if you want to offer updates, and perhaps an option to buy the source code for, say, $495?
Maybe you could make the software more expensive. Approximately 2.3% [1] of adults, non-institutionalized, male or female, all ages, with all education levels in the United States, are blind. If you could also provide the benefit of increasing sales, perhaps you could build a calculator (marketing tool; to estimate what percent of their customer base is blind and the money they're missing out on) and quantify that, that would help. You could especially capture some of that value if you bundle on consultancy services to perform the usability improvements.
How many hours would it take to get someone to get this working in a docker container? How long would it take to put together a decent installation guide?
https://nfb.org/blindness-statistics
Also, I feel like there was an early version/prototype of NVDA Remote that ran in the browser. I remember going to a page, turning on forms mode or whatever NVDA calls it (I've been out of the NVDA loop for a while) and I could send keys/get audio from the remote machine. I think that was before the addon was available so I'm pretty sure it was web native, but I could be misremembering. I don't think there's anything preventing transmission of the Insert key, at least. Capslock or other esoteric modifiers may be trickier.
0: https://github.com/nvaccess/nvda/issues/3564
Feel free to contact me if you want to develop an NVDA remote server in Elixir. I need a real project in Elixir to do more work in the language. I did some small Elixir projects and like it a lot.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_...
I work for a non-profit where we tackle accessibility issues related to the web, documents, and tech in general. We have a few Vagrant boxes that we use for development and testing, one of them is a Fedora box (GNOME 3 though) that comes with Orca configured [1] so that it doesn't prompt you for setup options. Chrome and Firefox are installed as well. If you have Vagrant and VirtualBox installed you can make use of it like so:
The box is ~2 GB. This is the repository for the box in question:* https://github.com/idi-ops/packer-fedora
* https://atlas.hashicorp.com/inclusivedesign/boxes/fedora24
We track Fedora releases and update boxes fairly regularly so there should be a Fedora 25 one with Orca once there's an official release upstream.
I hope it can be of use to anyone here. If you have any questions we hang out in #fluid-work on Freenode.
[1] https://github.com/gpii-ops/ansible-gpii-framework/blob/mast...
What's the non-profit? Expose UX [1] is preparing an episode focused on accessibility for Global Accessibility Awareness Day: startups will get judged by UX judges based on the accessibility of their products. Would love to connect with your org.
[1] http://ExposeUX.com
http://inclusivedesign.ca/research/ocadu/
So admittedly my development workflow isn't super high-tech. I do lots of JavaScript, some Rust, and a few others. All my languages have reliable command line tooling, which of course works well under Linux.
Some blind folks advised me to try Windows because it was supposed to make me more productive. I tried it for about a year and a half. I've used Linux since Slackware96, and whenever something failed under Windows I was stuck googling error codes and tracking down system logs. I can launch a Linux system upgrade from the command line. If it fails, it fails for an obvious/searchable reason, and prints its failure cause in the terminal. I don't have to track down logs in non-standard locations, google odd hex codes, etc.
Under Windows, the best I could find for accessible JS/Rust dev was Notepad++. That's just an enhanced text editor. At that rate I might as well use Gedit/Vim under Linux for development, which I do and it works well.
If you're developing heavily in Windows specific tech, then Linux wouldn't be a good fit. But as a technical user I'm quite happy with Linux generally, and Fedora specifically. About the only accessible Windows things I miss are audio games and Netflix, and my VM satisfies most of those. There are corner cases where Orca/Firefox act up, but under Windows there were lots of cases where I fought the OS, so there's just no perfect solution. I'd take a stronger foundation over slightly less accessibility any day.
Also, the web browsing experience on Windows is so much better, and the audio stack doesn't fall down at the drop of a hat because you edited a config file wrong (hope you have someone sighted who knows how to unedit it for you). I'm not sure I'd call Linux a stronger foundation; this was not at all my experience with it. OS X is, but then desktop Voiceover sucks to the point where you can't really program with it (basic things like terminal do odd things, nevermind the 10 or so keystrokes needed to navigate from code to the project explorer in Xcode. And we have to mention the speech latency). Then they just killed the function keys, which is an additional problem knocking OS X off the list.
But I think the biggest thing about Windows for me is that it's got synths which are capable of being intelligible upwards of 800 words a minute. Linux didn't even let you get at these settings via Orca last I tried it, and you can't set the inflection either, so it never emphasized punctuation. When your interface is linear and top-to-bottom, the biggest bottleneck in the general case is how fast you can go with the synth, and any platform which significantly cuts this down is therefore not a winner in my book.
But whether or not you agree with my points, I consider it pretty clear-cut that only a blind programmer even has the option of trying Linux in the first place, and certainly not a new one at that. You need too much knowledge to have even a halfway decent experience. In terms of making things accessible and having them matter, you've got to hit Windows first.
BTW, we provide a Windows 10 Vagrant box [1] as well. I just didn't mention it because it doesn't come with NVDA or the evaluation version of JAWS yet. That will happen soon though.
[1] https://github.com/idi-ops/packer-windows
For starters, even getting low latency out of the Linux audio stack is a major headache, and the synth situation is abysmal. You can't even touch the config files for these yourself because if you break either--even temporarily--you now can't use the computer. Then you get into how all the graphical desktops have accessibility issues to one degree or another and how you have to use a separate screen reader for anything outside them.
What you want if you want a testing VM that actually has value is Windows and NVDA. NVDA is free in both senses and kind of the industry standard for sighted testing now. Jaws is still more popular, but this is slowly shifting in NVDA's favor. This would be because Jaws costs roughly $1000 per user. The advantage of NVDA is that you can be sure all users can have it, and if it works with NVDA then it's very likely to work with jaws without too much more work.
But sadly you can't just test with one; in the end you have to test with all of them. Things like aria are nice if used correctly, but the aria spec doesn't say much about what screen readers have to do, and no one implements 100% of it. It's very close to the situation with needing to test on multiple browsers.
1. Make the inaccessible accessible through clever tools, relying on CV or similar. 2. Make tools that reveal to sighted devs how accessible their software really is, much like you've described.
These two approaches tackle the same problem from opposite ends and would hopefully meet somewhere in the middle. I view #1 as empowerment, getting back abilities that one has lost (or never had to begin with). I view #2 as awareness, giving the sighted visibility into where their software falls short in terms of accessibility.
I'm not sure which would have the biggest impact. But in my mind, I'd rather be empowered by technology. I'd be curious what other blind devs think, though.
Sure you can play around with the screen turned off to get some sense for the experience, but with the screen turned on you can compare the visual experience with the non-visual experience.
Another issue with testing with the screen turned off is - if an element isn't accessible, how are you going to know that it should have been there...
tota11y uses Chrome's Accessibility Developer Tools. Deque maintains browser extensions that use their own open source engine [2]:
http://www.deque.com/products/axe/#aXeExtensions
Both engines could also be used in CI environments to perform a11y audits. That should help web developers target at least low hanging fruit.
[1] http://khan.github.io/tota11y/
[2] https://github.com/dequelabs/axe-core
An idea, perhaps, but that's all it would be rather than real-world data. Blind people don't actually use these tools.
I have been blind in the past for months due to an accident when I was a kid. Fortunately I was lucky enough that a brilliant professor was able to restore partial eye sight. Enough for me to be independent and to be a software developer by profession and traveling the world whenever I get a chance.
One of the things I found out was that it is very hard to explain to people to tell them what it is like to not see. One of the popular questions was "So what could you see?" Don't get that question often these day, but I generally asked them to think at how much they can see with their hands.
When you can't even imagine how it is like, going that one step further on imagining how blind people are able to navigate your application/web site is a step beyond even that. Right now you only have things like web accessibility standards and tests for that. It helps, but it is not the same as "navigating the app like a blind person".
If there's an easy way to test and experience your app/website then it will also be easier to get a requirement like that past a C-level exec.
Sorry that I don't have much to add at this stage as I'm in the middle of starting up a new product myself, but you are always welcome to contact me (contact info is in the profile)
The tunable part should be made easy to do from a user perspective via some kind of "dial" "mechanism"
[1] http://www.apple.com/accessibility/iphone/vision/
By the time someone reaches 50 there's a good chance a proportion of text on their phone, web, computer and even groceries that is becoming unreadable without glasses.
Most app developers haven't a clue. Most of us 50 somethings hadn't a clue 10 years ago! Ctrl + in a browser is a brute force solution. Android's is even worse and a lot of what you want zoomed simply isn't, but it enlarges the parts you can read just fine.
Compared to many of my age I'm lucky and rarely need glasses, but already it's very annoying!
Something like this could be as helpful as when I first saw colour blind simulators 20 years or more ago.
Another interesting idea: try using braille screen for ourselves, so we as dev's will be able to work at complete darkness without any light :)
First off, you're 100% correct when you talk about how devtools are inaccessible. This problem is an historic one, stretching back as far as early versions of Visual Studio, or other early IDEs on Windows. Basically, the people who build the tools make the tools for themselves, and not being blind, make inaccessible by default tooling.
I do most of my work on Windows, using the NVDA screen reader, and consequently I have the ability to write or use add-ons for my screen reader to help with a variety of tasks[3]. This being said, this always means more work for equal access, if access is even possible.
I'm interested in any sort of collaborative effort you might propose. Targeting accessibility issues in common devtools does seem to me like a reasonable place to start attacking this problem. I had read a few months ago that Marco Zehe, a blind developer at Mozilla, was pushing some work forward for the Firefox devtools[4], but haven't heard much about that recently, and I think they might be distracted trying to get a11y and e10s working together.
Basically, I'm interested in helping in any way you might suggest, and from the thread here it looks like there are some enthusiastic people at least willing to listen. My email is in my profile, let's make something awesome.
[0] https://GetAccessibleApps.com
[1] https://CAPTCHABeGone.com
[2] https://www.indiegogo.com/projects/nvda-remote-access/
[3] https://github.com/mohammad-suliman/visualStudioAddon
[4] https://www.marcozehe.de/2016/01/26/making-the-firefox-devel...
If it's closed source like a feature in Visual Studio or some other company, I'll volunteer to ask them for it.
Maybe low hanging fruit is the easiest way to convince people at first.
The posts do not necessarily have to be long.
And have started a website to provide a resource for software development and accessibility: https://blinddev.org
Both are works in progress. If interested in contributing feel free to reach out, my email is in my profile.
Do let me know how to contact you.
Edit: oh there is an English button in the right top. Only saw it just now (a flag might be more colorful to spot).
And I also took some time to find where to change to english.
I'm not sure that using tools that try to provide a good visual experience is the right approach. Have you tried writing scrapers that provide an optimized textual representation?
Yes, we should all make our sites/apps accessible.
No, some sites/apps are great exactly because they offer a better visual representation that allows faster parsing of the information presented to the vast majority with adequate eyesight.
Just because someone develops a great way to visually take in information, that person should not be forced to develop an equally great textual representation.
There is also a fair amount of research out there on the topic (see Richard Ladner at UW).
Feel free to send me an email if you get anything going!
I'm mostly responding to encourage you to keep at it, and if you haven't tried Mac OS, maybe give it a whirl. Apple is pretty good about accessibility and their accessibility team is very good at accepting and acting upon feedback.
[1]http://mashable.com/2016/07/10/apple-innovation-blind-engine...
just because i can see you don't want my help? i somehow couldn't understand your plight? sight discrimination is real.
you're all idiots.
I am not blind, but I designed it to operate without looking at screen. If the app will take off, I'm considering into forking/pivoting into RSS reader that also is not using screen. App is already accepted in the app store, I'm sorting out launch details.
Please accept my deepest apologies for the shitty job we (the developers ) are doing at providing interfaces for vision impaired.
Probably when we're all old, we'll have vision problems of our own :).