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

Lately on Waffle

First Steps

Ars Technica:

Google has decided to reverse its long-standing policy requiring users to use their real names to make profiles on the service as of Tuesday, according to a post shared on the official account. The move comes after Google+ head Vic Gundotra suddenly departed in April, marking the beginning of a shift for the service.

As someone noted, it’s too little, too late in terms of bringing these people to Google+. But it is a good first step in undoing the litany of horrible decisions that have been made, particularly with the goal of pushing people towards Google+. It’s a step that has lasting value only as part of a longer commitment in recognizing what everyone outside (and quite a few inside) have known all along: that forcing people to use a community site does not a healthy community site or relationship make.


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.

Older posts »