bramd

Thanks, will keep an eye on your progress. If you want to discuss this kind of use cases in the future, feel free to get in touch.

Congrats on the launch.

Have you thought about assistive technology/accessibility tasks as well? Would love to use such a device to control the touch screens on inaccessible coffee machines at my clients offices for example that I can't operate without sight. I'm sure there are way more examples of such things.

Throwing complex robots at inaccessible devices is not the proper solution, but by far the most quick and practical one. Not in the US, so not even able to buy one and I'm also hesitant to buy something that is totally bricked when the company/cloud goes under.

Braille tablets/multiline braille displays are finally coming. The traditional piezo-electric cells are not well suited for them, due to the space the cell + driver+ electronics need. Putting the four rows of pins in a cell does already require staggering the elements. If you disassemble a cell, you'll see that every row has another pin length the bottom row usually has the longest and the top row the shortest pins. So this is not very scalable for multiple lines of dots.

There are two commercially produced techniques for multiline braille displays now: the first comes from Dot (a Korean company) who makes the Dotpad, this technique is also used in the Humanware/APH Monarch which will be an Android based standalone braille tablet. The other technique is created by Orbit Braille and they have their Graphity braille tablet. I couldn't find any good technical documentation that describe how these methods work exactly, so if anyone has any pointers I would like to read more about it.

I disagree. To "solve" their CAPTCHAs I had to register by providing a working email address. I don't encounter HCAPTCHA problems that often, so when I need to solve a new one usually my cookie has expired and I have to reopen the link to get a new one before being able to continue. I just store such links in my password manager, but imagine you have to find an email with the link they sent you over a year ago before being able to just continue on with what you were doing. And even then, depending on ad blocking/privacy settings their cookie may not even work.

I think this whole thing is a big hurdle just because I'm unable to solve visual puzzles. Besides, having a company collecting email addresses of people who are disabled in one way or another and giving them an identifying cookie is a privacy/data disaster waiting to happen.

That being said, I think the audio alternatives for visual CAPTCHAs are also unacceptable. Even if you can hear them, they may be hard to solve especially if they are not provided in your mother tongue. I think we can and should be able to do better by now

Totally agree. Buying new appliances is hard if you are blind. It's either very cheap stuff that still has buttons, expensive stuff with touch screens which are unusable to me or expensive stuff that has touch screens and an app to control it. Besides not willing to fiddle with a phone and an app for every single action, the expensive stuff with apps will be unusable sooner or later when the software stops getting support and the appliance is still there.

Marijn has done much to make CM6 an accessible code editor. Now with Monaco (editor component of VS Code) and CM6 both being accessible, online code runners/playgrounds and interactive code examples in docs/courses are almost guaranteed to be accessible when they use one of those editors. This eliminates a big accessibility issue when you are learning to code and rely on assistive technologies.

Yes, a nested list would clearly be the better structure here. Or even a description list (dl) with the comment's metadata in a dt and the comment in dd.

My thought exactly. An open source version could be nice in it's own right or lead to good improvements on other open source speech synthesizers such as Espeak. I think current TTS research/software is only focused on sounding nice and human. This is cool if you want to replace a human voice with something computer generated, but not ideal if you want an efficient speech output that can convey as much info as possible as fast as possible. Predictability is key here, I could proofread a text in Dutch (my native language) with ETI Eloquence set to English and just by the sound of certain letter combinations I would know if there is a spelling mistake, couldn't do that with any other "better sounding" synth.

The engine behind that add-on, Axe core, can be called from JS and there are some open source tools around to integrate it in your CI. I would say Axe is kind of the gold standard at this time when it comes to automated accessibility testing. Not because it catches the highest number of issues, but if it flags something you can be pretty sure it's a real issue and not a false positive.

Yes, I would like to publish some lessons in the future somewhere. However, a few quick takeaways:

* The microcopy matters, a lot. We had a button stating "I've got a notification: read what you should do after getting a notification" (from the top of my head and freely translated from Dutch, we didn't have an English translation back then). This was part of a bunch of buttons on the main screen that all gave information. Some screen reader users got confused and thought that they had a notification. If you don't see the visual layout, it is not obvious that this is just a plain button and not a bold text in red that is giving you a warning. * In the same category: the app has a status text that says "The app is working fine" or "The app is not working fine". Visually, the error state is signified by an exclamation mark and styling that makes clear that this is a serious issue. However, in text there is just one word, not, to signify that there is a serious issue. Following WCAG, the info signified by the exclamation mark icon was available in text, so no text alternative was required. However, we gave it a text alternative anyway to ensure screen reader users were also clearly alerted that something is wrong. Same goes for the "all is ok" icon, we gave that one a text alternative as well to ensure users all is fine.

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.

No time to read the whole thread right now, but feel free to get in touch (email is in my profile). I'm blind since birth and have had various software development jobs. These days I shifted a bit and started my own company doing digital accessibility consulting.

If you'll become totally blind (e.g. need to transition to a screen reader some day), I would advise you to leave the Mac platform. The built-in screen reader seems good at first, but falls down in complex work. Support for web browsing is suboptimal (Firefox is a no go) and the screen reader is only updated in the regular OS X release cycle. This means bugs will stick around a long time and it's totally unclear what the status of a bug is. Also, hackability of VoiceOver is limited. I find that a must for a tool that I am 100% reliant on.

I'm very sympathetic to Linux and run it in many places (Raspberry pi, home server, some stuff on VPSs), but I think Windows is a better accessible desktop experience now. Microsoft is trying tu push accessibility hard in most of their projects, this is often lacking in open source projects. Even if OS projects want to do a good job at accessibility, they usually miss the manpower of knowledge to do so. Especially given Docker and WSL (Windows subsystem for Linux), it is easy to run Linux-based development workloads on a Windows box.

My editor of choice these days is VS Code. That team is also very active on the accessibility of their editor. I use the free and open source NVDA screen reader. If something in NVDA is broken, I can at least look at their Github if any work is being done and if needs be throw in a few patches myself.

So, summing up I would say: find out a set of accessible tools to do your job, learn them before you get blind. Relying on vision until the very latest moment will give you an enormous productivity hit when the switch to 100% screen reader use comes (based on my experience training low vision and blind users in a previous job).

From what I've seen from the thread, others have already touched on some advantages of being a blind coder. You'll get a better mental model of your code out of necessity and depending on your team/employer you can be a more valuable team member because you also bring knowledge of software accessibility.

Hope this helps and good luck!

+1 for this advice. Identifying the issues is just one part of the work, finding a correct and usable solution might be lots of work if you don't have much experience with accessibility.

I also do full-time accessibility work. Don't need extra work right now, but feel free to get in touch to discuss work in the (near) future.

I'm still looking for a service like this, but that creates a nicely tagged PDF and conveys the HTML structure in the PDF tags.

Tagged PDFs are a requirement in many processes for accessibility or archival reasons.

What's the standard really depends on which slice of the world/market you're looking at. NVDA[0] is a very capable screenreader as well and does some things even better than JAWS. It's totally free and open source.

[0]: https://nvaccess.org/

Well, in this case I was quite glad that they have targeted the web platform. At least that allows me to code my own stopgap solution using userscripts and stuff. That's harder for native.

> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.

Not just that, but it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days. So yeah, I take this promise with some skepticism.

So either this is a lack of priority and disrespect to a part of their users or some level of incompetence.

I might sound harsh about this, but imagine being a blind software dev that's supposed to work with Slack to participate in teams. Every day you sign on to your team it's possible that the Slack devs break something and you can't function. And now they closed the escape hatch.

Pretty cool. And if people are wondering, yes, screenreading software can output this to a braille display. However, mainstream displays only have one line of braille making 2d images somewhat more difficult to understand.

Your question is very generic, but in situations where this device might be used most (e.g. walking, getting around) I usually use the following:

  * Guide dog (still the non-technical, living and breathing version)
  * iPhone for GPS navigation if I don't know the environment
  * Aftershokz Bluetooth headset with bone conduction to listen to spoken announcements and still hear what's happening around me

In general, the blind use all kinds of standard consumer tech, smartphone, smartwatch, laptop/desktop etc. There are still lots of products out there specifically designed for the blind, but there is more and more a shift to standard devices.

Congrats on your launch. As a potential blind user, I've some questions. How can I reach you? Your email doesn't seem to be listed in your profile.

Yes, you are right, but things like face recognition in this app run locally already. I tried it in airplane mode.

Also, check this blog from a blind user and some interesting comments: http://chrishofstader.com/seeing-ai-first-impressions/

Yes, if you make a mess and bring in some accessibility compliance people that have to suggest all kinds of shitty workarounds it will cost you money. If your devs don't know why those shitty workarounds are there they will break it all again in a next release. If you just use semantic HTML from the start you'll have a more robust product and less maintenance in the long run.

Oh, and ARIA rule one: don't use ARIA, use the native HTML equivalent. Rule two: Only use ARIA if you can't express your intent in native HTML and make sure you know what your code is doing, don't just copy paste some ARIA example from another project or random site, lots of ARIA in the wild is wrong.

I'm a blind developer and accessibility consultant. Accessibility consulting is a good business to have these days, but I hope my work will be obsolete one day :).

Sounds familiar. I had only the former kind of education. Often I'm pondering if I should pursue a masters degree in anything CS related. It's not that I really need it for my work. So, my options are to either do a CS master, and have to catch up on a lot of math and CS fundamentals, do some master in a totally different field such as business administration (useful since I have my own company), or do nothing at all :). Any advice from your perspective about this?

First, I don't think that "enabling sight" is the right term to use here. It's just making a certain device usable to the blind.

And yes, there are open source and free options available. iOS' accessibility APIs are closed to third parties and VoiceOver is the only option on that platform. However, there is free and open source screen reading software for Windows, Linux and Android.

I can't say what the state of Orca, the free Linux screen reader, is these days, but I know development is still going on. Orca wasn't so much of a problem in the past when I tried it, it was more that it could be a real pain to get everything working together. Think reasonable low-latency sound output for speech, driving a braille display through the BRLTTY software, getting the screenreader runnign at the login screen etc etc. I hope that has improved by now, but I only interact with Linux through SSH sessions or local text console these days.

Then there is NVDA for Windows. A free and open source screenreader mainly developed by two blind guys. On many fronts it has feature parity with the very expensive commercial offerings and even surpasses the commercial offerings on certain points. I use it as my daily driver.

In the past I also used a Mac near fulltime, but the VoiceOver of Mac OS became to buggy for my professional work. Also, usually updates only came when the OS was updated, so fixes and new features could take a while. So, long story short, open screenreader on a closed operating system that provides stable APIs seems to be the best of both worlds for now.

Related longread[0] on how the west tried to build a similar device after discovering "The Thing".

[0]: https://thecorrespondent.com/3789/operation-easy-chair-or-ho...

Hmm, I don't remember any such prototype/demo. However, the NVDA remote protocol is pretty simple, JSON messages over a TCP socket. Putting those messages on a websocket should be fairly straightforward. With the web speech API landing in Firefox as well as Chrome[0] you could even synthesize the speech at the client. There would still be the problem of sending special key sequences. Not just ins/capslock, but also shortcuts that are normally capturen by the browser/OS might get tricky.

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_...

> Though sadly it will be a while until we will hear: "You are visiting Hacker News, in a simple look and without any images, it features a list of links to articles and a menu at the top. Do you want me to read the articles titles, continue with accessing the menu or a more detailed description of the page?"

Sadly? I strongly disagree. If all my human-computer interaction would be like communicating with Siri/Google Now (e.g. conversational), I would have ditched computers years ago. It's all about giving semantic information to screenreaders so the user can eficiently navigate that content. In the rare case that I need some kind of human description, I just share my screen with someone that has working eyeballs.

FYI, I'm totally blind.

Another interesting project written in Erlang is LeoFS: http://leo-project.net/leofs/

> What I'm interested in is taking that sensory input and making it less immediate by giving it a memory -- letting it build up a picture of an environment rather than needing to point a device at something in order to know something about it.

Have you tested this approach with blind users? I think building a picture of an environment is a good task to offload to the brain and a good skill to have/develop for blind people.

> One big issue is figuring out how to sonify depth information so it's useful. One simple approach is to do a sort of sweep across each frame from left to right, letting each row of an image correspond to a certain pitch. I don't think this is a good approach, as it seems very vision-oriented and is likely to sound just like noise.

I think this is a quite good approach, but agree it has a high learning curve. However, that high learning curve might reward the end-user with a system that is more flexible. By preprocessing the input and generating audio based on the detected patterns you limit the applicability of such a system. That being said, a generic system that gives "unfiltered" output and has additional cues you can set for example for fast approaching objects might be useful.

Hmm, the reply button to submit this comment is just reachable with tab as it should be, so I don't see any issues there?

Have you looked at something like BigBlueButton? I recently used it to give a webinar. They don't have an HTML 5 client yet unfortunately, but they integrate some interesting things to provide video/audio over WebRTC and to their Flash client. I think it uses Freeswitch for the audio/video part.

If you nail the technical issues, you might find that lots of blindies are not that good videographers. You need a high quality stream and preferably a method to let the remote party control the camera zoom. I use "remote eyes" in various situations and had quite some issues focussing my camera in the beginning. I use USB camera glasses or a smartphone, usually just through a Skype connection.