The Journey Toward Braille: Potential and Limitations of using Braille with iDevices
By Jennifer Dunnam
Today, with the right resources and in the right circumstances, it is possible for a Braille reader to purchase a book the same day it is released by the publisher, at the same price paid by the print reader, and read it immediately on a mobile device in reasonably good quality Braille. If a book in another language is acquired, the Braille reader can quickly make some adjustments using the Braille display, and presto, the book is displayed in largely correct Braille for the additional language. Likewise, it is now possible to write a document, message, or anything else using the six keys of a Braille display, and the words are almost instantaneously translated to print, ready for sharing with anyone. Apple has been one of the major forces in making these previously unimaginable developments possible within the past few years.
The recent release of iOS 7 and of NLS's new BARD Mobile app makes this a good time to take a look at the state of Braille access to digital content. Seamless access to content in Braille is more advanced now than ever before. Yet, an understanding of both the positives and the current limitations is critical for making good decisions about the right solutions for both adults and children and for pushing toward improvements. Here, our focus will be on Apple's iOS platform and VoiceOver, but the issues mentioned here are ones which should be well understood for any screen reading system involving Braille.
Default Braille Translation Table:
Last November, the Braille Authority of North America made a decision to begin a transition to the use of Unified English Braille in the United States. Basically, UEB provides some updates to Braille, making it more amenable to computerized translation from print to Braille and from Braille to print, and adding more representations for print symbols in Braille without creating conflicts within the Braille code. Although it will be several years before UEB is the norm, Apple made UEB the default for English in its current operating system. It is possible to switch back to "English US" Braille translation in VoiceOver's settings. Switching back may be advisable for consistency's sake for children or others currently just learning Braille, since most other sources will still be providing Braille in English US. However, for early adopter types who are confident in their Braille use, the default setting provides a great way to begin getting familiar with UEB. Note that not only will the displayed Braille show in UEB, but the setting will also affect what happens when you write using the six keys. To avoid some backtranslation frustration, take a look at the "Overview of Changes" released by BANA to get up to speed on the changes you will need to implement when writing with the UEB setting on.
Toggling automatic translation:
Speaking of writing, for some time now, Braille users of Apple devices have both praised and lamented the interface for writing Braille using six keys into an iDevice. If one can generally type Braille quickly and flawlessly, the instant backtranslation works quite well. However, for those who type at a more leisurely pace, and whenever some editing is necessary, significant problems arise. If typing is done too slowly, incorrect translation occurs. To go back and fix the resulting mistakes or any other errors, the user must go through many contortions which require a level of skill which should not be necessary to type in Braille and can frankly make Braille seem more complicated than it actually is.
Apple has attempted to address this issue in iOS 7, but unfortunately, the new feature introduces new problems. If "Automatic Translation" is toggled off, one can type at any speed, without any translation being applied until after a press of the spacebar, or the tab key (space with dots 2345), or a specific key combination to activate translation (space with dots 45). However, no Braille shows up on the display at all until after any of these keys are activated. Therefore it is not possible to check what has been Brailled without applying translation. Additionally, the same cumbersome "work-arounds" as before are still necessary when editing. An article by Jonathan Mosen, focusing on this specific issue recently made the rounds: http://mosen.org/index.php/the-apple-Braille-crisis-its-got-to-be-fixed-for-the-kids/ Improvement is needed if refreshable Braille with an iDevice is to be a viable solution for children in education settings.
Display Math Equations in Nemeth:
iOS 7 also includes a new option to "show math equations in Nemeth" (Nemeth being the code for Braille mathematics used in the United States). Some documentation also references the possibility to input math in Nemeth as well. Despite many varied attempts involving reading different types of digital math books and math related web sites (including math samples done according to ePub, MathJax, and other standards), using a variety of math-related apps, and changing settings to all sorts of combinations, the writer of this post has yet to see any Nemeth code shown on the Braille display or to typed Nemeth code that translated to math. The solution may yet be present but undetected; even so, no one should assume that math is ready to go when the Nemeth option is turned on. For one thing, there are some types of math books that will not be addressed at all with this setting. In books in which all of the math problems are graphical images, for example, the text surrounding the math displays in Braille beautifully, but the entire math is simply omitted. In other math, many of the problems could be displayed in Braille, but some features like superscripts and subscripts do not display correctly, making the Braille rendition of the material unreliable at best. There is still a long way to go in this area, and much of it Apple or other companies can do nothing about without cooperation from the publishers of the content.
According to Braille rules, to keep down unnecessary clutter, font attributes such as italics and underlining are not shown in Braille with the same frequency as in print. Often these attributes are for visual appeal and do not affect the meaning of the text. Sometimes, however, they are essential. If the homework assignment is to write down a synonym for each of the underlined words, the underlining must be shown. If the reference notes are superscripted, or if a change in the time period of the story is signaled by the use of italics rather than words, the reader is disadvantaged without the font attributes. Indicators exist in Braille to show the beginning and ending of these attributes, but on iDevices (and with most other screen readers), these indicators are not shown. The only way to get information is letter by letter and with the use of the status cell on the display. The method is cumbersome and requires the reader to seek out the information. With the advent of UEB, the actual Braille indicators will be more practical to use with automatic translation. Some ability to toggle on and off the displaying of these indicators should be implemented before iDevices with Braille can reliably be used in education settings.
Braille Support Sometimes Changes:
The iOS update seems to have broken some previously available features, in the operating system itself and in some specific apps. For example, during testing for this post, it was discovered that Apple's word processing app, Pages, no longer seems to provide Braille output at all when focus is in the canvas as it previously did. Also, some key commands for editing using a Braille display such as "select all" and "copy", no longer work in iOS 7 as they did before. Since updates tend to happen frequently, perhaps at least some of these issues will be fixed by the time you read this. It is important, however, to be aware that the level of accessibility can change unexpectedly.
Good News for Reading Braille:
With NLS's new BARD Mobile app, which came out shortly after the iOS 7 release, the long wait for a reasonable way to read files in Braille-ready format (BRF) on iOS is over. The advantage to BRF format is that it retains the formatting and other features specially intended for Braille reading. Such files are often professionally produced by a Braille transcriber who has described pictures and diagrams, formatted tables in an understandable way, included the necessary font attributes, correctly Brailled math equations, and the like. Previously, to bring these files onto an iOS device in readable form required a lot of effort and technical savvy. Now, for the first time, they can easily be either downloaded from BARD or imported from other sources using Dropbox. BARD Mobile includes no editing capabilities—that is not its purpose—but the ability to read, navigate, and search in BRF's on mobile devices is a significant development. To read a BRF, contractions must be turned off, and "eight-dot Braille" must be turned on. Both of these can be accomplished with shortcut keys (space with dots 1-2-4-5 toggles contractions on and off; space with dots 2-3-6 toggles eight-dot Braille on and off). See the documentation for the BARD mobile app for more details on acquiring and working with BRFs.
There has been much exciting progress on the journey toward improved integration of Braille in the digital world. There remains work to do.