eBraille: Inception to Reality

A new file standard will soon be available for braille readers! Created by APH and partners around the world, eBraille allows braille and tactile graphics to be read together in one electronic document for the first time ever. It will also work on any multiline braille display, including the Monarch, which is set to release in September 2024.

Creation of eBraille

“We’re at the beginning of another braille revolution,” said Willow Free, co-chair of the eBraille Working Group. The first major multiline braille display release, it won’t be the last. The current braille file types are not reflowable, requiring each page size to be made separately. “Without a file type that has reflow ability, we would be at risk of transcribers needing to make braille for the Monarch, for a standard braille display, and for each new multiline display. Our braille libraries would become even more segregated by page size and hardware limitations,” said Willow. To have this reflow ability, a braille file type that utilizes markup─tagging that keeps your formatting from being hardcoded, among other benefits, is crucial.

“The initial idea for eBraille came from BrailleBlaster, APH’s braille transcription software. When NIMAS XML files from the National Instructional Materials Access Center (NIMAC) open in Braille Blaster, the program looks at the tags in the file and finds how those tags correspond to braille. To make eBraille, we’re doing the same process in reverse by applying tags to braille formatting. We knew we would need help from the rest of the field to implement the idea.”

Afterwards, the concept of eBraille was shared with the field, and APH created a partnership with the DAISY Consortium. “They reached out to folks with us, and we started forming a working group. Now, we’ve got over 40 organizations around the world working together to build this eBraille standard,” said Willow. The group began by crafting a problem statement and principles they will use to solve it. Discussions ensued about what the standard should and shouldn’t do before they started creating eBraille.

Practice Documents

APH and its partners are developing four documents that contain best practices for making eBraille files. The first one discusses how you should tag an eBraille document. “We’re working on number two now, which is metadata─ data about data. This includes the title, subject, author, braille code, language, and other items that computers want to be able to read without opening the file,” said Willow. Metadata helps libraries and publishing houses keep their braille collections organized and easily searchable by users. The third document is the CSS, which tells you how to format the things you’ve tagged, and the fourth is about how to package an eBraille document, which will be like the way an EPUB file is presented to users. Those documents are also in development. To learn more about the work being done to make the Best Practice documents, visit this GitHub page.

The technical aspects of the standard are meant for software developers so they can make software that both creates and reads eBraille files. Willow explained, “The average user doesn’t need to know this when they’re making their own eBraille files because they will make it in a similar way to how they make braille now. You’ll use your braille transcription software, apply styles to braille, and then the only thing that’s going to change is at the end. When you go to save the file, you’ll save the tags you made instead of throwing them out like you do when you create a BRF.”

What Happens When eBraille Development is Finished?

When eBraille is close to being released to the public, APH and its partners will send out exemplars, or perfect examples of eBraille files, to software developers. “We’ll make several exemplars that showcase how eBraille works, and software developers will use those to figure out how to support eBraille in their reading software,” said Willow. “We’ll also make a validator for creating eBraille. For example, if BrailleBlaster makes an eBraille file, we would run that document through the validator. It will tell us either, ‘Yes, this is a valid eBraille file,’ or ‘No, it is not valid, and here’s why.’ Then, we would go back to BrailleBlaster and fix whatever we did that wasn’t right.”

While these tools are primarily for software developers, average users can also check them out after they launch.

Join the eBraille mailing list to continue to receive updates about this revolutionary new file standard.