Skip to content

eBraille MVP

Jump to bottom
wfreeman-aph edited this page Jul 25, 2023 · 3 revisions

Navigation

  • Links- could be either to a location inside the current document or to a location within another document within the eBraille bundle or to an URL
  • The ability to navigate to structural elements
  • Should leave open the possibility to synchronize navigation between several versions of the text (e.g. contracted braille and ink print version of the text)

Semantic markup

This information is necessary so the file can be reflowable for different displays sizes or, for embossing, paper sizes. Also useful for navigation.

  • Headings
  • Paragraphs
  • Lists
  • Tables
  • Page numbers
  • Preformatted content
    • This is material that may not be accurately reflowed and so will need to be navigated both vertically and horizontally or could preclude the text being displayed or embossed using that particular hardware
    • Preformatted content will appear alongside reflowable content and is not segregated in its own file
    • It would be best if we could avoid preformatted content entirely because of the exception it represents to our goal of having an entirely reflowable document but this requirement is in the MVP because it is a compromise we may need to make
  • Braille code changes
    • Identified primarily for backtranslation and potentially for reading system-level Text-to-Speech support.
    • The need to switch braille codes within a single file varies throughout braille regions. In the US, it is common to switch braille codes. The most common example is when switching from UEB for literary material to Nemeth for technical material.
  • Braille grade changes
    • Identified for the same reason as braille code changes.
    • Like switching braille codes, the need for this varies throughout the world but it is common in the US and Canada. In those countries, an example of switching between braille codes would be in a glossary entry that has an example of how the word is pronounced. In examples like this one, the glossary entry is shown contracted, then uncontracted, and then followed by the pronunciation example.
  • Typeforms and emphasis (as they are expressed in braille)
  • Formatting
    • CSS telling the reading software how to display the content according to the local rules of braille.
  • Tactile Graphics
    • Support for at least two appropriate tactile graphic file formats
    • Support for alt text and extended descriptions

Metadata

  • Braille code(s)
    • Identifies any braille codes used in the file.
  • Braille grade(s)
    • Identifies any braille grades used in the file.
  • Recommended braille layout
    • Line per page and cells per line
    • Line spacing (single, double, triple, etc.)
    • This item reflects the recommendation of the braille producer and does not limit the file to the layout specified
  • Tactile graphic file type(s)
    • Support for different tactile graphic file types could vary among different hardware
  • Language(s)
  • Minimum page size
    • This will allow the reading system to know if it's even possible to display or emboss the file using the current hardware
    • Would be determined by any sections that are preformatted and the necessary display size and file type of tactile graphics.
    • Would be on the reading system to interpret this information and know the limitations of the hardware
  • Source document information
    • Title (required)
    • Author (required)
    • ISBN (where applicable)
    • Publisher (where applicable)
  • Encoding
    • Unicode, UTF-8

Implemented at launch

  • 2 authoring tools- these will be software that can be used to make valid eBraille files
  • 1 validator- this tool will ensure that an eBraille file meets the standards of the specification
  • 2 reading solutions- these will be tools that can be used to read eBraille files

Additional design considerations

  • Support multiple versions of the same content inside the publication. For example, one set of files can be of contracted braille and another version of the same content in uncontracted braille, or one set of files can be in braille and other version of files of the same content in print text.
  • Ability to switch from one version to another version of the content file without losing the reading position.
  • Ability to read reflowable braille as well as emboss the braille from the same braille publication. It is worth mentioning that in the principles which we established for this project, we prioritized supporting reflowable braille in case we end up with competing priorities.
Clone this wiki locally