Software Preservation Dilemma: Accessibility versus Authenticity

In a previous blog post, I introduced Re-Resolver, our experimental software preservation project in which we attempt to recreate the classic, but no longer functional iOS app Resolver by analyzing its features and rewriting the app from scratch. Re-Resolver is open source and available on GitHub, and will be made available on the app store later this summer.

With the project, we are exploring this method of software preservation to find questions. Is this really preservation, or is it something else? Is this method worth the effort?

In this blog entry I’ll focus specifically on one unexpected dilemma that came up while trying to duplicate the original app: the conflict between accessibility and authenticity.

The accessibility dilemma

In the Re-Resolver, our intention was to create software that is as close to the original Resolver app as possible. This means looking at the features of the original app, recreating those features as closely as possible, and not adding, modifying, or removing features. If the feature set of the software changes, then we would be creating a different piece of software.

What if we view software accessibility as a feature? If we have the opportunity to make the app more accessible, should we do so, or does this conflict with the preservation effort by making it historically inaccurate? If our view of software preservation is very liberal, we might be able to convince ourselves that, yes, we are preserving the original software, and our accessibility improvements are part of a new version of the same software.

What level of effort would be involved in making software more accessible, should we decide to go that route?

While it may be difficult to do a complete accessibility audit, it is relatively easy to find and make changes that will improve the experience of using software for at least some users. As an example, here’s a video that demonstrates the process of finding potential improvements in our Re-Resolver project by enabling VoiceOver, screen-reader software that is built into iPhones.

Using VoiceOver in the app as shown in the video above uncovers or confirms three problems that I wanted to fix:

  1. The image name “reresolver_button_300pt” is used by VoiceOver as the name of the blank buttons on the “Ask” and “Decide” screens. There is also no accessibility hint.
  2. On the “New Choice” screen, the Textfield is given the generic name “Textfield” by VoiceOver, with no hint.
  3. Shaking the phone to get a new answer causes the text to change on the button, but VoiceOver does not read the new text.

Did the original Resolver app also have these issues? VoiceOver on the iPhone was released in June of 2009, according to Michael Hansen of AppleVis. This was not long before the app released, so it’s possible that the developers did not take this technology into account. I went back to testing on Amanda’s iOS 7 device, and discovered that the original app varied slightly, but did have some similar issues.

  1. The button on the “Ask” and “Decide” screens is called “Answer” by VoiceOver, but there is no accessibility hint.
  2. The “New Choice” screen in the original app is also given the generic name “Textfield”, with no accessibility hint.
  3. Shaking the phone for a new answer will not cause the new text to be read by VoiceOver.
  4. Tapping the button for a new answer will only cause the new text to be read if the label on the button – not the enclosing button – is highlighted by VoiceOver when the tap takes place.

Our initial goal was to duplicate the original app as much as possible, so we could have decided to leave the accessibility problems in Re-Resolver, or even to spend effort to make the accessibility issues in the new app match the issues present in the old app.

Even though the original app had similar problems, I made a decision to attempt to improve VoiceOver compatibility in in the new, restored app. Ultimately, I want people to use our work.

Using the Accessibility Inspector

I cheated before I made the above video, and used the new accessibility audit feature in Xcode’s accessibility inspector, which is described in this video from the Apple Worldwide Developers Conference. It makes it even easier to find certain problems. With the accessibility auditor, you can run an app in the simulator or on an actual device, and then press the “Run audit” button, which will find a list of potential problems on the current app screen, highlight the problem areas on the screen, and give a possible solution for each problem.

Audit ask image name used in description

In the example shown above, the accessibility auditor is reporting the problem with the blank button on the “Ask” screen. The inspector has highlighted the problem area in blue on the simulator. The inspector has given a description of the problem – “Image name used in description: The label of this UIButton is an Image File Name”. Clicking on the question mark will give the potential solution for the problem, “Set a human readable, localized accessibilityLabel”, with a link to documentation.

Making the changes to the app

Once it was determined which changes needed to be made to the app, making these changes turned out to be quite simple. As you can see, Xcode tries to make it easy for us with a Label and Hint property exposed within the editor.

Cropped results hint xcode

The change for the TextField followed a similar pattern. While this set the initial accessibility label for the button, some minor code changes were also needed to change the accessibility label when the text on the button changed.

Here are the code changes to update the accessibility label for the button when it is pressed. ( A preceding minus sign indicates that a line of code was removed; a plus sign indicates that a line was added. )

-        button.setTitle(choiceList.choose(), forState: .Normal)
+        let choice = choiceList.choose()
+        button.setTitle(choice, forState: .Normal)
+        choiceButton.accessibilityLabel = choice

When testing, I found that VoiceOver automatically read the new text when it was updated.

The code that is used when the device is shaken is similar, but adds an extra line that tells VoiceOver to speak the changed answer.

-        self.choiceButton.setTitle(self.choiceList.choose(), forState: .Normal)
+        let choice = self.choiceList.choose()
+        self.choiceButton.setTitle(choice, forState: .Normal)
+        self.choiceButton.accessibilityLabel = choice
+        // If VoiceOver is enabled, speak the new result
+        UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, choice)

We’d need some additional modifications in order to internationalize the app by supporting other languages, but we haven’t committed to doing that yet. So that’s it, the simple code and editor changes needed to make the three accessibility improvements for our project.

Concluding: Accessibility is more important than historical fidelity

For our particular preservation project, adding accessibility improvements was a simple decision. The problems mentioned here were easy to detect and easy to fix, and don’t increase the cost of the project significantly. More important than cost, the changes help people to use the software. Yes, we’re trying to recreate the behavior and experience as it was before, but allowing more people to experience the software without changing the feel for others seems like the right thing to do. Historians won’t be looking at our duplication project to answer important questions about precisely how the original app functioned or malfunctioned, and no user will care that the code used to perform the restoration is completely different from the original. The project is about restoring access to the people.

Just as with other forms of preservation, we have to consider the intended usage when we make decisions about implementation. Performing OCR scans on printed books and giving them a new, machine readable layout preserves the important text and serves one group of patrons; providing digital images of the actual pages preserves notes in the margins and serves another group of patrons.

In the previous blog post, a hypothetical case of receiving obsolete video files on obsolete storage was remedied by transcoding the video files to a more widely used format, and placing the videos online. We’ve performed a similar service here and have preserved the content in a way that is usable to the greatest number of people, by improving accessibility.

Please post comments to the blog!


1 thought on “Software Preservation Dilemma: Accessibility versus Authenticity

  1. Pingback: One month after release, our app has six users | Marooned Librarian

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s