mltony

Could you guys fix this accessibility bug: https://bugs.chromium.org/p/chromium/issues/detail?id=126072... - it's been open for years.

My two cents: learn VoiceOver for iPhone yourself, turn on screen curtain for further realism, and spend tons of time with your relative practicing simple things. I am blind and a couple of years ago I was trying to help a friend to learn VoiceOver - the friend wasn't that tech savvy, and it turns out that even simple concepts like swipe left or two fingers double tap present some difficulty to them. So have a lot of patience, but in the end if they can learn to use apps like Mail or Audible independently - that would be a very rewarding experience.

iOS VoiceOver is better than Google TalkBack on Android. Although I've heard recently that Android is catching up fast.

I mean it's amazing that blind people can use such a portable device; but I don't quite like that there are only so few gestures that can be made using touch screen. That's the reason they had to invent rotor, I personally find it inconenient compared to using a full size keyboard; but given touch screen rotor is probably the best you can get out of it.

But also I need to mention again my complaints about bugs that never get fixed. Just in case someone from Apple is reading this:

* In some apps the focus jumps about 1 second after opening a new screen. This is especially bad in YouTube app, but also can be rreproduced in other apps albeit with lower delay.

* Back in the days when iPhones had a physical home button, tripple press was supposed to toggle VoiceOver. But the problem is that in more than half iPhones (mine and friends') it stops working after a few weeks of usage. Yeah it can be argued that it's hard to reproduce, but this bug was so well-known and infamous in blind community that shame on Apple for not fixing this.

In general I'd think that a smart decision would be to make both iOS and MacOS VoiceOvers open-source, so that blind people themselves can fix all the bugs. Until then we're left with the situation that a bunch of disinterested sighted devs work on VoiceOvers, and as I already mentioned they are more interested in implementing some shiny new features instead of fixing decade old bugs. And as far as I know being an accessibility engineer is kind of considered one of the worst in the pecking order of engineers, so only those people who couldn't find a better career become accessiblity engs. engs.

Blind developer here. I could never recommend VoiceOver on MacOS to anyone. 10 years ago before I lost my eyesight I was a huge fan of Apple - everything was just working so much smoother than in Windows world. And much more visually appealing. However, after losing eyesight, I had to switch to Windows. I learned VoiceOver on Mac at first, but working with it was so unbearably frustrating,, even back in 2016 when I was trying. Here are some of my complaints that I still remember:

* Many actions work every other time. I remember that interacting with text area of terminal app was especially painful since the sequence of commands was non-deterministic.

* Hierarchical navigation model is more cumbersome than flat navigation on Windows. In XCode to access some project settings you need to interact with some panel, which has two horizontal subpanels, so you need to interact with the right one, which in turn has two more vertical subpanels, you interact with the bottom one, which has three more subpanels... The recursion depth was 9 levels, I kid you not; and making a single mistake will lead you to wrong place.

* Searching webpage in a foreign language doesn't work. Because Command+F needs to be presssed in English layout and this would open VoiceOver search window, where switching to another layout doesn't work.

* No easy way to open a link in another tab in browser - as opposed to Control+Enter on Windows.

* Too difficult keystrokes - I remember one of keystrokes involved 5 keys: Fn+Ctrl+Option+Command+Up/Down. By now I forgot what it means, but I remember that it gave me plumber's disease - pain in my left wrist from having to press too many keys for extended periods of time.

I probably forgot a bunch more. Not sure if any of these have been fixed since then. But my general impression was that Apple is not very interested in fixing bugs, but instead, they appear to care a lot about presenting shiny keynote slides every year on WWDC claiming how much they care about accessibility.

In Windows world things are considerably better. Jaws is much more convenient to use, even though I've heard many reports of them not willing to fix bugs. NVDA is open source and it is my favorite, since if something doesn't work for me - I just go and fix it myself, but in general things are rarely broken to that extent in NVDA.

Also if I remember correctly Jaws and NVDA share about 45% of marketshare in the screenreader world, while VoiceOver is about 10%. So judging from this point alone anyone would be much better learning a Windows screenreader.

Very interesting idea. I think it depends on precision with which that implant can communicate heading. If precision is 10 degrees or less, this can actually be extremely useful to visually impaired people.

I got the idea when I was learning to cross a wide street with a white cane. three lanes in each direction - and it proved to be a challenge because I would veer left or right and frequently get confused and lost. Then I thought a compass would be helpful, but a quick survey of compass apps on iOS showed that they are either visual, or show your heading as a number that can be read by VoiceOver, but it is still not very practical. So I thought that I need to encode heading as something that my brain can easily decipher during crossing the street. I have prior musical training, so that's why I decided to encode heading as a musical interval. This allows my app to communicate with about 10 degrees precision and in practice this is well enough to go on a straight line for long enough to cross the street.

I use NVDA. Here is that add-on if you're interested: https://github.com/mltony/nvda-browser-nav/

Blind developer here; I often write tools for myself to perform some task that is not well supported by my screenreader. For example:

* I wrote an add-on that allows me to read HN comments in a structured way. A typical screenreader would present page in a linear manner, so you'd have to read all replies in order, which is quite tedious in popular posts. My add-on parses the page and identifies the level of each comment, and then I can navigate to previous/next comment at any level. So I can quickly check top-level comments and then read replies only if I'm interested.

* Another add-on makes Jupyter edit boxes to work with my screenreader. Jupyter was requiered at my company , so I either had to write that add-on or else. The way it works is that it sends Control+C Control+V keystrokes to the browser to retrieve contents and then presents them to me in an accessible window for editing. When I'm done it would Control+A Control+V new content back to edit box.

* BlindCompass - iOS app that I wrote for myself to navigate on the streets. One of the problems of blind people is that it is easy to lose the sense of heading, e.g. where is north vs South. So BlindCompass would read my heading and present it as a two-pitch sound, that allows me to deduce rough direction. It's also easy to figure out the right direction and just maintain it, so with BlindCompass I can cross large open spaces easily.

I do use it with bluetooth headphones - bone conductance headphones, so that I can also hear the street. I tried to put my phone in the pocket, but then heading fluctuates with every step. I assume this might be enough for someone, but I prefer to hear accurate heading, wich allows me to walk straight comfortably.

iOS app Blind Compass https://github.com/mltony/blind-compass

I am blind and I developed this auditory compass for blind people that communicates your heading as two tones - musical interval between them encodes your heading. It helps white cane users not to get confused in space or walk straight across large open space by locking heading. It also makes me look like a lunatic, because I put iPhone into phone holder that I sawn to my hat to provide most accurate heading information.

The app is free, but I have to pay for Apple Developer subscription to keep the app in the app store.

Blind developer here.

So surprised to see so many negative comments here. Wondering if wheelchair users were hated back in the days when the law about wheelchair ramps was passed. Accessibility of websites is a real problem for blind people. And the thing is it is relatively easy to make your website accessible:

* Use simple HTML controls: all of them work great in all screenreaders. Only when custom behavior is implemented in javascript this might cause problems. * Test accessibility with keyboard. That fancy combobox that you wrote that expands with beautiful navigation cannot be opened from keyboard.

This ADA guidance actually doesn't even mention this. Sure, providing alt descriptions can be useful but it's almost never preventing me from using a website. But a combobox or a button that won't click is a real problem. But I hope this is just the first step in making Internet more blind-friendly.

Blind developer here. Even though web technology might move fast, things move slowly in the world of accessibility.

You're saying it's too hard to catch up with the latest technology - I wouldn't agree with this in the context of accessibility. What happens in practice is that a frontend developer develops for example a fancy combobox that needs to be clicked on with a mouse without thinking twice. And that combo box stays on the website for years. Now suppose that's a website to book flights. I go there and I spend half an hour trying to click that damn combobox with a keyboard and still it wouldn't allow me to select anything. Well too bad, it turns out I cannot fly XXX airlines. Or I'd have to wait for my sighted assistant who comes once a week to deal with these websites.

And what if I told you that half of websites on the internet are like this - that is not accessible or extremely ahrd to use? I have to avoid certain online stores, certain airlines, certain hotels because of that. Finally I work in faang company and so many internal web tools here are not accessible. I found my way around, but I have seen blind people being fired for not being able to perform while every other tool that is required for you to use doesn't work with your screenreader and nobody cares to fix that?

And what's the price to fix it? Educate developers to use simple combobox instead of fancy one? Try to test it with keyboard? Are blind people really asking for too much?

And also regarding getting sued - I have no idea what kind of lawyers can sue for this, I have never heard of actual blind people being able to sue someone because the website was not accessible. If that was the case I would be able to sue half of Internet including Google, Facebook, Amazon, and so many more. I suspect certain lawyers are taking advantage of the system - e.g. there was this american life episode years ago about a lawyer who is specializing on suing hotels that claim to provide acomodations for disabled people -wheel chair users - and they don't satisfy ADA requirements or something. I suspect this Domino pizza lawsuit was initiated by similar type of ADA troll lawyer. Don't compare blind people to troll lawyers!

Ah, you're right, CodeMirror 6 appears to be more accessible. However it still only shows one line at a time. So that's still worse than Monaco. Monaco can show one or two hundred lines at a time. So with CodeMirror 6 I still would have to read text line by line without any way to skip a function for example, which is unnecesarily tedious.

Sure, I understand that people don't have infinite time to spend on perfect accessibility. I was careful not to have any blaming tone in my message.

One more point to consider: CodeMirror is not accessible for blind users with screenreaders, as it just presents an empty text area. While Monaco is acdcessible, at least VSCode is. This used to cause a lot of pain for blind people using Jupyter, which uses CodeMirror (or at least used to).

Could it be that Boeing engineers made this presentation vague and confusing on purpose? I mean the article presumes that the engineers had poor PowerPoint skills, but it seems to me that this could have been cover-your-ass type of situation (also perhaps similar to Challenger disaster story).

I mean obviously Boeing engineers need to communicate to NASA their assessment of the situation, but they don't want to be blamed for any technical difficulties (e.g. if second shuttle would have to be launched to save the crew). So they think Columbia will probably be fine, but let's communicate our worries to NASA, but let's do that in deliberately vague and conspicuous language, in hope that NASA managers won't see the fine print.

10 years ago I found even more outrageous bug in Windows 8.

I was working in MSFT back than and I was writing a tool that produced 10 GB of data in TSV format , that I wanted to stream into gzip so that later this file would be sent over the network. When the other side received the file they would gunzip it successfully, but inside there would be mostly correct TSV data with some chunks of random binary garbage. Turned out that pipe operator was somehow causing this.

As a responsible citizen I tried to report it to the right team and there I ran into problems. Apparently no one in Windows wants to deal with bugs. IIt was ridiculously hard to report this while being an employee, I can't imagine anyone being able to report similar bugs from outside. And even though I reported that bug I saw no activity in it when I was leaving the company.

However I just tried to quickly reproduce it on Windows 10 and it wouldn't reproduce. Maybe I forgot some details of that bug or maybe indeed they fixed this by now.

Blind developer here. If anyone wants to use computer without a mouse, I can also recommend screenreaders for the blind, such as NVDA. Blind people have to use screenreaders,, but if anyone sighted has such an aversion to mouse, why not try a screenreader. They allow to control all applications (including browsers, IDEs, anything else) purely from keyboard without mouse. It's a lot of work to learn all the shortcuts though, I would have thought it's not worth it, but looking at people developing this kind of mouse-free tools, maybe someone might find it worth the time.

NVDA: https://www.nvaccess.org/download/

Just having raw Tex code for the formula would be already immensely helpful. Right now we're in the situation that the information about formulas is lost for screenreader users. Once there's raw Tex formula, then screenreader developers, myself included, can come up with many different ways to present formulas in more convenient form. But again, so far, the raw tex code of the formulas is lost, and apparently it seems to be either incredibly hard to embed it into PDFs or something - judging by so little progress in this direction over the last decade.

Could you elaborate on this? Like a link to a concrete project/discussion? I am visually impaired too and I did my own research on this topic a while ago. It appears that in the past decade or two there have been a few attempts to improve accessibility of Latex generated PDFs, but none of them seems to have accomplished the goal and pretty much all of them are dead projects now. I would be happy if there's an ongoing project.

I had a 5 years gap in my career - all medical. Recently, right after that gap, I was intervieweing with multiple companies - most of them didn't even ask me, even though I was worried as hell. In the end I got almost all job offers I wanted. The only notable exception that didn't even grant me a phone screen was Amazon, their recruiter told me that ML has advanced so much in those 5 years that all my prior experience is totally irrelevant to them anymore. Oh, really. Whatever. In the end I ended up joining Facebook.

So with your 12 months gap and your prior experience, I would say nothing to worry about.

I come from Russia, where the idea of gifted classes is taken to the next level: instead of gifted classes we have entire gifted schools. If this is true, that children who coudln't make it into gifted class are so much demoralized by the presence of gifted children, how about we build gifted schools here in the U.S.? This way non-gifted students won't be exposed to gifted ones on a dayily basis. Transportation might be an issue though - in Russia it is absolutely normal when 8 or 9-year old children take public transportation to school on their own.

The new engines were too big to fit in their traditional spot under the wings. To combat the problem, Boeing mounted them forward on the wings. Moving the engine position forward shifted the plane’s center of gravity, which altered the aerodynamics of the aircraft. The position of the new engines pulled the 737 tail down, pushed its nose up, and put it at risk of stalling.

Can someone explain to me how this is possible? In my understanding If you move the engines forward, it would move the center of gravity forward as well, and this would push the tail up and pull the nose down - exactly the opposite from what's written in the article. Does some fancy aerodynamic effect play some role here that leads to stalling?

I actually work more in backend area, so I am not that familiar with accessibility standards in HTML. I am only a user there. But looks like others have already answered some of your questions.

You don't need any non-standard input elements to make web site accessible. In fact the opposite is true: if you only use standard HTML elements, chances are your web-site is going to be fully accessible. It is when developers decide to use some fancy javascript instead of a standard button, or some other fancy form controls, with tons of javascript, this is when screenreaders tend to have problems trying to figure out what's going on.

For small businesses I imagine the biggest problem is that they only have only one engineer to support a web site, and he is not familiar with accessibility standards (justifyably so, because there are so few blind people out there), and he'd have to learn these standards and test the web site for accessibility problems - all these actions require time.

Microsoft Word is fully accessible. As for PDFs, as long as they are not scanned, most likely they are accessible. Sometimes forms in PDF files are not very accessible.

And also every now and then I need to read a science paper in PDF format - somehow they still haven't figure out how to make accessible formulas in Latex-generated PDFs, so I'd have to use an OCR called InftyReader to OCR this PDF to get the formulas.

In my experience the worst offenders are drivers for printers and scanners. Every time my printer runs out of ink on my computer it'll show me a dialog, that my screenreader doesn't recognize at all. So by the presence of empty window I'll have to deduce that it's running out of ink. Scanner driver is completely inaccessible, so I had to get a linux box just to use my scanner - at least all the command-line tools are accessible.

I appreciate this feedback, I'll keep it in mind for my future comments.

And by the way, it is very common that people can't find words to give me feedback - happens pretty often. So I encourage people to give me feedback - no need to feel like ass :)

None that I'm aware of. The problem is checking whether a web site is accessible is a manual operation and therefore time-consuming. And it often happens that companies break accessibility, and then they fix it, and then they break it again...

The big three are Jaws and NVDA for Windows and VoiceOver for Mac. You probably don't need to test with all three every time since they are similar in terms of what kind of content they can access on the pages. But each of them has its own quirks, there are web-pages that only one of them can read.

Yes, touch-typing. I feel when my fingers hit two keys at the same time - that's the time to go back and check the previous word for spelling mistakes. And I use screenreader to read things for me.

I work in a big IT company and often times internal tools are not very accessible. Sometimes when I talk to their respective maintainers, they are willing to help me, but they don't know what is accessibility and what is screenreader. Is there a good document on how to make web sites accessible that I can show them?