Matt Garrish and Romain Deltour both work for the DAISY Consortium, a non-profit organization committed to enabling equal access to information and knowledge regardless of disability. Romain Deltour will be at ebookcraft 2018 on March 21 leading a workshop called Is Your EPUB Accessible? Put It to the Test!
Ever tried to jump into a new technology only to discover that everyone seems to be speaking in tongues? And while you think you sometimes catch the sound of English words, those words don’t seem to mean what you thought? And no matter how much you try to Google to catch up, it only leads to more confusing terminology, until you’re ready to throw your laptop at the first poor soul who happens to walk by? Trust us, you’re not alone, so take a deep breath and put down the laptop before anyone gets hurt. We’re here to help.
Sadly, even though we deal in accessibility, it doesn’t mean that accessibility jargon is any more accessible than any other jargon. With that in mind — and knowing we’re inevitably going to fall prey to jargon’s seductive charms when we talk about the Ace accessibility checking tool for EPUB — we wanted to share a list of key concepts, standards, and organizations that every good accessibility practitioner needs to know to keep their sanity.
Okay, so this is one you won’t usually hear people say, but it’s everywhere in accessibility literature. It’s literally just an abbreviation of “accessibility” — there are 11 characters between the “a” and the “y.” You even pronounce it “A-eleven-Y.” (For brownie points, it’s what’s called a numeronym!)
AT is the ubiquitous acronym for “assistive technology.” An assistive technology is any device, software program, or application feature that readers require to consume a publication. Some examples include:
- screen-reading software programs, like NVDA and Jaws;
- refreshable braille displays, which are hardware devices that transform the digital text to physical braille; and
- zooming software that allows low-vision readers to increase the page size.
The ubiquity of AT speaks to how often the term is used and how much simpler it is to say than “assistive technology.”
Accessibility APIs (application programming interfaces) are what allow assistive technologies to communicate with the different programs that run on any given operating system. An assistive technology is not directly in control of a browser, for example, but gets information and sends commands to the browser through the platform’s accessibility API. Think of them like middlemen.
DOM / Accessibility Tree
This is a two-parter that gets to the root of how content is made available to assistive technologies. The document object model (DOM) is a representation of a web page that browsers create when they render the page (i.e., read the source, run scripts, apply style sheets). The DOM is most easily thought of as a tree, where the branches represent the elements and text of the document (e.g., at the top is the HTML element, below it head and body elements, and so on).
The typical web developer has a good sense of the DOM, as it’s at the heart of scripting web content. What isn’t so widely known is that the DOM isn’t the only representation of the page and it’s not what assistive technologies access. A different structure, called the accessibility tree, is also generated and this is what browsers expose to the accessibility APIs. The accessibility tree is derived from the DOM, but typically contains many optimizations, such as the removal of unnecessary tags and formatting and the inclusion of roles and states.
For a good visual representation of the relationship between the DOM, accessibility tree, and accessibility APIs, see the Accessibility Object Model proposal.
The document outline refers to the heading structure of the publication (i.e., the hierarchy of <h1> through <h6> HTML headings). To allow users to move through the document in a logical and meaningful way, the use of headings needs to reflect their relative importance: There can’t be gaps and inconsistencies.
The document outline is roughly equivalent to a complete table of contents, but will also include headings used in supplementary content, such as sidebars. The Ace reports include both the table of contents and a generated document outline so you can verify the heading structure easily.
At first glance, accessibility supported probably sounds like a way of describing an accessible method of creating content. And that’s sort of true, but the more critical point of the expression is that whatever it is you’re producing also has to have real-world support. Accessible practices have to be more than theories and unimplemented features to be useful. A cool new experimental feature for describing images in an unreleased browser might one day qualify as accessibility supported, for example, but until it’s widely supported in browsers it fails accessibility requirements.
WCAG is the abbreviation for the Web Content Accessibility Guidelines. These are the guidelines that define accessible practices for the web, and they’re the foundation on which Ace‘s accessibility checks are built. The acronym is pronounced “WUH-cag.”
WCAG is built on four key principles: that content be perceivable, operable, understandable, and robust. These are collectively known as POUR.
Perhaps the best way to describe schema.org is as the vocabulary of the web. It’s used to describe different aspects and features of a web page for search optimization. It’s important for accessibility since it contains a set of properties for describing the accessibility of content.
The EPUB Accessibility specification builds on WCAG to define accessibility for EPUB publications. It also adds a requirement for the inclusion of schema.org accessibility metadata to improve the discoverability of publications in supply chains and on the web.
The name is usually shortened to ARIA as WAI (pronounced “way”) simply refers to the group that developed the standard (the Web Accessibility Initiative).
DPUB-ARIA is an extension of ARIA that adds new roles for publications, allowing the identification of the table of contents, chapters, and indexes, among other key sections.
Like WAI, DPUB (pronounced dee-pub) refers to the World Wide Web Consortium’s (W3C) Digital Publishing group, who developed the vocabulary.
The World Wide Web Consortium describes itself as “an international community that develops open standards to ensure the long-term growth of the Web.” It maintains many of the web’s key standards. W3C’s work developing and promoting web accessibility has also been vital in making formats like EPUB more accessible to all.
The International Digital Publishing Forum was a global trade and standards organization that was responsible for the development and maintenance of the EPUB format. The IDPF merged into W3C in 2017, leading to the formation of the Publishing@W3C initiative to continue the work on EPUB and new web-friendlier publishing formats. (IDPF is mostly a relic now, but still pops up in conversation.)
The DAISY Consortium is who we work for! It’s a global consortium of organizations committed to making reading materials accessible to all. The DAISY Consortium was founded over 20 years ago to promote the DAISY talking book standard, but has engaged strongly with both the IDPF and W3C over the years to bring digital publishing accessibility into the mainstream.
Matt Garrish has been working in publishing for as long as he can remember, and writing and editing digital publishing standards for over a decade. His addiction to specification writing began with the DAISY Consortium, and soon spread to IDPF and most recently W3C. He is the general editor of EPUB and the forthcoming Web Publications standard, and takes a special interest in accessibility.
Some of his efforts to make publishing more inclusive include contributing to the development of accessibility metadata in schema.org, co-authoring the Digital Publishing WAI-ARIA module, and participating in the development of WCAG 2.1. He has also published books on EPUB accessibility and best practices.
When not working on standards, Matt is helping the DAISY Consortium develop accessibility conformance testing and reporting tools for EPUB. He’s often hard to find online as the rest of his time is occupied fielding an endless litany questions from his inquisitive young daughter who thinks daddy’s job is sooo boring.
Romain Deltour is a software developer for the DAISY Consortium, a non-profit organization committed to enabling equal access to information and knowledge regardless of disability.
After having worked at INRIA in the Web Adaptation and Multimedia team, Romain joined the DAISY staff in 2006, where he led the development of automated accessible publishing tools and contributed to IDPF’s EPUB Working Group. He’s also one of the primary maintainers of EpubCheck, the conformance checker for EPUB.
Nowadays, Romain’s focus is extending to automated evaluation of ebooks’ accessibility, as well as the future of Web publications. As an active member of W3C’s Publishing Working Group, Romain firmly believes in the web’s potential to enable a truly inclusive publishing ecosystem.
If you’d like to hear more from Romain Deltour about putting your EPUB to the accesibility test, register for ebookcraft, March 21-22, 2018 in Toronto. You can find more details about the conference here, or sign up for our mailing list to get all of the conference updates.