Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.

Lately on Waffle


I’ve been reading about the resolution put out by the (US) National Federation of the Blind where it says that Apple’s been a prince getting technologies like VoiceOver implemented and accepted by default on their products. I haven’t had more than passing relationships with blind people over the course of my life, but it’s far from a foregone conclusion that they’ll be able to use devices productively out of the box. For the longest time, and continuing today, being blind and working with computers meant spending thousands of dollars to get to a frustrating and incomplete experience. It’s a minor stroke of irony that they are largely appreciative of a phone pronounced “eye phone” and which user interface consists of a non-tactile sheet of glass, but it’s a testament to what’s been done for accessibility that it’s not merely a contender against a phone with physical number keys but actually better to use.

The resolution is about asking Apple to do more. Not explicitly in terms of beefing up VoiceOver even more, which is done at a steady clip anyway, but in solving the app problem for them. Accessibility is relatively easy to implement compared to five years ago and/or on any other platform. But because of app churn and constant redesigns — some brought on by Apple’s championship of new technologies, some by the volatile app market, some by switching strategies of app implementation — blind people are finding that with some updates, well-implemented accessibility comes and goes.

If Apple is still standing behind the reasoning for having an App Store, the most simple and straightforward solution to this problem would be one more rule in their App Review Guidelines: “not every app has to be accessible, but if it is accessible, any new update submitted which compromises the accessibility in the published version will be rejected”.

There are two major lines of criticism against this proposal:

#1. “You are robbing the app makers of the privilege to steer their own ship, choose their own features, pivot” — brief interlude to vividly mime throwing up a bit in my mouth — “to what they want to.”


This rule doesn’t say anything about keeping features. They can strip out features into different apps, rework them entirely or slough off four fifths of their entire app. This may backfire on occassion, but as an app maker, you probably know what to do, and if it turns out you don’t, you should be allowed to find that out on your own.

What’s not the case even with the most raging missteps is that some people aren’t able to, in the most literal sense, use the app anymore. It’s not the case that a third, eighth or twelfth of your app’s users will be unable to tap buttons. But reneging on accessibility means exactly this. It is as if you reached into their phones and tore out the buttons, stopped the text from updating, hid entire sections of information and user interface, or labelled half the stuff as “button”, “list item” or “table row”.

Without a doubt, this is horrible. If you’d do this to your sighted users they’d brew a shitstorm heard around the world. But it’s accidentally routine for blind users. Maybe you really haven’t had time to optimize accessibility so that your app is usable with VoiceOver. Fine – we all have priorities, and not everyone needs to cater to every user. There are hopefully other apps in your niche. But this is about reneging on that promise, about tearing out buttons from people’s phones that were there yesterday and are gone today. If you removed those buttons from a third of your sighted users, that would hopefully be caught in review. This just fills in the cognitive gap.

#2. “Sometimes when reimplementing an app, it’s technically complicated to maintain accessibility.”

This is a guess. I am not well-versed in the practicalities of accessibility, although having turned on VoiceOver a few times just to see what it’s like and using Macs, iPads, iPhones and Apple TVs through it, in the pool of everyone who knows how to develop apps, I’m probably sadly in the 20% most well-educated. But it seems like it could be true, especially for native vs hybrid apps (ie an app largely just wrapping a web site).

File bugs. Find workarounds. Reevaluate the technology. Pick this to be one of the metrics you use when comparing different approaches. Let “will the buttons go away for a percentage of our users” be a thing you find out about an approach before you double down on it — it seems like the sort of thing you’d want to keep an eye on.

I can’t find a moral argument against this rule. Being a programmer, even a very user/outcome-centered programmer, I can find a certain amount of sympathy for the technical difficulty of doing this in practice. What I proposed above was the uncompromising rule, where nothing else would do. There’s another formulation of the rule which I think may still make the problem well known, but progress possible in the absence of a perfect technological landscape: “not every app has to be accessible, but if it is accessible, any new update submitted which compromises the accessibility in the published version must be marked as such”. People with VoiceOver on would be given a big warning on the app update screen, and the App Store wouldn’t magically update everyone’s app to the new version. Every app maker would have to recognize the problem (and could still go back to fix it if it was an oversight) and the information would be out there, ripe to use for scorecards, petitioning and record-keeping. And people’s buttons still wouldn’t go missing.

There’s another discussion about how this wouldn’t be needed if it wasn’t for Apple’s insistence (so far at least) on being the gatekeeper of everything every iOS user does with their devices. On how they set themselves up as the arbitrers, but seem to be unwilling to enforce things like this and incapable of removing complete sham apps that sell you settings you already have (hello, Emoji apps). On how if the National Federation of the Blind could have even some sort of favorites list, this sort of thing might not happen. And on how it’s difficult to maintain that you’re looking out for everyone’s best — a sisyphean task at the best of times — when stuff like this is allowed to happen. But I think I’ll let that discussion play out in the mind of the reader.

The Bird Has a Word

Just announced, the official Swift weblog.

Objective-C was well-documented, but there was never a hub for it aside from Apple’s developer documentation. Sure, there was a language guide, but it was all in the service of what you’ll need to know to be able to use these other things that Apple makes.

A language is a skill to be learned, a tool to be used, an instrument to be cherished and increasingly a process in which you can participate. It is both awesome and useful that people are putting the pieces together from what’s been mentioned. It’s going to be even better that they won’t necessarily have to.

Translation From PR-Speak to English of Selected Portions of Apple’s Statement about the Closing of Aperture

(See: “Apple stops development of Aperture“)

With the introduction of the new Photos app and iCloud Photo Library, enabling you to safely store all of your photos in iCloud and access them from anywhere,

We know how important photos are to you and because we just launched a new service letting you have all your photos around at all times without having to worry about managing storage, which is a terrific completion of the whole notion of keeping photos around in digital form,

there will be no new development of Aperture.

we are making the next version of Aperture talk to this treasure-trov–

Ahem. Sorry. Frog in my throat. What I mean is, shut ‘er down, boys.

When Photos for OS X ships next year, users will be able to migrate their existing Aperture libraries to Photos for OS [sic].

When the groundbreaking Lamborghini portable ash tray/coin receptacle ships next year, Lamborghini drivers will be able to migrate their existing pennies and/or cents. Lamborghini’s well-known track record in ad-hoc loose small-denomination currency storage and management is unparalleled and unrepentant.

« Newer posts · Older posts »