Braille Monitor                                                 October 2011

(back) (contents) (next)

The Evolution of Braille:
Can the Past Help Plan the Future?
Part two of a three-part article

by the Braille Authority of North America (BANA)

From the Editor: In the May 2011 issue we published part one of this article prepared by the Braille Authority of North America. Here is part two:

Part one of this article gave an overview of the vast changes that have occurred in both print and Braille in the last few decades. This installment provides background on the Braille Authority of North America as well as a glimpse into its deliberations. The article also offers perspectives on the challenges of producing Braille today, given current codes and current production methods.

The Workings of the Braille Authority of North America

The mission of the Braille Authority of North America (BANA) is to assure literacy for tactile readers through standardization of Braille and/or tactile graphics. BANA's purpose is to promote and facilitate the use, teaching, and production of Braille. It publishes rules, interprets those rules, and renders opinions pertaining to Braille in all existing and future codes. It deals with codes now in existence or to be developed in the future, in collaboration with other countries using English Braille. In exercising its function and authority, BANA considers the effects of its decisions on other existing Braille codes and formats, the ease of production by various methods, and the acceptability to readers.

The board of BANA and all of its committees are made up of educators, transcribers, Braille producers, and Braille readers. More than a hundred people are involved in BANA's work.

As language changes, the need for new ways to represent things in Braille continues to require new symbols and new uses of current symbols. Braille readers need access to the same information as do their print-reading counterparts in this age in which the norms for printed material are evolving rapidly.

Despite the need to respond to the changes in language, making changes in Braille is not easy. BANA must deliberate very carefully before making even small changes to Braille. It is essential that BANA consider the impact of any changes on readability, writeability (that is, how easy it is to write the code using various tools), computability (how accurately it can be translated and represented electronically), space considerations, familiarity to current Braille readers, and so on. There are many goals to balance, and not all of them can be achieved effectively all of the time. The benefits of making any change must be shown to outweigh the drawbacks. For example, when the term and icon for the euro were adopted in Europe in 1995, a Braille symbol had to be invented to represent that new print symbol. In 2007 BANA adopted new symbols for copyright and trademark; before that, the practice had been to spell out the word, even though a print symbol was used in the original text. BANA cannot ignore the changing conventions of print without putting Braille readers at a significant disadvantage. The current process of keeping up has been to add new symbols as they come up, but, with each new symbol and each new rule change, more ambiguity and more conflict are being created in Braille. An example of this is given later in this article.

The following case provides a look into the workings of one of the BANA technical committees and the process through which decisions are weighed and made. Each technical committee of BANA works on various charges regarding changes and clarifications to a particular Braille code. The committees work via email and teleconferences and provide written reports of their progress to the BANA board for each of its semi-annual meetings. The Literary Braille Technical Committee was working on the seemingly simple task of deciding how to show emphasis of a part of a word. Partially emphasized words—that is, using indicators to identify bold or colored print or other font changes—are appearing with increasing frequency in elementary school textbooks, as well as in other materials that include challenging text such as product brand names, as is discussed later in this article. The committee’s report to the board in the fall of 2006 included the following informal narrative as an illustration of the process by which the committee members approached this task. Read along and follow their thinking as they attempt to resolve this issue:

First: We decide, following our principles, not to add a hyphen to signal the transition between regular print and italic or fully capitalized print, giving the Braille reader more accurate information about the print text. Of course we all want to do that.

Second: We decide to use the termination indicator as necessary to end italics or all caps. That looks good. All is going well. This is going to be easy!

Third: Someone points out that, following these rules, an italic indicator could come before an e, n, s, d, or t, causing confusion between the italicized letter and a contraction.

Fourth: We then consider the letter sign to fix the problem; no, that won't work. It's not clear to the reader.

Fifth: OK, we'll require uncontracted Braille in partially emphasized words. That's consistent with the current Braille Formats guidelines.

Sixth: That would solve the problem, but how is the reader going to know that this is uncontracted Braille? Sometimes a contraction not used early in the word will be a tip-off. Maybe the problem contraction will be the only one. Then the reader may have to stop to think a minute, but, if reasonably well educated, will probably be able to figure it out. It will be even easier if the reader happens to know the rule about use of uncontracted Braille in this instance. How often will one find the word "uses" with the final s in italics? I guess even then the reader could probably tell whether "uses" or "useless" were intended. Sigh . . . Not a perfect fix—especially in textbooks for children in elementary grades.

What number are we on now? Well, maybe those hyphens weren't so bad after all. Now, why was it we wanted to get rid of them? Oh, that's right, to give the Braille reader accurate information about the print. How about making a symbol meaning "uncontracted Braille coming”? That would solve the problem completely. Wow! Let's do it.

Now what symbol should we use: a. Double letter sign? We could, but then we'd have to change the non-Latin passage indicator. b. Three letter signs? Too long—it will never fly. c. Letter sign followed by dots 2-3? That's kind of nice, but we'll have to be sure we don't want to use the letter sign for out-of-place punctuation. That will take a long time.

Are we having fun yet? We thought this would be so easy to solve!

Code building is a more challenging task than it first appears; even simple fixes become complicated given the complexities of our current codes. The literary Braille code was not designed to be "extensible” – that is, there are no clear and specific rules for building and changing symbols in a logical fashion. Right now every proposed change to the Braille code has to be considered individually in an ad hoc fashion.

Current Challenges in Transcription, Translation, and Backtranslation of Braille

As discussed in the first part of this article, Braille transcribers often use Braille-translation software to make their work more efficient. Braille-translation software converts the text in an electronic document into characters that can be embossed in Braille onto paper or that can be shown on a refreshable Braille display. The software is written so that, as much as possible, it follows the rules for correct usage and placement of Braille contractions and symbols. While this software can often do a very good job of converting print characters into Braille symbols, there are still some situations in which a transcriber must intervene in order to produce accurate and comprehensible Braille. Charts and tables, descriptions of pictures, and transcription of spatial arithmetic are some obvious examples. However, other instances may be less obvious. Currently, human intervention is often required for such details as ensuring correct use of single and double quotation marks, proper displaying of acronyms and web addresses, handling of long passages written in all uppercase letters, removing excessive emphasis indication, correct use of dashes and hyphens, to name only a few. The intervention is largely required because the way these items are handled in print can vary greatly from document to document, and the rules for their use are far more restrictive in Braille than they are in print. Transcribers may need to follow additional steps to change an electronic file into correct Braille in other situations as well, such as changing decorative letters into text because the software does not recognize these images as letters.

A transcriber can produce Braille that can be read either on paper or on a refreshable Braille display. However, as Braille readers gain greater access to refreshable Braille displays, the more common scenario is that they are using the displays to read directly from the screens of computers and mobile devices, and no transcriber is involved. Using this on-the-fly translation without transcriber intervention, the texts are often displayed incorrectly. Here are three examples:

Example 1. According to current codes, email addresses should be Brailled in Computer Braille Code so that each character in the address is clear to the reader. Yet, when reading in contracted refreshable Braille from a computer screen, an email address will display in contracted literary Braille, making the characters ambiguous. The user can take steps to view the address with no translation applied, but then the surrounding text is also displayed in uncoded characters. Special symbols often display incorrectly. For example, both the tilde and the caret display as dots 4-5. The underline character displays as dots 4-6, no matter where it is, creating confusion with the print “dot” that appears in virtually every electronic address. These ambiguities can make for garbled translations and incorrect information to the reader.

Example 2. There is often a great deal of confusion among single quotation marks, apostrophes, and accent marks. Because of the various ways these symbols are used in print, sometimes inner quotation marks display in refreshable Braille as apostrophes (dot 3), and sometimes a mark that is intended as an apostrophe or accent mark is shown as an opening inner quotation mark (dots 6, 2-3-6).

Example 3. When the sentence “H2O = water” is displayed in refreshable Braille, the fact that the 2 is subscripted is usually ignored, and the equal sign may display as a full cell. If, as in this example, it is spaced away from the formula, the sentence reads instead as “H2O for water.” What's more, the way these situations are handled varies depending upon the screen reader or translation program being used; for instance, some programs simply display the = sign as the word "equals" instead of the symbol. Therefore the Braille reader is not getting the same information as the print reader of this text.

Changing print conventions further complicate the job of accurate Braille translation. In some situations it is unclear how to Braille something correctly at all, according to the current BANA codes. For example, a dollar sign most often comes at the beginning of a string of numbers, and the Braille symbol for the dollar sign in the literary code (dots 2-5-6 when placed before a number sign) seems to have been chosen with the assumption that this would always be the case. Unlike the print dollar sign, the Braille symbol is dependent upon its placement for its meaning; in other contexts dots 2-5-6 has numerous possible meanings. How, then, should we handle the name of the pop music sensation that is pronounced "Kesha," but who uses a dollar sign instead of an s in the middle of her name?

According to the literary Braille code, an out-of-place dollar sign should be Brailled as dot-4, 2-5-6, that is, dot-4 dollar sign. This seems to work when the dollar sign is by itself or when it follows a number or is in a context that refers to currency. Since the dot 4 also can stand for some kind of accent or letter modification and is also used as a “print symbol indicator,” the Braille reader might be quite puzzled to have dot 4, dots 2-5-6 turn up in the middle of a person’s name.

For clarity, should the name Ke$ha simply be Brailled with an s instead of a dollar sign? That solution might work for readability, but it does not provide the Braille reader the same information that the print reader has. A transcriber encountering this name may spell it “Kesha,” but include a transcriber's note indicating that the s is shown as a dollar sign in print. Of course, this solution is clear, but it requires the involvement of a transcriber rather than the name automatically and correctly displaying on a Braille device.

"But there is an easy fix," the astute Braille reader may say. "There is a perfectly good symbol for the dollar sign in the math code—BANA should just use that in the literary code, too." The dot-4 s may work because it is unambiguous and is associated with the shape of the print dollar sign. However, a change of the literary dollar sign to the one used in the Nemeth Code would require use of different rules from those that apply in the Nemeth code. In the literary code a number sign is required after the currency symbol if it precedes numbers and the numbers are in the top of the cell. However, in Nemeth code, there would be no number sign following the dollar sign, and the numbers are Brailled in the lower part of the cell. Even with this approach, consistency still has not been established.

The example above of the out-of-place dollar sign is not an isolated instance. There are countless other examples of words written in ways that make it difficult to apply some of the context-based Braille rules developed many decades ago. For example, brand and company names, such as the sports store FanNation and the online service, use creative punctuation and capitalization to make their names stand out, but also make an exact representation in Braille more complex. If a company uses nonstandard symbols in its name and a blind person misspells the company name on a cover letter for a job application because she did not get accurate information from the Braille, what are the chances that person will get the job? Should she have to check the spelling using audio or relying on a sighted person to tell her how it is spelled, or should Braille, the primary literacy tool for people who are blind, be capable of giving the most accurate information?

Aside from the difficulties in literary contexts, it is becoming increasingly problematic that a completely different code is used for mathematical and technical materials. These materials do not currently translate correctly with the use of software that does not include transcriber intervention. The need for a solution to this issue is ever more urgent as mathematical and computer code expressions increasingly appear in everyday contexts.

To be clear, at this moment no known solution would completely eliminate the need for a trained transcriber to intervene in order to verify that the format of an embossed Braille document is clear and conveys enough information about the layout of a print page or document. This is especially true in educational materials. Transcribers will likely always be needed for creating tactile graphics, complex mathematics and science materials, and other complicated written matter. It would be much more productive, however, if their work could be focused on these difficult materials rather than on ensuring that each and every dot in the text is correct. The more frequently human intervention and judgment calls must be made, the more likely Braille production will be delayed, costs will be increased, and the Braille will be less accurate.

Another area of concern is backtranslation, the process by which software converts contracted Braille materials into print. Backtranslation is most often used when a person creates a document in Braille on a computer or other electronic device and then either prints the document, emails it, or simply saves it into a mainstream file type. This process can be especially useful for Braille-using students who need to write in Braille to support their developing Braille literacy, but who also need for their work to be readable by their non-Braille-reading teachers and by fellow students with whom they may collaborate on projects. In the workplace Braille readers can also benefit from the ability to type text using the computer keyboard as a sort of electronic Brailler by using six keys or by attaching other Braille devices, thus producing text readable as print by someone who does not read Braille. The software and hardware exist for this need to be met in a seamless way, but sometimes problems occur during the process of backtranslation—even when the person who typed in Braille followed the rules of the code perfectly. Many of the examples given in this article are also problematic when dealing with backtranslation.

When a Braille reader reads a document that has been translated from a print original, reading itself is a form of backtranslation. The Braille document gives the Braille reader information about the print original. Ideally that information is both complete and accurate. The more print changes, the greater is the inability of the current Braille codes to do that job.


It is, without question, desirable for users to have independent access to Braille materials. The proliferation of Braille-translation software, of Braille embossers, and of refreshable Braille displays has given Braille readers more access to Braille from more sources than ever before. With this greater access has come the need to consider multiple factors in the development of new rules and symbols for Braille. In order to meet the needs of today, which are different from those of past decades, Braille needs some systematic changes that will allow for the following:

It is clear that BANA cannot continue to adjust the codes on a symbol-by-symbol basis. Our community needs a flexible code that can grow with the English language and the changing ways it is represented in print. Braille needs to translate into and from print with complete accuracy. To keep up with growing demands, Braille needs to be produced more quickly and with less human intervention than is currently required. BANA is considering solutions that will permit this. The third installment of this three-part article will outline these potential solutions.

(back) (contents) (next)