| CARVIEW |
eBraille 1.0
DAISY Specification
More details about this document
- This version:
- https://daisy.org/s/ebraille/1.0/FINAL-ebraille-20250814/
- Latest published version:
- https://daisy.org/s/ebraille/
- Latest editor's draft:
- https://daisy.github.io/ebraille/
- Previous version:
- https://daisy.org/s/ebraille/1.0/CR-ebraille-20250303/
- History:
- Commit history
- Editors:
- Willow Free (American Printing House for the Blind)
- Bert Frees (DAISY Consortium)
- Matt Garrish (DAISY Consortium)
- George Kerscher (DAISY Consortium)
- Charles LaPierre (Benetech)
- Avneesh Singh (DAISY Consortium)
- Feedback:
- GitHub daisy/ebraille (pull requests, new issue, open issues)
Copyright © DAISY Consortium 2023-2025
Abstract
This specification defines eBraille, a digital reading format for braille publications.
eBraille uses an EPUB 3-compatible file set based on the Open Web Platform — using technologies such as XHTML and CSS — to encode braille in semantically enhanced markup and allow it to adapt to the different capabilities of braille reading devices. The file set is designed for both packaged distribution to end users and deployment to the web for online and downloadable reading.
Status of This Document
This section describes the status of this document at the time of its publication.
This document was published by the eBraille Working Group as a DAISY Specification.
This document may be superseded by other documents. The latest revision of this specification can be found at https://daisy.org/activities/standards/ebraille/.
The English version of this specification is the only normative version.
Unlike braille formats that focus on interchanging embosser-ready braille, eBraille focuses on adapting braille for reading in refreshable braille displays with different line lengths.
In order to maintain close alignment with mainstream publishing formats, and simplify transcription of these works, the eBraille format is built on an EPUB 3-compatible file set — it incorporates XHTML documents, CSS, images, audio, and video. This means that an eBraille publication shares its technology with the web, making it compatible for reading in standard web browsers.
An eBraille publication differs from reading a typical web site in that the braille is not transformed on the fly but comes formatted according to the rules of the regional braille code where the publication was produced. Users are not locked into this default display, however. With the display flexibility of CSS, and standardized markup practices, they can apply styles for another region or even modify the display to their own preferences (e.g., by changing the maximum line length).
eBraille publications are also designed to be flexible for deployment. An eBraille publication can be placed on the web, unzipped on a user's local file system, or distributed in EPUB 3-compatible packaging. And as web-compatible file sets, they are adaptable to future changes to publishing formats.
This section is non-normative.
The eBraille file set is designed to be compatible with EPUB 3 [epub3] and adapt to changes to that standard. Distribution and consumption on mainstream EPUB reading systems, however, is not a primary goal of this format. This specification introduces some additional requirements and features beyond those defined in EPUB 3, and it is not expected that mainstream reading systems will adapt to these modifications. Consequently, an eBraille publication may not render exactly as intended outside of eBraille reading systems.
The primary difference between the eBraille format and EPUB 3 is eBraille publications do not
have to be packaged and distributed in an EPUB container
[epub3] — they can be deployed on the web as an unpackaged set of files. An eBraille
publication is packageable in an EPUB container when that is the preferred distribution method, but
eBraille uses the file extension .ebrl not .epub.
Compatibility with EPUB 3 also means that eBraille relies on the same underlying technologies [epub3]. Many of these technologies, like [html], are referred to as "evergreen" or "living" standards as they are updated often and do not have version numbers. Others, like [svg], are referred to without a specific version number so that the latest recommendation is always the recommended one to use.
The practical effect of this approach is predominantly beneficial for eBraille creators. New features become available for use as soon as they are standardized; it is not required to wait for a new revision of the eBraille standard to allow them. The approach does come with some drawbacks, however. eBraille creators also have to keep themselves apprised of changes to the underlying technologies, and use their best judgement in some cases as to whether a new feature is supported well enough in eBraille reading systems to begin deploying. In some rare cases, it may also mean that content that was previously valid may no longer be, but breaking changes like this usually only happen when features are unsupported or are found to have serious security or privacy flaws.
This section is non-normative.
Refer to the eBraille Implementation Report for a list of validators, reading systems, and authoring tools that implement this specification.
This section is non-normative.
The first version of the eBraille format is focused on creating a reading experience that is minimally feature complete for the majority of braille publications. It is not expected that this version will handle every unique formatting requirement of every publication type, but future drafts and versions of this specification will focus on making the format more feature complete.
In particular, the working group expects to review the current support decisions for the following features:
- scripting — the use of JavaScript in eBraille content documents is currently prohibited. The working group is seeking further input on the need for dynamic braille before allowing scripting as the ability to script documents increases the security and privacy risks of the format.
- CSS extensions — the first version of eBraille uses standard CSS properties to format braille content. There may be a need to extend CSS in the future to handle more complex formatting cases, which will also require defining reading system implementations.
- embossing — this version of eBraille is focused on consuming eBraille publications on electronic reading systems, more specifically refreshable braille displays. It is expected that a revision is needed to better account for the use case of embossing publications on paper.
This specification defines the following terms specific to eBraille.
Only the first instance of a term in a section links to its definition.
- eBraille content document
-
eBraille content documents contain all or part of the content of a braille publication. They use a restrictive set of [html] tags and define processing requirements through the use of
classandroleattributes.For more information, refer to 6. eBraille content documents.
- eBraille creator
-
An individual, organization, or process that produces an eBraille publication.
- eBraille file set
-
The set of files that comprise an eBraille publication. The eBraille file set is contained within the publication root.
For more information, refer to 4.2 File and directory structure.
- eBraille publication
-
A logical document entity consisting of a set of interrelated resources.
An eBraille publication typically represents a single intellectual or artistic work, but this specification does not restrict the nature of the content.
- eBraille reading system (or reading system)
-
A system that processes eBraille publications for presentation to a user in a manner conformant with this specification.
- primary entry page
-
The default eBraille content document that users reading an eBraille publication in a browser are expected to encounter. It is located in the publication root and specially named to open by default when users browse to a folder containing an eBraille publication.
The primary entry page is an implementation of the EPUB navigation document [epub3]. It contains the table of contents for the publication.
For more information, refer to 8. Primary entry page
- publication root
- The publication root is the base directory of the eBraille file set. All the resources of an eBraille publication are located at or below this directory.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This section is non-normative.
In package document metadata, reserved prefixes [epub3] are used without declaration.
The following namespace prefixes [xml-names] are also sometimes used without an explicit declaration, but the listed declaration is required for their use to be valid:
| Prefix | Required declaration | Used with |
|---|---|---|
dc:
|
xmlns:dc="https://purl.org/dc/elements/1.1/"
|
Dublin Core elements [dcterms] |
epub:
|
xmlns:epub="https://www.idpf.org/2007/ops"
|
EPUB 3-defined attributes [epub3] |
A conforming eBraille publication:
- MUST be a conforming EPUB publication [epub3], except for the willful violations [infra] documented in this specification.
-
MUST define at least one rendering of its content as follows:
- It MUST contain a package document that conforms to 5. Package Document and meet all publication resource requirements for the package document.
- It MUST contain a primary entry page that conforms to 8. Primary entry page.
- SHOULD conform to the accessibility requirements defined in 10. Accessibility.
- MUST be either an unpackaged eBraille file set or a packaged eBraille file set as defined in
4. eBraille file set. Note
This is a willful violation of EPUB publication conformance [epub3], which requires a publication to be packaged in an EPUB container, to facilitate the deployment of eBraille publications from the web without users having to download a ZIP file.
In addition, all publication resources MUST adhere to the requirements in 3. Publication resources.
The rest of this specification covers specific conformance details.
This section is non-normative.
An eBraille publication is typically composed of many resources — XHTML documents, CSS files, tactile graphics, audio, video, etc.
As an eBraille publication is intended to be easily packaged as a conforming EPUB publication, the requirements for publication resources are inherited from EPUB, specifically as defined in EPUB 3 [epub3].
This section represents a subsetting of the EPUB requirements, as certain features, such as manifest fallbacks, are disallowed in eBraille publications.
To ensure that eBraille reading systems are capable of rendering the content of eBraille publications, only certain widely supported resource types are allowed to be included without
fallbacks. These are called core media types and are designated by their MIME media type [rfc2046]
(e.g., XHTML documents have the MIME media type application/xhtml+xml).
Being designated a core media type does not mean that all reading systems are required to support the type of resource, however. A reading system without audio capabilities will not be able to render audio core media types, for example.
The list of core media types allowed in eBraille publications is the same as those designated for EPUB 3. Some of the key core media types for eBraille include:
application/xhtml+xml— HTML documents that use the XML syntax [html].text/css— CSS Style Sheets [css2].image/jpeg— JPEG Images [jpeg]image/png— PNG Images [png]image/svg+xml— SVG images [svg]
The complete list is available in the core media types section of [epub3].
All other media types are considered foreign resources.
Foreign resources, unlike core media types, have no guarantee of support in reading systems.
To avoid users not being able to access the content of the eBraille publication, foreign resources can only be used if a fallback to a core media type is provided. Fallbacks are provided using intrinsic fallback methods [epub3].
Manifest fallbacks are not supported in eBraille. This means they cannot
be used to include foreign resources in the spine or as a means of
providing fallbacks for foreign image formats (in the latter case, fallbacks can be provided
instead using the [html] img and picture elements' intrinsic fallback
capabilities).
It is generally best to avoid foreign resources unless absolutely necessary. PDF tactile graphics are
an example of a foreign resource that may not be avoidable for some eBraille creators, but using
the [html] object element's intrinsic fallback capabilities can avoid having to duplicate the
image in a core media type format.
eBraille publications MUST NOT use manifest fallbacks [epub3] to provide fallbacks for foreign resources.
The intrinsic fallback methods provided by [html] elements are supported.
Publication resources MUST NOT be located outside the publication root or its descendant directories. In other words, eBraille publications do not support remote resources [epub3].
Like EPUB, eBraille does not support the file: URL scheme [rfc8089] for
referencing resources in an eBraille publication. Accessing files on the user's local file
system presents too great a security risk.
The data: URL scheme may be used to embed resources within eBraille content documents per the restrictions outlined in Data URLs
[epub3].
This section is non-normative.
It is possible to include additional resources in an eBraille publication that are not part of the rendering of the content. EPUB 3 defines resources that are not used in the spine or embedded in xhtml content documents as exempt from the normal core media type resource restrictions [epub3].
This means, for example, that eBraille creators can embed pre-formatted braille in their publication in a format such as PDF or BRF. The resource would still be listed in the manifest, but it would not be flagged as needing a fallback.
It would not be possible to link to these resources from the eBraille publication, but the publication could note the presence of the resources and include instructions on how to access them (e.g., to open the publication with a ZIP tool and navigate to a specific directory).
This section is non-normative.
Reading systems typically do not rely on file extensions for rendering, so, with a couple of notable exceptions for the package document and primary entry page, eBraille does not require specific extensions for the resources in an eBraille publication. The media type declared in the manifest is used as a hint to the nature of each resource, but even that declaration is not reliable. Instead, reading systems typically leave inspection of resources and their rendering to their underlying browser core.
The use of standard file extensions for resources should still be considered a best practice, however, as it avoids authoring confusion over the nature of resources.
Some formats have more than one common extension. For example, XHTML documents can use either the
extension .html or .xhtml and JPEG images can use either .jpg
or .jpeg. In these cases, either extension is acceptable.
This specification uses the .html extension in examples for eBraille content documents as it is more widely used and recognized than .xhtml, particularly for
opening the primary entry page.
The .xhtml extension may be useful if eBraille content documents are opened in a
browser on a local file system (e.g., for testing), as this triggers some browsers to render the
content using the correct XML parser. The extension has no effect on documents served over the
web, however.
The requirements for XML-based media types [rfc2046] defined in XML conformance [epub3] also apply to eBraille publications.
The only difference is that eBraille publications only support UTF-8 [unicode]. UTF-16 MUST NOT be used to encode XML resources.
This section is non-normative.
The eBraille file set is essentially an OCF abstract container [epub3]. EPUB 3 only defines its file set in the abstract because those files are expected to be zipped in the EPUB container [epub3]; the standard is not concerned with the physical files before they are zipped or after they are unzipped. As a ZIP file does not have a true file system within it, the rules for file naming and placement can only be defined virtually.
Unlike EPUB, eBraille allows manifestation of the OCF abstract container both as a physical file set and as a packaged container. This allows an eBraille publication to be independent of packaging, making it a format that can flexibly move between web deployment and end-user distribution.
eBraille defines additional rules on the file structure in order to make it easier to read an
eBraille publication on the web or from a local file system. In particular, it requires the EPUB navigation document [epub3] be in the
root of the file set and named index.html. These requirements do not conflict with
being able to package an eBraille publication as a valid EPUB publication [epub3], however.
The eBraille file set MUST be a conforming OCF abstract container, except for the willful violations [infra] documented in this specification. The root directory [epub3] of the eBraille file set is also known as the publication root.
The eBraille file set MUST contain the following files in the publication root:
- The eBraille package document. This file MUST be named
package.opf - The eBraille primary entry page. This file MUST be named
index.html
There are no restrictions on where the rest of the eBraille publication content goes beyond the
requirement in EPUB 3 that publication
resources are not allowed in a META-INF directory [epub3].
For simplicity of unzipping and accessing a publication on a user's local file system, eBraille creators are encouraged to place the rest of the publication in a subfolder (e.g., named
"ebraille"). This will make the navigation document the first HTML file users
encounter.
To avoid potential naming issues when opening eBraille publications on common operating systems, eBraille file paths and file names have to adhere to the EPUB 3 file naming restrictions specified in File paths and file names [epub3].
This section is non-normative.
Although the publication root establishes a common directory for all files in an eBraille publication, depending on how the eBraille publication is deployed it could allow references to resolve outside of the publication root. For example, if an eBraille publication is deployed on the web, unless it assigned its own domain, a path-absolute-URL string [url] (i.e., a path that begins with a slash) could allow the publication to reach other resources on the server.
For this reason, the eBraille file set must not include file references that use path-absolute-URL strings.
Also, as eBraille does not support remote resources [epub3], as defined in 3.5 Resource location, references to publication resources must not be absolute-url-with-fragment strings [URL].
An eBraille publication MAY contain multiple renditions of the content. The specifics of how this is done are defined in EPUB 3 Multiple-Rendition Publications 1.1 [epub-multi-rend-11].
When including multiple renditions, the default
rendition [epub-multi-rend-11] — the one listed first in the container.xml file
[epub3] — MUST be a braille rendition. The default rendition has a default rendition:accessMode selection
attribute [epub-multi-rend-11] equivalent to the value tactile. No other
value is allowed if the attribute is set explicitly.
Subsequent renditions are exempt from the following requirements:
- The file naming and location requirements for the package document and primary entry page, as this would cause conflicts.
- The recommendation to use only 6- and 8-dot Unicode characters if the rendition is not in braille.
- The publication language requirement to use the
Braiscript designator if the rendition is not in braille.
[epub-multi-rend-11] is only a W3C Working Group Note. The technology is not currently considered stable and should be used with appropriate caution.
The eBraille working group may consider a replacement technology for multiple renditions in a future version if there is significant need for them and implementation of the EPUB technology proves too difficult.
An unpackaged eBraille file set is a multi-file manifestation of the eBraille file set where:
- The publication root is a physical directory.
- The
META-INFdirectory is OPTIONAL.NoteThis is a willful violation of the OCF abstract container file and directory structure [epub3], to simplify the requirements of unpackaged eBraille publications. As the eBraille package document has a predicatable name and location, the
META-INFdirectory can safely be omitted when its only use is to identify that package document in itscontainer.xmlfile.
The OCF mimetype file being specifically designed for OCF ZIP container media type identification,
it does not have to be included in an unpackaged eBraille file set.
A packaged eBraille file set is a single-file manifestation of the eBraille file set that:
- MUST be a conforming OCF ZIP container.
- MUST use the extension
.ebrl.
If an eBraille file is packaged with the extension .epub, it might not be recognized
as an eBraille publication (e.g., if it is also not served with the eBraille media type or that media type is not recognized). In this case, the file would
likely only open as an EPUB publication in an EPUB reading system, resulting in some loss of
braille-specific functionality.
Packaged eBraille publications use the same media type identifier as EPUB in the
mimetype file: application/epub+zip [epub3], as required by OCF ZIP container media type identification
[epub3]
The EPUB media type identifier helps make eBraille files compatible with EPUB reading systems.
The actual media type for eBraille publications is application/ebrl+zip, as defined
in B.1 The application/ebrl+zip media type. This is the media type used, for example, in the Content-Type
header [rfc9110] when serving packaged eBraille publications over the web.
As the use of CSS font properties is not recommended, eBraille creators SHOULD NOT use EPUB's font obfuscation algorithm [epub3] to embed fonts.
This section is non-normative.
eBraille uses the EPUB 3 package document [epub3] to express information about an eBraille publication.
The package document is an XML document that contains three primary sections that encapsulate information about the content and how to render it:
- Metadata — the
metadataelement contains bibliographic and rendering information about an eBraille publication. - Manifest — the
manifestelement contains a list of all the publication resources. - Spine — the
spineelement contains the default ordering of eBraille content documents.
These sections are all contained within the root package
element.
The primary difference of the eBraille package document is only in the metadata that is required and recommended. The eBraille implementation of the package document is also more limited in the features it allows — EPUB 3's manifest fallbacks and legacy elements [epub3] are not allowed, for example.
At the root of the eBraille package document is the package element. This element MUST
conform to the requirements for the package
element in [epub3].
For example, EPUB 3 requires the package element's version attribute [epub3] have the
value "3.0". This identifies that the package document conforms to the EPUB 3
definition. (The identifier that the content conforms to this specification is contained in the
required dc:format element.)
It is also required that the unique-identifier attribute [epub3] be specified. This
attribute references the ID of the dc:identifier element
that contains the unique identifier for the publication.
Although setting the default language of the package document text on the package
element is not required, it is best practice to set it here in an xml:lang attribute [epub3] so that
language information is available for every element that requires it.
Setting the xml:lang attribute on the package element only identifies
the language of the metadata in the package document. This attribute does not set the language
of the content. Refer to 5.3.3.8 Language for more information about identifying the
language of the content.
This section is non-normative.
Metadata about an eBraille publication is expressed in the package document's metadata element [epub3]. This
element is the first child of the root package
element.
The following elements are allowed as children of the metadata element:
- Dublin Core elements
-
Dublin Core defines 15 elements in the
/elements/1.1/namespace [dcterms]. Any of these element can be used in themetadataelement — elements not listed in the required or recommended metadata sections are considered optional elements. - The
metaelement -
The
metaelement [epub3] is used to express properties from metadata vocabularies, where itspropertyattribute [epub3] defines the property name.Metadata properties defined in this element typically require a prefix (many prefixes are reserved and do not have to be declared).
- The
linkelement -
The
linkelement [epub3] is used to associate resources with an eBraille publication, such as metadata records.Linked resources are typically not publication resources so are not listed in the manifest.
Metadata properties defined in this element also typically require a prefix.
For more information about the attributes allowed on these elements, refer to their definitions in [epub3].
EPUB 3 requires that all Dublin Core [dcterms] and meta
elements have child text content
[epub3] (i.e., they have to have at least one non-whitespace character after leading and trailing ASCII
whitespace [infra] is stripped). In the descriptions for these elements, this
specification refers to this content as the element's value.
Whitespace within these element values is not significant. Sequences of one or more whitespace characters are collapsed to a single space [infra] during processing.
The meta element and link element are meant for use with properties defined in existing
metadata vocabularies, such as those in the Dublin Core /terms/ namespace
[dcterms].
EPUB 3 defines a set of reserved prefixes [epub3] for common metadata vocabularies. Properties from these vocabularies can be used without having to declare their prefix.
The prefixes a11y: and dcterms: are reserved prefixes in EPUB
3. They do not have to be declared to use the associated required and recommended
metadata properties in this specification.
If properties from other vocabularies are needed, a prefix needs to be declared before they
can be used. Prefixes are defined in the prefix attribute on the root package element. Both the prefix and a URL to
associate with the prefix have to be specified. These values are separated by
whitespace.
For more information about using prefixes in the package document, refer to Vocabulary association mechanisms [epub3].
The eBraille package document metadata:
- MUST meet all the requirements for EPUB 3 metadata [epub3].
- MUST include all metadata defined in 5.3.3 Required metadata.
- SHOULD include all metadata defined in 5.3.4 Recommended metadata.
- Property name:
-
a11y:brailleCellType - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage
-
Required. Exactly 1.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
6|8|6, 8|8, 6
The a11y:brailleCellType property identifies whether the text of the eBraille publication is encoded using 6- or 8-dot braille characters.
Use the value 6 when the entire content of the eBraille publication is
expressed in 6-dot braille characters and 8 when the content is expressed in
8-dot braille characters.
If both 6- and 8-dot braille characters are used in the same file, use a comma to separate the values, with the one used most often listed first.
- Property name:
-
a11y:brailleSystem - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage
-
Required. One or more.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
Text. SHOULD be a value from the eBraille Braille Codes Registry [code-registry]
The a11y:brailleSystem property identifies the name of the braille system an
eBraille publication has been formatted in conformance with.
If only some contractions are used, specify the code twice — both as contracted and uncontracted. Put whichever code is most common first.
For multiple braille codes, codes should be listed in descending order from most to least utilized within that file.
- Property name:
-
a11y:completeTranscription - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage:
-
REQUIRED. Exactly one.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
true|false
The a11y:completeTranscription identifies whether the original work being
transcribed is fully represented in the braille rendition, minus any minor omissions such as
illustrations without captions or other material that is not ordinarily transcribed.
The value MUST be true if complete and false if not complete.
Completeness is determined by whether the original work being transcribed is fully
represented in the braille rendition, minus any minor omissions such as illustrations
without captions or other material that is not ordinarily transcribed.
- Property name:
-
dcterms:copyrightDate - Namespace:
-
https://purl.org/dc/terms/ - Usage:
-
REQUIRED. Exactly one.
- Content model:
-
MUST be an [iso8601-1] conformant date of the form
YYYY-MM-DD,YYYY-MM, orYYYY
The dcterms:dateCopyrighted property [dcterms] identifies the copyright date
of the work being transcribed.
- Element name:
-
dc:creator - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED. One or more.
- Content model:
-
Text. Follow regional conventions for name layout.
- Attributes:
The dc:creator element [dcterms] identifies the name(s) of the primary author,
editor, etc.
To identify the role the creator played in the creation of the content, associate a role property [epub3] with the element.
To provide the creator's name for sorting purposes, associate a file-as property [epub3] with the element.
For more information, refer to the definition of
the dc:creator element in [epub3].
- Element name:
-
dc:format - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED child of the
metadataelement. Exactly one. - Content model:
-
MUST contain both the case-sensitive name "eBraille" and the version number.
For this version of the specification, the value is "
eBraille 1.0". - Attributes:
The dc:format element [dcterms] identifies version of the eBraille standard an
publication conforms to.
- Element name:
-
dc:identifier - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED child of the
metadataelement. One or more. - Content model:
-
Text.
eBraille creators are advised to use absolute-URL strings [url] for identifiers whenever possible. The inclusion of a domain owned by the eBraille creator can improve the uniqueness of the identifier, for example, while the use of a URN with a namespace identifier [rfc8141] improves processing by reading systems.
- Attributes:
-
-
id[conditionally required]
-
The dc:identifier element [epub3] contains an identifier for an eBraille publication, such as a UUID, DOI, or ISBN.
eBraille creators have to specify one identifier as the unique identifier for the publication
using the package element's unique-identifier
attribute [epub3]. This attribute references the id attribute [epub3] of the dc:identifier
containing the unique identifier.
The dc:identifier element is not used to identify the source work being
transcribed. Use the dc:source element for the
source work's identifier(s).
For more information, refer to the definition
of the dc:identifier element in [epub3].
- Element name:
-
dc:language - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED child of the
metadataelement. One or more. - Content model:
-
MUST be a well-formed language tag [bcp47] that includes the script subtag
Braito indicate the text is encoded in braille. - Attributes:
-
id[optional]
The dc:language element [epub3]
identifies the language(s) of the eBraille publication.
When specified, a region subtag indicates a specific variant of the language of the work.
The country codes in the region subtag do not identify the braille code the transcription
follows. Refer to the a11y:brailleSystem
property for more information.
If multiple languages are used, add a separate dc:language tag for each one. The
first language listed in document order is the primary language of the publication.
Setting the language in the package document metadata is not a replacement for setting
the language of each eBraille content document. The xml:lang attribute
in a content document defines the language and encoding of its content. For more
information, refer to the definition of the
dc:language element in [epub3].
- Name:
-
dcterms:modified - Namespace:
-
https://purl.org/dc/terms/ - Usage
-
Required. Exactly 1.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
An [xmlschema-2] dateTime conformant date of the form:
YYYY-MM-DDThh:mm:ssZ, where YYYY represents the year, MM the month, DD the day, T is a separator indicating the start of the time section, hh the hour, mm the minutes, ss the seconds, and Z represents the UTC time zone designator
The dcterms:modified property identifies the date, in Coordinated Universal Time
(UTC), on which an eBraille publication was last modified.
For more information, refer to the definition of the last modified date [epub3].
- Name:
-
a11y:producer - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage:
-
REQUIRED. One or more.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
- Text
The a11y:producer property identifies the name(s) of the organization(s) or
individual(s) that produced the braille publication. Repeat the property for each
organization or individual.
The a11y:producer and dc:publisher MAY identify the same
organization or individual, but they do not have to. The producer is responsible for
creating an eBraille publication, while the publisher may have only commissioned the work
from a producer.
- Element name:
-
dc:date - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED child of the
metadataelement. Exactly one. - Content model:
-
Text. [epub3] recommends that the date string conform to [iso8601], particularly the subset expressed in W3C Date and Time Formats [datetime]
- Attributes:
The dc:date element [dcterms] defines the publication date of the eBraille publication.
The publication date is not the same as the last modification date, which is the last time the publication was changed.
The publication date expressed in the dc:date is also not the same as the
date of publication of the source work being transcribed. Refer to 5.3.4.5 Source for more information on how to set the publication date of a source work.
- Property name:
-
a11y:tactileGraphics - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage:
-
REQUIRED. Exactly one.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
- If no tactile graphics are included, the value MUST be
none. - Otherwise, the value MUST be a comma-separated list containing one or more of
the values:
JPG,PNG,SVG, andPDF. Formats are listed from most used to least used.
- If no tactile graphics are included, the value MUST be
The a11y:tactileGraphics property identifies whether an eBraille publication
contains tactile graphics.
- Element name:
-
dc:title - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
REQUIRED child of the
metadataelement. One or more. - Content model:
-
Text
- Attributes:
The dc:title element [dcterms] identifies the title of the source
material.
The first dc:title element in document order identifies the primary title of the
eBraille publication. Subsequent dc:title elements may be ignored by
reading systems, so consider merging titles into a single tag if it is important that users
have access to the complete set of titles.
For more information, refer to the definition of
the dc:title element in [epub3].
- Element name:
-
dc:description - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text
- Attributes:
The dc:description element provides an abstract, a table of contents, or a
free-text account of the resource.
- Property name:
-
dcterms:educationLevel - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text
The dcterms:educationLevel property identifies the level of education an
eBraille publication is targeted to (e.g., the grade level). Repeat the element if the
publication is intended for more than one education level.
- Element name:
-
dc:publisher - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text
- Attributes:
The dc:publisher element identifies the name(s) of the organization(s) or
individual(s) that published the eBraille publication. Repeat the property for each
organization or individual.
- Element name:
-
dc:rights - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text
- Attributes:
The dc:rights element provides rights information about an eBraille publication. The rights statement includes various property rights associated with the
resource, including intellectual property rights. Repeat the element to include more than
one rights statement.
- Element name:
-
dc:source - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text, but the value SHOULD be formatted as a Uniform Resource Name
- Attributes:
When an eBraille publication is a transcription of another work, that source is
identified in a dc:source element.
The value of the element SHOULD uniquely identify the source. An ISBN, DOI, ISSN or similar identifier from a controlled system is preferred.
It is also RECOMMENDED to specify the publisher of the source work. Use a
dcterms:publisher property with a refines attribute that
references the dc:source element.
If not transcribing a published print work, the name of the organization or individual that produced the original text MAY be used as the publisher.
It is also RECOMMENDED to specify the date of publication of the source work. Use a
dcterms:date property [dcterms] with a refines attribute
that references the dc:source element.
It is RECOMMENDED that the date string in the dcterms:date property conform to
[iso8601], particularly the subset expressed in W3C Date and Time Formats
[datetime].
- Element name:
-
dc:subject - Namespace:
-
https://purl.org/dc/elements/1.1/ - Usage:
-
RECOMMENDED child of the
metadataelement. Zero or more. - Content model:
-
Text
- Attributes:
The dc:subject element [dcterms] identifies the subject of an eBraille publication. Repeat the element for each subject.
The value SHOULD be a human-readable heading or label, but a code value MAY be used if the subject taxonomy does not provide a separate descriptive label.
The system or scheme the element's value was drawn from MAY be identified using the authority property [epub3]. A subject
code MUST also be specified when specifying the authority property.
For more information, refer to the definition of
the dc:subject element in [epub3]
The package document metadata section MAY include any other Dublin Core elements [epub3] not listed as required or recommended.
Metadata from vocabularies with a reserved prefix MAY also be added, including metadata properties in the Accessible Formats Metadata Vocabulary that are not listed as required or recommended in the preceding sections.
Properties from other vocabularies are also allowed provided a prefix [epub3] is defined.
The package document manifest element
[epub3] contains a list of all of the resources in the eBraille publication. It is the second
required child of the root package element.
Each item element [epub3] child of the
manifest defines one resource, minimally providing the following information:
- an identifier for the resource in its
idattribute [epub3]; - the location of the resource in its
hrefattribute [epub3]; and - the media type of the resource in its
media-typeattribute [epub3].
Manifest entries may also identify specific properties of the resource in the properties attribute. For
eBraille, this attribute will typically only be used for the navigation
document and when SVG tactile graphics are embedded in the resource.
The manifest entries for eBraille content documents may also indicate if a media overlay document is available in the media-overlay attribute [epub3].
For the complete set of requirements for the manifest, refer to the The manifest element in [epub3].
As eBraille does not support manifest fallbacks, the
fallback attribute is not supported.
The package document spine element [epub3] is
the third required child of the root package element. It
defines the default reading order for an eBraille publication.
Each itemref child of the spine references the manifest entry for an
eBraille content document in its required idref attribute [epub3].
The linear attribute [epub3] is used
to indicate if the resource referenced contains content that must be read sequentially or not.
Linear content typically consists of eBraille content documents that contain content in the primary
reading order while non-linear content contains supplementary material such as notes and
descriptions that can be accessed out of sequence (e.g., an eBraille reading system might opt to
not render them until after all the linear content has been read). If the linear
attribute is not specified, the spine item defaults to being linear content (i.e., the attribute is
only required to specify non-linear content).
For the complete set of requirements for the spine, refer to the The spine element in [epub3].
In addition to the restrictions already enumerated, eBraille publications MUST NOT include any of the following in the package document:
- all features marked as deprecated [epub3]
- collections [epub3]
- legacy features [epub3]
This section is non-normative.
eBraille content documents define the markup and presentation of the content of an eBraille publication. An eBraille content document is encoded using the XML syntax of [html], also commonly known as XHTML, and is styled using CSS [css2].
eBraille content documents are not limited to formatted text. For example, they may include tactile graphics, audio, and video. The primary difference between the features of an eBraille content document and a typical web page is that scripting and forms are not supported.
Note that unlike EPUB 3, eBraille only supports XHTML in the spine [epub3] of an eBraille publication. SVG images are not supported in the spine [epub3] but can be embedded in XHTML documents.
An eBraille content document MUST be an XHTML content document as defined [epub3] with additional constraints as defined in the following subsections.
eBraille content documents are expected to provide their text content in 6- or 8-dot braille characters. eBraille is not meant as a delivery format for ASCII braille or similar mappings to braille cells.
For this reason, the text content of eBraille content documents SHOULD consist only of the following [unicode] characters:
- Braille Patterns (U+2800 … U+28FF) ;
- Whitespace [xml]:
- TAB (U+0009)
- LF (U+000A)
- CR (U+000D)
- SPACE (U+0020)
- NO-BREAK SPACE (U+00A0)
- SOFT HYPHEN (U+00AD)
This restriction only applies to the renderable text of an XHTML document as well as the attributes that could be rendered depending on the display capabilities of a device or user configuration settings, for example:
- the
altattribute [html] for images and image maps that cannot be displayed; - the
abbrattribute [html] for alternative table headings; - the
titleattribute [html] for expansions of abbreviations.
The restriction also applies to CSS styling that would generate non-braille characters (e.g.,
list styling for numbers, letters, and glyphs, and the use of the content property
to dynamically add text before or after elements). Reading systems are not expected to convert
such styling to braille characters.
This restriction does not prevent the use of CSS to insert braille characters.
The restriction does not apply to attributes that carry meta information (e.g., the
class and href attributes [html], as well as the title
attribute in the page list).
For some technologies that can be embedded in eBraille content documents, such as [mathml], it will not be possible to restrict the text to braille characters.
When authoring [html] ordered (ol) and unordered (ul) lists, eBraille creators
SHOULD embed the list number, letter, or glyph within each item (e.g., by setting
list-style-type to none to override the default styling). Do not
rely on eBraille reading systems to convert the automatic styling of lists to braille
characters.
eBraille creators SHOULD only use CSS for marking list items when the style sheet supplies the
braille characters to display (e.g., by setting list-style-type: '⠸⠲ ' to insert
braille bullets).
eBraille does not support scripted interactivity or form submissions. Consequently, eBraille creators MUST NOT include [html] script elements or the form element's
action attribute in eBraille content documents.
The lack of support for scripting means that html elements that depend on scripting (e.g.,
the canvas element and custom elements) will not
work in eBraille publications. It is strongly recommended not to include these elements,
as well.
An exemption is made to the scripting requirement for the primary entry page so long as it is not listed in the spine. The exemption is to allow publishers to add a user interface for web deployment.
This section is non-normative.
eBraille creators may use CSS [css2] to style and lay out eBraille content documents. With the few exceptions defined in this section, eBraille defers to [epub3], and more specifically to the CSS standardization work done in W3C, to define CSS.
Keep in mind that some eBraille reading systems will not support all desired features of CSS. The following are identified as potentially problematic, depending on the technology choices of reading system implementations, and should therefore be used with caution:
- The "CSS Paged Media Module Level 3" working draft [css-page], which builds on the "Paged media" section of [css2], is not well supported in web browsers.
Note that the presentation of content is not determined by author style sheets only. Reading systems are expected to apply default styles that make sense for the current locale, in case author styles are missing or incomplete. This may be done through CSS or through other means. Reading systems may also perform specific styling according to user preferences.
The requirements for using CSS to style eBraille content documents are defined in CSS requirements [epub3] but with the following differences:
- eBraille creators MUST NOT use
-epub-prefixed properties [epub3]. - CSS style sheets MUST be UTF-8 encoded [unicode].
In addition, eBraille creators:
-
SHOULD NOT use properties that affect the text's font (e.g., which font gets applied, its size, whether it is bold, italic, etc.). Creators should assume that reading systems determine the shape and size of the braille symbols (e.g., for technical reasons, or to ensure a good reading experience).
The font-related properties include, but are not limited to:
-
SHOULD use font-relative lengths [css-values] only. Because it should be assumed that creators have no control over the font used by the reading device, using absolute lengths is regarded as unreliable. Using font-relative lengths in style sheets is also needed in order to reliably use relative widths and heights in media queries.
More specific guidance on how to use CSS properties in eBraille content documents is provided in the eBraille Styling Best Practices.
eBraille allows the use of media queries [mediaqueries] to support styling and content that is conditional on the type and characteristics of the device.
The following restrictions and recommendations apply to CSS (e.g. @media [css-conditional] and @import [css-cascade] rules),
as well as where media queries are used as a microsyntax in [html]
(such as in the link and style elements), and in xml-stylesheet processing instructions
[xml-stylesheet]:
-
eBraille creators SHOULD NOT use media queries that discriminate between a braille display and a screen. Specifically,
- media queries MUST NOT include the deprecated
braillemedia type [mediaqueries] to target braille displays. - Media queries SHOULD NOT include references to the
gridfeature [mediaqueries] to detect braille displays, either. - Media queries SHOULD also NOT include the
screenmedia type [mediaqueries] to target braille displays.
NoteThe primary motivation for these restrictions is making the rendering of an eBraille publication on a computer screen representative for the rendering on a comparable braille display. The recommendation against the use of
brailleand(grid)is also driven by the fact that there are currently no known CSS implementations that match these types, so requiring eBraille reading systems to match them could be problematic.The recommendation against the use of
screenwas included to be forward-compatible with a possible future version of the standard that supports differences in styling for screens versus braille displays. Currently, eBraille reading systems are prompted to matchscreen. - media queries MUST NOT include the deprecated
- Media queries SHOULD use font-relative lengths [css-values] to adapt the styling based on the dimensions of the viewport.
More specific guidance on how to use media queries in eBraille content documents is provided in the eBraille Styling Best Practices.
This section is non-normative.
As this is a technical specification for the eBraille format, its focus is on the technologies for creating eBraille content documents. It does not specify a specific manner in which the content must be created, as regional differences in braille codes will influence how any given publication is formatted.
A goal of the eBraille format, however, is, as much as possible, to promote common markup practices across regions so that organizations and individuals can interchange files without needing to completely reformat them. Using common markup practices will allow eBraille reading systems to apply regional CSS rules, improving the readability for users expecting different braille formatting conventions.
To this end, eBraille content documents rely primarily on the [html] class and role
attributes to identify formatting requirements. Augmenting core HTML elements with a common set of
classes and roles will make eBraille publications more predictable for reformatting.
The eBraille working group is working on a set of best practices to help facilitate this model. These include:
- eBraille Tagging Best Practices — This document defines the core HTML elements and attributes to structure braille content.
- eBraille Styling Best Practices — This document defines CSS styling conventions to use to render braille content.
eBraille does not support fixed layouts as defined in [epub3]. Consequently, eBraille publications:
- MUST NOT specify the
rendition:layoutproperty with the valuepre-paginatedin the package document metadata or specify its override propertyrendition:layout-pre-paginatedon spine items [epub3]. - MUST NOT specify any other properties or spine overrides defined in Fixed-layout package settings [epub3].
This section is non-normative.
To make it easier to deploy eBraille publications on the web, the EPUB navigation document [epub3] is used as
the primary entry point for publications. The required file naming (index.html) and
location of this file mean it will be the first document loaded when users browse to a folder
containing an eBraille publication.
By requiring the primary entry page be located in the publication root, it is also easier for users to unzip an eBraille publication and read it locally, if they so choose. If all the other resources in the publication are placed in a subfolder, for example, the primary entry page will be the first HTML document users encounter in the unzipped folder.
The primary entry page does not have to be the first document in the spine, however. As the page is meant as an entryway for web reading, it may not be helpful to include it in the spine at all. Reading systems will still be able to extract the table of contents and other information from the document even if it is not in the spine.
The primary entry page MUST be a conforming EPUB navigation document
[epub3]. In addition, it MUST be named index.html and be located in the publication root, as defined in 4.2 File and directory structure.
The primary entry page MUST include an [html] link element with its rel attribute set
to the value publication. The href attribute MUST specify the package document
and the type attribute MUST contain the media type of the package document
(application/oebps-package+xml).
Although it is possible to discover the package document by its required name and location, this requirement ensures that eBraille reading systems can programmatically determine that the primary entry page belongs to an eBraille publication (i.e., to avoid having to check for a package document for any web page a user might try to open).
The primary entry page MAY include [html] script elements only if the document is not included
in the spine. This exception is to allow publishers to include a user interface to better enable
reading of their publication in browsers. It is not meant for general scripting of the content.
A scripted primary entry page is not allowed in the spine as an extra measure to ensure that the scripting does not interfere with rendering in eBraille reading systems. Reading systems are expected to disable the scripting in the primary entry page regardless of the document's placement in the spine.
As the primary entry page is meant to help browser users navigate the publication, it SHOULD NOT be included in the spine. If the publication needs a table of contents in the spine, it is better to create a separate document with publication-specific formatting.
As per the requirements of EPUB 3, the manifest entry for the primary entry
page has to have a properties attribute with the value nav [epub3].
The table of contents provides users access to the major sections of the publications.
The EPUB 3 specification requires a table of contents. It is defined in an [html] nav
element whose epub:type attribute specifies
the value "toc" [epub3].
For compatibility with web-based rendering, the table of contents MUST also be identified by the
role attribute [html] value "doc-toc"
[dpub-aria].
The table of contents is defined by a single [html] ordered list (ol) in the root of the
nav element. Each [html] list item (li) represents one of the top-level
sections of the publication. If the section can be linked to, wrap its heading inside an
[html] anchor tag (a), otherwise wrap the heading in a span element (unlinked headings
are not common outside of publications that omit content).
If a section contains additional subsections, list those headings in an ol element
after the link to the heading.
The minimalist rules on the structure of the table of contents are to ensure that eBraille reading systems can reliably process the information and present it to users in a specialized interface. The table of contents is not normally included in the spine for reading; it is typically only presented directly to users if they load the primary entry page in a browser.
For more information, refer to The toc nav
element in [epub3].
The page list provides users to access to static page break locations in an eBraille publication. These static page breaks typically correspond to the page breaks in the source publication, whether it is a print book, a PDF, an embossed braille work, or any other format with static page breaks. Publishers may, however, opt to provide their own static page break locations if the eBraille publication is not transcribed from another work.
Providing a page list is optional per the EPUB 3 specification. When specified, the page list is
defined in an [html] nav element whose epub:type attribute specifies the value "page-list" [epub3].
For compatibility with web-based rendering, the page list MUST also be identified by the
role attribute [html] value "doc-pagelist" [dpub-aria]
The page list is defined by a single [html] ordered list (ol) in the root of the
nav element. Each [html] list item (li) represents one static page break
in the publication, with the page number wrapped inside an [html] anchor tag (a) that
links to its location.
Each entry in the page list MUST include the print page number equivalent in a title
attribute [html]. Providing both encodings allows reading systems to match the page number
regardless of whether the device accepts braille input or not and avoids mistranslation of the
page numbers if only one encoding is provided.
Only include the page number in the a tag. Adding words such as "page" may break the
ability of users to jump to the page break (i.e., eBraille reading systems will typically
try to find an exact match for the page number a user enters).
Unlike the table of contents, the page list cannot include nested lists. It is not possible to group pages together by the section they belong to, for example.
For more information, refer to The page-list
nav element in [epub3].
Landmarks identify key structures of an eBraille publication that users may want a quick way to access. Landmarks are not a repetition of the table of contents, but a more select list of locations that users may want to refer to while reading.
The most common landmark in EPUB 3, for example, is the location where the body matter begins. Providing this location allows reading systems to skip the front matter and load the first page when users open a publication. Other key landmarks include glossaries and indexes, as users often need to access these reference sections for more information while reading.
Providing a landmarks navigation is optional per the EPUB 3 specification. When specified, the
landmarks are defined in an [html] nav element whose epub:type attribute specifies the value "landmarks" [epub3].
Due to the conflicting naming with ARIA landmarks [wai-aria-1.2], the DPUB-ARIA vocabulary [dpub-aria] does not include a role for a landmarks navigation element.
Landmarks are defined by a single [html] ordered list (ol) in the root of the
nav element. Each [html] list item (li) represents one landmark in the
publication.
The name of the landmark is wrapped inside an [html] anchor tag (a) that provides a
machine-readable semantic that identifies the type of landmark in its epub:type
attribute. These semantics are drawn from the EPUB
Structural Semantics Vocabulary [epub-ssv].
For more information, refer to The landmarks
nav element in [epub3].
eBraille publications support media overlays as defined in [epub3]. Media overlays allow prerecorded audio to be synchronized with the content of eBraille content documents, allowing users to switch between reading braille, listening to auditory playback, or reading along with narration.
A media overlay document MAY be associated with an eBraille content document by adding a
media-overlays attribute to its package document manifest
entry.
The body of a media overlay document consists of par and seq elements
[epub3]. The par element defines the audio content to associate with the specified
content, while seq elements are used to group par and other seq
elements into logical structures such as figures and tables.
Although it is possible to associate styling information [epub3] with the audio playback, eBraille reading systems are not expected to use this information. It would only be used if the eBraille publication were visually rendered, such as if the publication were opened in a mainstream EPUB 3 reading system.
For more information about creating media overlay documents, refer to the Media overlays section of [epub3].
eBraille publications fall under the category of optimized publications as defined by the EPUB Accessibility specification [epub-a11y]. eBraille publications are only meant for braille users, so it is not expected that eBraille creators can produce them to fully meet the requirements of W3C's Web Content Accessibility Guidelines [wcag22]. There is not always a benefit to braille users in meeting all of that standard's requirements.
At the same time, it is possible to create eBraille publications that fail to meet the needs of users if care is not taken to optimize the content. Not properly identifying headings, for example, will limit users' ability to navigate a publication quickly. Similarly, failing to mark up tables properly can make them difficult to navigate and understand.
So although fully meeting WCAG conformance may not be possible, eBraille SHOULD meet all success criteria applicable to eBraille reading and include all relevant accessibility metadata [epub-a11y] in the package document.
This section is non-normative.
Although eBraille shares a common file set with EPUB 3, many of the privacy and security threats [epub3] that arise with EPUB 3 publications do not apply to eBraille publications. The reason is that the primary threat vectors in EPUB 3 come from its allowance of scripting and network access. Users do not face the same risks from third party scripts, from attempts by publishers to monitor their activities or profile them through scripting, or from malicious code being brought in by remote resource calls, among other threats outlined in EPUB 3.
It does not mean that there are no security or privacy risks with eBraille publications. eBraille creators still need to ensure they maintain the security and privacy rights of users when creating their publications. The possible areas of concern for eBraille publications include:
- Linking to external resources
-
Linking out to resources on the web can expose users to potential malicious content. Broken-link hijacking is one example where a malicious actor may buy the expired domain of a site and redirect users to content the eBraille creator never intended. Links to a publishers web site could allow them to profile users if they include tracking information.
- Including malicious content
-
Although eBraille does not allow eBraille creators to embed remote resources in publications, using third-party resources, such as tactile graphics, can expose users to exploits.
- Falsified publication information
-
Malicious actors could include false metadata — such as the title, author, and publisher — in an eBraille publication to trick unsuspecting users into believing they are reading material from a trustworthy source. This could, for example, lead users to be more trusting of external links than they otherwise would be.
The following recommendations from EPUB 3 [epub3] apply equally to eBraille publications:
- Avoid links to untrustworthy web sites (e.g., that browsers do not recognize as safe).
- Use secure connections to external sites and resources (i.e., using the HTTPS protocol).
- Avoid embedding content not provided by reputable organizations or individuals.
When an eBraille publication is distributed to end users as a single file, it MUST be packaged as a conforming packaged eBraille file set.
When making an eBraille publication available for reading over the web, eBraille creators MUST ensure that resources are served with the correct MIME media type [rfc2046] in their Content-Type headers [rfc9110]. File extensions cannot be relied on, as XHTML documents, for example, are only properly processed as XML when the correct media type is set.
eBraille creators MUST also ensure that each directory containing an eBraille publication is
configured to serve the primary entry page (index.html) by
default for users that access the publications from a web browser.
This section is non-normative.
As an eBraille publication represents a subset of an EPUB 3 publication [epub3], an eBraille reading system similarly consists of a subset of features of a full EPUB 3 reading system [epub-rs-3].
Similar to EPUB 3, eBraille does not define a uniform set of requirements that all reading systems must meet. Support is instead based on the capabilities of the device. A reading system might not support media overlays, for example, if it does not support audio playback.
As eBraille publications can be deployed unpackaged on the web, users may not even require a dedicated eBraille reading system to read them. A very basic reading experience will be possible directly from a standard web browser, while browser-based reading systems could provide a richer reading experience for reading on the web.
An eBraille reading system MUST meet the requirements for EPUB reading systems [epub-rs-3], with the following differences:
- It MUST NOT support remote resources [epub-rs-3].
- It MUST NOT resolve path-absolute-URL strings [url].
- As remote resources, forms, and scripting are not supported, it MUST NOT allow eBraille publications to have network access [epub-rs-3]. (Note that barring network access should not prevent users from following external hyperlinks [epub-rs-3] in a publication.)
- It MUST only support eBraille content documents in the
spine. The reading system MAY reject eBraille publications with other formats in the spine or ignore their entries when rendering the publication. - It MUST NOT support form submission [epub-rs-3].
- It MUST NOT support scripting [epub-rs-3].
- It is only required to support OCF processing [epub3] if it supports packaged eBraille publications.
The following EPUB reading system features [epub-rs-3] are not supported in the authoring of eBraille publications. Unlike the features restricted in 13.2.1 General, the existence of these features will not affect the rendering of eBraille publications and does not affect their privacy or security. Reading systems built on EPUB rendering engines MAY support these features although they SHOULD be disabled, if possible, to discourage use by eBraille creators:
- manifest fallbacks.
- SVG content documents. (Note that this does not affect embedded SVG.)
- EPUB 3's prefixed CSS properties.
- fixed layouts.
- backward compatibility or forward compatibility with other EPUB versions.
eBraille reading systems not built on EPUB rendering engines MUST NOT add support for these features.
An eBraille reading system MUST support at least one of packaged eBraille publications or web-hosted eBraille publications, but SHOULD support both deployment methods.
For packaged eBraille publications, reading systems:
- SHOULD NOT fail to open a publication solely because the
mimetypeis missing or not encoded or stored as required. - are not required to assign a unique URL [epub-rs-3] to publications because scripting is not supported. It is still RECOMMENDED to domain isolate publications in case scripting is introduced in a future version, however.
If an eBraille reading system supports web access, it SHOULD allow users to download unpackaged eBraille publications hosted on the web by specifying the path to the package document.
In addition to the general requirements for CSS support in [epub-rs-3], Reading devices MUST
guarantee that 1ch corresponds with the cell-to-cell distance (i.e., the distance
from center to center of corresponding dots in adjacent cells), while 1em should
correspond with the line-to-line distance (i.e., the distance from center to center of
corresponding dots from one line to the next).
As the use of CSS font properties is not recommended, reading system support for font obfuscation is OPTIONAL.
eBraille reading systems of type braille display SHOULD match screen, and SHOULD match both
(grid) and not (grid) [mediaqueries].
eBraille reading systems MUST support PDF for tactile graphics in addition to the core media types requirements in [epub-rs-3]. If an eBraille reading system is not capable of rendering PDFs embedded in eBraille content documents, it MUST provide a mechanism that allows the user to open the graphics in an application that supports PDF rendering.
eBraille publications made available over the web in unpackaged form are expected to provide minimal functionality in web browsers without the need for a dedicated eBraille reading system.
If a browser-based reading system is created for reading unpackaged eBraille publications (e.g., through a web app), it SHOULD provide the same functionality as a dedicated eBraille reading system.
Browser-based reading systems will be inherently less secure than dedicated eBraille reading systems, as it will not likely be possible to disable features such as scripting, forms, and remote resource access. Consequently, a browser-based reading system SHOULD follow all the recommendations for securing publications defined in [epub-rs-3].
This appendix defines metadata properties for describing accessible formats, but with specific focus on the needs of eBraille publications.
It extends the EPUB Accessibility Vocabulary
namespace [epub-a11y] so that the properties can be used in the package document using the reserved prefix a11y.
The required and recommended properties are formally defined in the body of this specification, but as the document does not list all the possible optional properties an eBraille creator can use, an additional set of optional properties are included in this appendix.
Properties are only added to this vocabulary if suitable equivalents are not already defined in existing vocabularies such as Dublin Core and Schema.org.
The working group does not anticipate submitting the properties to the EPUB Accessibility Vocabulary at this time, but a formal submission could occur in the future if there is a need to standardize their use beyond eBraille.
This specification extends the EPUB Accessibility Vocabulary namespace [epub-a11y] to include the following properties:
- brailleCellType
- brailleSystem
- completeTranscription
- producer
- tactileGraphics
- minimumCells
- minimumLines
These properties MUST be declared using the a11y: prefix.
The EPUB Accessibility standard [epub-a11y] reserves the prefix "a11y:" for use
with properties in the https://idpf.org/epub/vocab/package/a11y/# namespace.
eBraille creators do not have to declare the prefix in the package document.
This section defines additional properties that eBraille creators can use in eBraille publications that are not required or recommended metadata.
- Name:
-
a11y:minimumCells - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage:
-
Optional. Zero or one.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
Positive integer
The a11y:minimumCells property identifies the minimum number of cells per line
required to accurately display the material within the transcription.
For example, if a single graphic in the file requires at least 10 cells of space, the minimum for this file would be 10 cells.
Reading systems should attempt to display the content regardless of the value of this property.
- Name:
-
a11y:minimumLines - Namespace:
-
https://idpf.org/epub/vocab/package/a11y/# - Usage:
-
Optional. Zero or one.
Expressed in the
propertyattribute [epub3] of ametatag. - Allowed value(s):
-
Positive integer
The a11y:minimumLines property identifies the minimum number of lines per page
required to accurately display the material within the transcription.
For single- and multi-line braille displays, the concept of a page refers to the total number of lines that the hardware can accommodate without refreshing.
This appendix registers the media type application/ebrl+zip for the eBraille
implementation of the EPUB Open Container Format (OCF).
The OCF ZIP container file is based on the zip archive format (see https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT). It is used to encapsulate an eBraille publication.
- MIME media type name:
-
application - MIME subtype name:
-
ebrl+zip - Required parameters:
-
None.
- Optional parameters:
-
None.
- Encoding considerations:
-
OCF ZIP container files are binary files encoded in the
application/zipmedia type. - Security considerations:
-
All processors that read OCF ZIP container files should rigorously check the size and validity of data retrieved.
In addition, because of the various content types that can be embedded in OCF ZIP container files,
application/ebrl+zipmay describe content that poses security implications beyond those noted here. However, only in cases where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. In such cases, matters of security would fall outside the domain of this registration document.Security considerations that apply to
application/zipalso apply to OCF ZIP container files. - Interoperability considerations:
-
None.
- Published specification:
-
This media type registration is for the eBraille implementation of the EPUB Open Container Format (OCF), as described by the eBraille specification located at
https://www.daisy.org/s/eBraille. - Applications that use this media type:
-
This media type is in use for the distribution of braille documents in the eBraille format.
- Additional information:
-
- Magic number(s):
-
0:
PK 0x03 0x04 - File extension(s):
-
eBraille container files are identified with the extension
.ebrl. - Macintosh file type code(s):
-
ZIP
- Person & email address to contact for further information:
-
eBraille Working Group (ebraille@daisylists.org)
- Intended usage:
-
COMMON
- Author/change controller:
-
DAISY Consortium
This section is non-normative.
-
dc:title§5.3.3.13 - eBraille content document §1.5
- eBraille creator §1.5
- eBraille file set §1.5
- eBraille publication §1.5
- eBraille reading system §1.5
- packaged eBraille file set §4.7
- primary entry page §1.5
- publication root §1.5
- unpackaged eBraille file set §4.6
- value §5.3.1.2
-
[CSS-CASCADE] defines the following:
- @import
-
[CSS-COLOR] defines the following:
- color
-
[CSS-CONDITIONAL] defines the following:
- @media
-
[CSS-FONTS] defines the following:
- font-family
- font-size
- font-style
- font-variant
- font-weight
-
[CSS-PAGE] defines the following:
- CSS Paged Media Module Level 3
-
[CSS-TEXT-DECOR] defines the following:
- text-decoration
- text-shadow
- text-underline-position
-
[CSS-VALUES] defines the following:
- font-relative lengths
-
[CSS2] defines the following:
- Paged media
-
[DPUB-ARIA] defines the following:
- doc-pagelist
- doc-toc
-
[EPUB] defines the following:
- dir
- id
- property attribute
- xml:lang
-
[EPUB-A11Y] defines the following:
- accessibility metadata
- EPUB Accessibility specification
- optimized publications
-
[EPUB-MULTI-REND-11] defines the following:
- default rendition
- rendition:accessMode selection attribute
-
[EPUB-RS-3] defines the following:
- assign a unique URL
- backward compatibility
- embedded SVG
- EPUB 3 reading system
- external hyperlinks
- fixed layouts
- font obfuscation
- form submission
- forward compatibility
- manifest fallbacks
- network access
- OCF processing
- recommendations for securing publications
- remote resources
- scripting
- SVG content documents
-
[EPUB3] defines the following:
- -epub- prefixed properties
- any other Dublin Core elements
- associate
- associate styling information
- authority property
- child text content
- collections
- container.xml file
- core media type resource
- core media types section
- CSS requirements
- Data URLs
- dc:language element
- definition of the dc:creator element
- definition of the dc:identifier element
- definition of the dc:subject element
- deprecated
- EPUB 3
- EPUB 3 metadata
- EPUB 3 publication
- EPUB 3's prefixed CSS properties
- EPUB container
- EPUB navigation document
- EPUB navigation document
- EPUB publication
- EPUB publication conformance
- EPUB reading systems
- epub:type attribute
- File paths and file names
- file-as property
- fixed layouts
- Fixed-layout package settings
- font obfuscation algorithm
- foreign resources
- href attribute
- id attribute
- intrinsic fallback methods
- item element
- legacy elements
- linear attribute
- link element
- manifest
- manifest element
- manifest fallbacks
- media overlays
- media-overlay attribute
- media-type attribute
- meta element
- metadata element
- OCF abstract container
- OCF ZIP container
- OCF ZIP container media type identification
- package document
- page-list
- par
- prefix
- privacy and security threats
- properties attribute
- recommendations from EPUB 3
- remote resources
- rendition:layout property
- requirements for the package element
- reserved prefixes
- reserved prefixes
- role property
- root directory
- seq
- spine
- spine element
- The landmarks nav element
- The manifest element
- The spine element
- toc
- underlying technologies
- unique-identifier attribute
- version attribute
- Vocabulary association mechanisms
- XHTML content document
- xhtml content documents
- XML conformance
- xml:lang attribute
-
[HTML] defines the following:
-
aelement -
abbrattribute (forthelement) -
actionattribute (forformelement) -
altattribute (forimgelement) -
canvaselement -
classattribute (forglobalelement) - custom elements
-
formelement -
hrefattribute (foraelement) -
hrefattribute (forlinkelement) -
imgelement -
lielement - link
-
linkelement - media queries are used as a microsyntax in
-
navelement -
objecttype -
olelement -
pictureelement -
relattribute (forlinkelement) -
roleattribute -
scriptelement -
spanelement - style
-
titleattribute (forabbrelement) -
titleattribute (forhtml-globalelement) -
titleelement -
typeattribute (forlinkelement) -
ulelement -
wbrelement - XML syntax
-
-
[INFRA] defines the following:
- collapsed to a single space
- leading and trailing ASCII whitespace
- willful violations
-
[MEDIAQUERIES] defines the following:
- (grid)
- deprecated braille media type
- the grid feature
- the screen media type
-
[RFC8141] defines the following:
- namespace identifier
-
[URL] defines the following:
- absolute-URL strings
- absolute-url-with-fragment strings
- path-absolute-URL string
-
[XML-STYLESHEET] defines the following:
- xml-stylesheet
This section is non-normative.
This section identifies substantive changes made to the eBraille specification between drafts. For a list of all changes, refer to the issue tracker.
Changes since the 2025-03-03 Candidate Release
- 12-May-2025: Added additional clarifications and improved the requirements that explain how eBraille publications are EPUB publications with a few willful violations. No new requirements were added. Refer to issue 316 and issue 318.
- 05-May-2025: Removed normative requirements from the metadata section that were directly repeating what is already required by EPUB. Refer to issue 319.
- 05-May-2025: Removed the recommendation that identifiers be URNs and replaced with the advisory note from the EPUB specification about using absolute-URL strings and URNs. Refer to issue 320.
- 05-May-2025: Moved the restriction on manifest fallbacks to the section on resource fallbacks. Refer to issue 317.
- 22-Apr-2025: Removed the
a11y:graphicTypeproperty and updated thea11y:tactileGraphicsdefinition to list the formats when tactile graphics are present. Refer to issue 312. - 21-Apr-2025: Reorganized the metadata sections to include condensed property definitions at the beginning of each. Metadata is now arranged by descriptive title rather than element or property name. Refer to issue 311.
Changes since the 2024-10-17 Working Draft
- 25-Feb-2025: Removed the
dateTranscribedproperty due to lack of distinction between it anddc:date. - 24-Feb-2025: Changed all references to EPUB 3 specifications to use undated references due to the new revision.
- 21-Feb-2025: Restricted authoring of the
brailleandscreenmedia types andgridfeature and removed the reading system requirements to handlebrailleto resolve the open editor's note. - 18-Feb-2025: Renamed the
a11y:cellTypeproperty toa11y:brailleCellType. Refer to issue 194.
Changes since the First Public Working Draft
- 07-Oct-2024: Added clarifications that CSS should not be used to insert non-braille characters and that list numbering should be embedded. Refer to issue 273.
- 02-Oct-2024: Replaced the
a11y:sourcePublisheranda11y:sourceDateproperties with guidance on using therefinesattribute to attachdcterms:publisheranddcterms:dateto the source. Refer to issue 280. - 30-Sept-2024: Added clarifying note that
dc:identifieris not for the source work's identifier(s). Refer to issue 171. - 30-Sept-2024: Renamed
codetobrailleSystem. Refer to issue 195. - 30-Sept-2024: Renamed
a11y:createdtoa11y:dateTranscribed. Refer to issue 198. - 26-Sept-2024: Moved
a11y:sourcePublisherto the recommended metadata. Refer to issue 221. - 23-Sept-2024: Added
a11y:sourceDateto the recommended metadata. Refer to issue 200. - 19-Sept-2024: Added
dc:dateas a required element. Refer to issue 263. - 29-Aug-2024: Added media type registration for eBraille container.
- 08-Aug-2024: Updated the names in the
dc:creatorelement examples and added explanation and examples of using thefile-asproperty to provide sorting info. Refer to issue 218. - 08-Aug-2024: Fixed the definition of whitespace characters allowed in content documents to refer to the XML definition as Form Feed is not valid in XHTML. Refer to issue 238.
This section is non-normative.
The following members of the eBraille working group contributed to the development of this document:
- Alex Russomanno (NewHaptics)
- Alexander Hars (Inventivio)
- Alice O'Reilly (Library of Congress)
- Amanda Lannan (University of Kentucky)
- Amanda Whelan (Bucks County Intermediate Unit)
- Andrea Dodson (Curriculum Associates)
- Andrew Flatres (HumanWare)
- Andrey Yakuboy
- Angela Van Appelen (Affordable Braille Production)
- Anja Lehmann
- Aquinas Pather (Allyant)
- Arne Kyrkjebø (Tibi)
- Autumn Booths
- Avneesh Singh (DAISY Consortium)
- Basile Mignonneau
- Bert Frees (DAISY Consortium)
- Beth Pieters (IESBVI)
- Caryn Navy (Duxbury Systems)
- Chantelle Griffiths (Tactile and Technology Literacy Centre)
- Charles LaPierre (Benetech)
- Christian Egli (SBS Swiss Library for the Blind, Visually Impaired and Print Disabled)
- Dan Brown (Pearson)
- Dan Gardner (ViewPlus)
- Dang Hoai Phuc (Sao Mai Center for the Blind)
- Danielle Montour
- Dave Gunn (DAISY Consortium)
- David Holladay (Duxbury Systems)
- Davy Kager (Dedicon)
- Diane Spence
- Dilip Ramesh (Thinkerbell Labs)
- Doug Schepers (Fizz Studio)
- Don van Dijk (Visio)
- Edwin Wong (CNIB)
- Francisco Martinez Calvo (ONCE)
- George Kerscher (DAISY Consortium)
- Greg Stilson (APH)
- Gregory Gerhart (PaTTAN)
- Hari Palani (UNAR Labs)
- Kathryn Sheriff Segers (Tennessee School for the Blind)
- James Bowden (RNIB)
- Jarosław Urbański (Harpo)
- Jason Megginson (The College Board)
- Jen Goulden (Braille Authority of North America (BANA) and Crawford Technologies)
- Jenna Gorlewicz (Saint Louis University)
- Jennifer Dunnam (NFB)
- Jennifer Sutton
- John Ylioja (NNELS)
- Joshua Miele (Amazon)
- Judy Dixon
- Kristin Spencer (APH)
- Ka Li (NNELS)
- Ki Kwang Sung (Dot)
- Kim Charlson (Perkins School for the Blind)
- Kristijan Ciganovic (BBi)
- Kyle DeJute (APH)
- Leona Holloway (Monash University)
- Linda Turner (APH)
- Manfred Muchenberger (SBS Swiss Library for the Blind, Visually Impaired and Print Disabled)
- Marc Sutton (Apple)
- Marty McKenzie (South Carolina School for the Deaf and the Blind)
- Matt Garrish (DAISY Consortium)
- Matthew Horspool
- Melanie Romer Noel (Dot6.ca)
- Michael Cantino (Northwest Regional ESD)
- Michael Hunsaker (Davis School District)
- Michael Johnson (Benetech)
- Michael Ko (HIMS)
- Michael Walker
- Michael Whapples (APH)
- Michal Tkacik (Braille Authority of Slovakia, Matej Hrebenda Slovak Library for the Blind in Levoca)
- Mike Paciello (WebABLE.Com)
- Mischa Kuenzle (SBS Swiss Library for the Blind, Visually Impaired and Print Disabled)
- Nathalie Sorichter (FernUniversität in Hagen)
- Nicole Gaines (APH)
- Nils Huhta (Index Braille)
- Paul Fontaine (Xavier Society for the Blind)
- Peter Sullivan (Duxbury Systems)
- Peter Tucic (HumanWare)
- Reiner Delgado (DBSV)
- Riane LaPaire (NNELS and Braille Literacy Canada (BLC-LBC))
- Richard Orme (DAISY Consortium)
- Robert Jaquiss (Independence Science)
- Ron Miller (Vispero)
- Robert Roldan (Amanuensis Braille)
- Sarah Bradley
- Sara Larkin (IESBVI)
- Sarah Welch (APH)
- Scott Erichsen (National Disability Insurance Agency)
- Sile O'Modhrain (University of Michigan)
- Steve Noble (Pearson)
- Sue O'Brien (TSBVI)
- Susan Osterhaus (TSBVI)
- Svetlana Vasilyeva (Elita Group LLC)
- Tamara Rorie (NLS)
- Thomas Simpson (NewHaptics)
- Tina Herzberg (University of South Carolina Upstate)
- Venkatesh Chari (Orbit Research)
- Willow Free (APH)
- [bcp47]
- Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
- [code-registry]
- eBraille Braille Code Registry. DAISY. URL: https://daisy.org/s/ebraille/registries/codes
- [css-cascade]
- CSS Cascading and Inheritance Level 5. Elika Etemad; Miriam Suzanne; Tab Atkins Jr. W3C. 13 January 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-cascade-5/
- [css-color]
- CSS Color Module Level 3. Tantek Çelik; Chris Lilley; David Baron. W3C. 18 January 2022. W3C Recommendation. URL: https://www.w3.org/TR/css-color-3/
- [css-conditional]
- CSS Conditional Rules Module Level 3. Chris Lilley; David Baron; Elika Etemad. W3C. 15 August 2024. CRD. URL: https://www.w3.org/TR/css-conditional-3/
- [css-fonts]
- CSS Fonts Module Level 3. John Daggett; Myles Maxfield; Chris Lilley. W3C. 20 September 2018. W3C Recommendation. URL: https://www.w3.org/TR/css-fonts-3/
- [css-text-decor]
- CSS Text Decoration Module Level 3. Elika Etemad; Koji Ishii. W3C. 5 May 2022. CRD. URL: https://www.w3.org/TR/css-text-decor-3/
- [css-values]
- CSS Values and Units Module Level 3. Tab Atkins Jr.; Elika Etemad. W3C. 22 March 2024. CRD. URL: https://www.w3.org/TR/css-values-3/
- [css2]
- Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS2/
- [datetime]
- Date and Time Formats. Misha Wolf. W3C. 27 August 1998. W3C Working Group Note. URL: https://www.w3.org/TR/NOTE-datetime
- [dcterms]
- DCMI Metadata Terms. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
- [dpub-aria]
- Digital Publishing WAI-ARIA Module. W3C. URL: https://www.w3.org/TR/dpub-aria/
- [epub]
- EPUB 3.3. Ivan Herman; Matt Garrish; Dave Cramer. W3C. 27 March 2025. W3C Recommendation. URL: https://www.w3.org/TR/epub-33/
- [epub-a11y]
- EPUB Accessibility. W3C. URL: https://www.w3.org/TR/epub-a11y/
- [epub-multi-rend-11]
- EPUB 3 Multiple-Rendition Publications 1.1. Matt Garrish. W3C. 27 June 2025. W3C Working Group Note. URL: https://www.w3.org/TR/epub-multi-rend-11/
- [epub-rs-3]
- EPUB Reading Systems 3. W3C. URL: https://www.w3.org/TR/epub-rs/
- [epub-ssv]
- EPUB 3 Structural Semantics Vocabulary. W3C. URL: https://www.w3.org/TR/epub-ssv/
- [epub3]
- EPUB 3. W3C. URL: https://www.w3.org/TR/epub/
- [html]
- HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
- [infra]
- Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
- [iso8601]
- Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: https://www.iso.org/iso/catalogue_detail?csnumber=40874
- [iso8601-1]
- Date and time — Representations for information interchange — Part 1: Basic rules. ISO 8601-1:2019.. International Organization for Standardization (ISO). 2019. ISO 8601-1:2019. URL: https://www.iso.org/standard/70907.html
- [jpeg]
- JPEG File Interchange Format. Eric Hamilton. C-Cube Microsystems. Milpitas, CA, USA. September 1992. URL: https://www.w3.org/Graphics/JPEG/jfif3.pdf
- [mediaqueries]
- Media Queries Level 4. Florian Rivoal; Tab Atkins Jr. W3C. 25 December 2021. CRD. URL: https://www.w3.org/TR/mediaqueries-4/
- [png]
- Portable Network Graphics (PNG) Specification (Third Edition). Chris Lilley; Leonard Rosenthol; Pierre-Anthony Lemieux; Chris Needham; Simon Thompson; Chris Seeger; Chris Blume; Cosmin Truta. W3C. 24 June 2025. W3C Recommendation. URL: https://www.w3.org/TR/png-3/
- [rfc2046]
- Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2046
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
- [rfc8141]
- Uniform Resource Names (URNs). P. Saint-Andre; J. Klensin. IETF. April 2017. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8141
- [RFC8174]
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
- [rfc9110]
- HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html
- [svg]
- Scalable Vector Graphics (SVG) 1.0 Specification. Jon Ferraiolo. W3C. 4 September 2001. W3C Recommendation. URL: https://www.w3.org/TR/SVG/
- [unicode]
- The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
- [url]
- URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
- [wcag22]
- Web Content Accessibility Guidelines (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 12 December 2024. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/
- [xml]
- Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
- [xml-stylesheet]
- Associating Style Sheets with XML documents 1.0 (Second Edition). James Clark; Simon Pieters; Henry Thompson. W3C. 28 October 2010. W3C Recommendation. URL: https://www.w3.org/TR/xml-stylesheet/
- [xmlschema-2]
- XML Schema Part 2: Datatypes Second Edition. Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/
- [css-page]
- CSS Paged Media Module Level 3. Elika Etemad. W3C. 14 September 2023. W3C Working Draft. URL: https://www.w3.org/TR/css-page-3/
- [mathml]
- Mathematical Markup Language (MathML™) 1.01 Specification. Patrick D F Ion; Robert R Miner. W3C. 7 March 2023. W3C Recommendation. URL: https://www.w3.org/TR/REC-MathML/
- [rfc8089]
- The "file" URI Scheme. M. Kerwin. IETF. February 2017. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8089
- [wai-aria-1.2]
- Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper; Carolyn MacLeod. W3C. 6 June 2023. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
- [xml-names]
- Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/
Referenced in:
- § 1.4 Future directions
- § 1.5 Terminology
- § 3.5 Resource location
- § 3.7 File extensions
- § 5.1 Introduction
- § 5.3.3.8 Language
- § 5.4 Manifest
- § 5.5 Spine
- § 6.1 Introduction
- § 6.2 XHTML
- § 6.2.1 Character encoding (2)
- § 6.2.3 Unsupported features
- § 6.3.1 Introduction
- § 6.3.2 CSS requirements
- § 6.4 Authoring best practices
- § 9. Media overlays (2)
- § 13.2.1 General
- § 13.2.6 Core media types
Referenced in:
- § 1.2 Relationship to EPUB 3
- § 3.3 Foreign resources
- § 3.6 Exempt resources
- § 4.2 File and directory structure
- § 5.3.3.7 Identifier
- § 6.2.2 List formatting
- § 6.2.3 Unsupported features
- § 6.3.1 Introduction
- § 6.3.2 CSS requirements
- § 10. Accessibility
- § 11.1 Threat model
- § 12.2 Web-hosted eBraille publication
- § A.1 About the properties
- § A.2 Extension properties
- § A.3 Optional metadata definitions
Referenced in:
Referenced in:
- § 1.1 Overview (2)
- § 1.2 Relationship to EPUB 3
- § 1.4 Future directions
- § 1.5 Terminology (2) (3) (4)
- § 2. eBraille publication conformance
- § 3.1 Introduction
- § 3.2 Core media types
- § 3.3 Foreign resources
- § 3.5 Resource location
- § 3.6 Exempt resources
- § 3.7 File extensions
- § 3.8 XML conformance
- § 4.1 Introduction
- § 4.3 File paths and file names
- § 4.4 URLs in the eBraille file set
- § 4.5 Multiple renditions
- § 5.1 Introduction
- § 5.3.1.1 Metadata elements (2)
- § 5.3.3.1 Braille cell type (2)
- § 5.3.3.2 Braille system
- § 5.3.3.7 Identifier
- § 5.3.3.8 Language
- § 5.3.3.9 Last modification date
- § 5.3.3.11 Publication date
- § 5.3.3.12 Tactile graphics
- § 5.3.3.13 Title
- § 5.3.4.2 Education level
- § 5.3.4.3 Publisher
- § 5.3.4.4 Rights
- § 5.3.4.5 Source
- § 5.3.4.6 Subject
- § 5.4 Manifest
- § 5.5 Spine
- § 5.6 Additional unsupported features
- § 6.1 Introduction
- § 6.2.3 Unsupported features
- § 7. Layout rendering control
- § 8.1 Introduction
- § 8.2 General requirements
- § 8.3.2 Page list
- § 8.3.3 Landmarks
- § 9. Media overlays
- § 10. Accessibility
- § 11.1 Threat model
- § 11.2 Risk mitigation
- § 12.1 Packaged eBraille publication
- § 12.2 Web-hosted eBraille publication
- § 13.1 Introduction
- § 13.2.1 General
- § 13.2.2 Other unsupported features
- § 13.3 Browser-based reading systems
- § A.1 About the properties
- § A.3 Optional metadata definitions
Referenced in:
- § 1.2 Relationship to EPUB 3
- § 3.2 Core media types
- § 5.5 Spine
- § 6.2.2 List formatting
- § 6.3.1 Introduction
- § 6.3.3 Media queries
- § 6.4 Authoring best practices
- § 8.2 General requirements (2)
- § 8.3.1 Table of contents
- § 8.3.2 Page list
- § 13.2.1 General
- § 13.2.5 Media queries
- § 13.3 Browser-based reading systems
- § A.3.1 Minimum cells
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: