Comment by mwcampbell
7 hours ago
The thing that always worries me about these clean-slate designs is the fear that they'll ignore accessibility for disabled people, e.g. blind people, and then either the system will remain inaccessible, or accessibility will have to be retrofitted later.
It's funny you mention that because the first thing I thought when viewing this page was "is this a loading state? why is everything grey?".
Ahem. It's _radiant_ grey.
I like the design. Minimal and loaded fast. I haven't dug into the pages' code but I'm guessing there's little or no bloated JavaScript.
I thought "is there one of those popups covering things and greying out the page until you close it?"
I'm actually ok with that if it truly serving the purpose for what a computer should be.
I think those principles would embody the notion that the same thing cannot serve all people equally. Simultaneously, for people to interact, interoperability is required. For example, I don't think everyone should use the same word processor. It is likely that blind people would be served best by a word processor designed by blind people. Interoperable systems would aim to neither penalise or favour users for using a different program for the same task.
I also think for the purpose of piloting a new system I don't mind people chasing whatever aspect of that mission most inspires them. Anything aspiring to be a universal paradigm needs to account for accessibility to have legitimacy in being "for everyone" but that doesn't necessarily have to be the scope when you're starting.
I'd like to think that prioritizing early phase momentum of computing projects leads to more flowers blooming, and ultimately more accessibility-enabled projects in the long run.
Yeah, this is concerning. Although, if the system is architected well, accessibility features ought to be something that can be added as an extension.
What is a screen reader but something that can read the screen? It needs metadata from the GUI, which ought to be available if the system is correctly architected. It needs navigation order, which ought to be something that can be added later with a separate metadata channel (since navigation order should be completely decoupled from the implementation of the GUI).
The other topic of accessibility a la Steve Yegge: the entire system should be approachable to non-experts. That's already in their mission statement.
I think that the systems of the past have trained us to expect a lack of dynamism and configurability. There is some value to supporting existing screen-readers, like ORCA, since power users have scripts and whatnot. But my take is that if you provide a good mechanism that supports the primitive functionality and support generalized extensibility, then new and better systems can emerge organically. I don't use accessibility software, but I can't imagine it's perfect. It's probably ripe for its own reformation as well.
> What is a screen reader but something that can read the screen?
Good screen readers track GUI state which makes it hard to tack on accessibility after the fact. They depend on the identity of the elements on the screen so they can detect relevant changes.
For all the complaints leveled at Apple, their accessibility on their OS's is astounding.
It is said if we live long enough, we all will be disabled at some point.