Marco Zehe

> I think it would be a grave mistake to simply give up on mixing code with different trust labels in the same address space. Apart from having to redesign lot of software, that would set a hard lower bound on the cost of transitioning between trust zones. It would be much better if hardware mitigations can be designed to be usable within a single address space. I wonder what software redesigns he has in mind. As far as I can tell, best practices are already trending toward only one trust zone per address space. Some might argue that that's the whole point of multiple address spaces. I suspect that Spectre will accelerate this trend. I do know how difficult this kind of change can be. The example I have in mind started before Spectre, and is unique to one platform. On Windows, developers of third-party screen readers for the blind are going through a painful transition where they can no longer inject code into application processes in order to make numerous accessibility API calls with low overhead. This change particularly impacts the way screen readers have been making web pages accessible since 1999. For the curious, here's a blog post on this subject: https://www.marcozehe.de/2017/09/29/rethinking-web-accessibility-on-wi…

Marco Zehe is an Accessibility QA Engineer at Mozilla, he is blind, and he writes on his own site. Two years ago, he wrote a post, "The Firefox developer tools Inspector Panel is becoming accessible" [0]. I don't know how things have progressed since then and I wonder if there are problems particular to Firefox on Linux and Orca, as opposed to other combinations like Firefox for Windows with JAWS or NVDA. [0] https://www.marcozehe.de/2016/05/24/the-firefox-developer-tools-inspec…

The internet suggests that the official desktop/web client is not particularly usable with a screen reader: https://www.marcozehe.de/2016/01/16/status-of-the-accessibility-of-sla… https://slackhq.com/designing-slack-for-everyone-456002920bf2 (talks mostly about the mobile clients, which were designed later) Maybe this has changed recently?

Any idea what the state of accessibility would be at the welcome screen if I ordered this phone? The last update I saw is several months old. http://www.marcozehe.de/2014/02/23/accessibility-in-firefox-os-an-upda…

I'm also a blind software developer. I scrape by building apps[0] and services[1] for other blind people, and running the occasional crowdfunding[2] campaign. 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]…