A recent development in publishing is the increased attention to accessibility. But this needs to be more than just making content accessible. The systems involved in the creation, development, production, and dissemination of the content need to be accessible as well.
“People First” needs to include people often overlooked in many communities: people with perceptual, cognitive, or physical disabilities. The good news: it’s getting easier now than it has ever been to ensure that editorial and production workflows enable the production of properly accessible content. Less common, but equally important, is ensuring that the systems used in those workflows are themselves accessible. Fortunately, there has been a convergence in recent years between the technologies on which editorial systems are built and the technologies on which accessibility standards are based. After an overview of these technologies and standards, this essay will first focus on the role of the editor in making content accessible (it’s not just the job of vendors or digital staff), with concrete examples of things editors can do to contribute to the full implementation of accessibility downstream. Then the issues regarding making systems and web-based interfaces accessible will be discussed. The goal: to encourage publishers and systems providers to work together to make the editorial and production process as “born accessible” as the publications they produce.
Significant progress has been made over the past few years in making content accessible. While the focus has often been on “open access”— making content freely available, outside subscription paywalls or retail walled gardens — what has historically (and even to this day) been often overlooked is whether that content is accessible to people with perceptual, cognitive, or physical disabilities. That’s the sense of “accessibility” I’m addressing here.
There are far more of those people than most of us realize. As my friend Michael Johnson from Benetech is fond of pointing out, there are more blind people than people with red hair, and more people with dyslexia than left-handed people. Those are only two of many visual disabilities (low vision and color blindness are also very common ones). Add to that the Deaf community, or people with motor impairments — to add two more common populations — and you’ll start to realize that accessibility is a real issue for a lot of people.
The progress I referred to above has mainly been about making content accessible—the books, journal articles, and websites that all too often are difficult or impossible to consume by people with disabilities. What more attention needs to be paid to is the accessibility of all the systems used to author, edit, produce, and publish that content. What good is accessible content if you can’t get to it?
I had the privilege of being the guest editor of the January 2018 issue of the Learned Publishing journal devoted to accessibility. Without question, I wanted an article from George Kerscher, who for decades has been a leading driver and advocate for accessibility—and who is blind. As it happened, this is exactly the topic George wanted to write about. Of course, I contributed an article as well. It took me perhaps ten minutes to navigate the publisher’s article submission system. It took George almost an hour—at the end of which he couldn’t find the “Submit” button. He had to email the article to the editor to submit it for him.
This sort of thing happens every day, to thousands of people with disabilities, all over the world. I hope that enrages you as much as it enrages me.
But first, let’s set the stage with the good news about accessibility standards.
The single most significant enabler of accessibility is that now most of the world’s accessibility requirements are based on web standards that have become ubiquitous. Many—including most of those relevant to publishers—are governed by the W3C, the Worldwide Web Consortium. The most ubiquitous of those is HTML, the markup standard for websites; HTML is now the fundamental markup for accessibility. That means that if content uses HTML markup properly (we’ll get to what that means a bit later), it’s already potentially accessible. For example, assistive technologies (AT) such as screen readers are designed to understand HTML markup, enabling their users to navigate and consume content not by visual cues but by headings, tabs, and other markup via keyboard.
The W3C provides other standards that supplement or enhance basic HTML markup. ARIA1 markup provides semantics that augment the native semantics provided by HTML—for example, identifying a <section> as a chapter or an <aside> as a sidebar. MathML enables math to be spoken to users with visual disabilities; HTML table markup enables a screen reader user to navigate the rows, columns, and cells of a table — and to tell which of those cells are row or column headers. Finally, WCAG—W3C’s Web Content Accessibility Guidelines2 — provides the basis for assessing whether content or systems are sufficiently accessible, and what shortcomings need to be addressed.
Best of all, these are technologies that are already a part of most publishers’ editorial and production workflows, sometimes used in-house, more commonly used by their vendors. Even for books: the proper interchange format for accessible publications is now EPUB 3.3 The content documents (e.g., chapters) in an EPUB are marked up in — you guessed it — HTML (expressed as XML, for now).
While much more content, especially in higher education and increasingly in scholarly and trade publishing, is much more accessible than it used to be, that accessibility is often the result of processing after standard production workflows are complete. It is common for book publishers to outsource the creation of accessible EPUBs to conversion vendors, or to the prepress vendors who typeset the print books. Many of the leading vendors are now quite expert in this. However, this post-production outsourcing adds cost and delay that can be avoided if accessibility is addressed upstream in the editorial and production workflow.
One of the most common accessibility issues is the lack of proper image descriptions. Images in HTML require what is called “alt text,” which is a short textual description of the image. All too often, the alt text is missing, insufficient, or useless. In my work, I commonly see alt text consisting of the file name or path to the image. Imagine how not only useless but annoying it is when a screen reader user hears that spoken out loud! Another common mistake is using the caption as the alt text. The screen reader user has already heard the caption; now, annoyingly, it’s read out again. Plus, a caption typically identifies an image; alt text should describe it. When the image conveys significant information to the user — for example in a chart, graph, or diagram — the alt text, which is typically limited to 150–250 characters, is insufficient. These require what are called “extended descriptions” (previously referred to as “long descriptions”) that convey to users with visual disabilities what the image conveys to a sighted user. That often involves a paragraph or more of text, and markup for things like lists and headings.
Creation of image descriptions is often outsourced, sometimes to the conversion or prepress vendor, sometimes to firms that specialize in image descriptions. Yet, if the issue of the image descriptions hasn’t been addressed upstream in the workflow, the job of those vendors can be made more difficult or even impossible. In scholarly work, most images are provided by the authors; in education, the creation of images is most often done by graphics professionals, and the alt text needs to address particular pedagogical issues; and even in trade, a post-production vendor may not understand what the purpose of an image is. It’s better for authors to provide what I like to call “draft image descriptions,” and then for editors, who have been trained to understand what good image descriptions require, to refine them—just as they refine all the other content. That’s the job of an editor, not a production vendor!
There are other issues as well that are best addressed upstream in the editorial and production workflow. For example, headings need to be properly structured (which means nested properly, with no heading levels skipped), because users of assistive technology depend on them to understand how the content is structured, and to be able to jump from heading to heading as they navigate the content. I mentioned column and row headings in tables: those are essential to screen reader users because without them the assistive technology just says, for example, “row 16, column three” when the number in that cell should be described as “Iowa, population” because the rows are the names of the states and the third column contains their populations. A well constructed table of contents, ideally with subheadings, is a big help to disabled users in navigating the content. Links and form fields need to be properly labeled because otherwise the user of assistive technology — who cannot “see” the context — doesn’t know what is being linked to or what the form field requires.
These are just some of the issues that are essential to users of assistive technology for which authors and editors are best positioned to get right in the first place. I don’t want to leave designers off the hook: one of the most common deficiencies in the books and websites I analyze for accessibility is insufficient color contrast. Small type, often gray, and a soft pastel color palette, are fashionable these days, but when the type is too small or the contrast between the text and the background is insufficient, people with low vision or color blindness can’t discern it. For similar reasons, information should never be conveyed solely by color.
It’s really important for everybody in the organization — and particularly everybody involved in the creation, development, and dissemination of content — to be conscious of accessibility. While that may mean that there are some new issues that design, editorial, and production staff need to pay attention to, by involving everybody in ways that make sense given their roles and expertise actually reduces the work overall. Ultimately these issues need to be addressed; kicking the can downstream often results in their being dealt with by people less qualified or at additional cost and delay.
It should be obvious that no matter how good a job a publisher does of making its content meet accessibility standards, it’s all for naught if people creating or consuming that content can’t access the systems used in its development or dissemination.
Addressing these problems may seem highly technical, but it’s not rocket science. I mentioned above that form fields need to be properly labeled. Very likely the word “submit” was somewhere near that elusive “Submit” button that George couldn’t find. ARIA provides two solutions: to add to the button the attribute aria-label="submit" or the aria-labelledby attribute with the ID of the element where the word “submit” is provided. Without these, George was lost, because he can’t “see” the surrounding context that sighted people take for granted.
The same thing goes for links. Most people don’t realize that assistive technology users are often presented with the links in the content they’re consuming as a list. If the only text in the link is the URL of the link — and especially if that link is insufficiently descriptive, which is true of most URLs — the user of AT has no way to identify what the link is linking to. The link itself needs to provide that information.
Keep in mind that there are a lot of different types of disability, and lots of content that isn’t textual in the first place. Video and audio resources need closed captions for the Deaf and hard-of-hearing community. Conversely, videos need what are called “audio descriptions” (you might call them video descriptions; they mean the same thing): spoken descriptions of the visual content, designed to co-exist with the spoken dialog in the video.
People with many types of disabilities need to navigate entirely by keyboard, which means that they need to navigate and identify content by headings and landmarks and other markup that provides “focus” on specific places in the content that sighted users navigate visually. A common problem is what are called “modals,” those dialogs that pop up on top of the content, based on or for interaction: not only does assistive technology need to provide focus on the modal, it also needs to go back to the right place when the modal is closed. In most websites I’ve analyzed, an even more annoying problem occurs: although the modal covers up the content behind it for a sighted user, the content “behind” the modal is often still present to the user of assistive technology, making it basically indecipherable.
These are just a few of the many aspects of interaction with and consumption of content that more attention needs to be paid to.
The good news is that the same standards that govern making content accessible also apply to making the systems by which it is created, discovered, disseminated, and consumed accessible as well. I mentioned WCAG as the fundamental standard for assessing accessibility. We are now at version WCAG 2.1; WGAG 2.2 is about to be published, and WCAG 3.0 is under development. (Don’t hold your breath; it will be several years before WCAG 3.0 is finalized. WCAG 2.1 is what you need to conform to at the time this article was published.) The reason I bring this up is that WCAG is currently the acronym for Web Content Accessibility Guidelines. WCAG 3.0 will stand for “W3C Accessibility Guidelines.” It’s not just about the content, it’s also about all the systems we use to create and consume it.
And fortunately, as the technology landscape has evolved, the standards enabling this are converging. Most content, from newspapers to college textbooks, is now consumed online, and increasingly in small format devices like phones. While most trade books are still sold as print, virtually all trade publishers also provide them as EPUBs (which, by the way, should be accessible EPUB 3s), and most of them deliver exactly the same EPUB 3 to all the retailers—yes, even Amazon. Finally, increasingly the technologies that deliver the content to the end users—Apple, Google, Kobo, Amazon, etc. for books; hosting platforms like Atypon, Silverchair, and HighWire for journals; aggregators like VitalSource and RedShelf for textbooks; and the platforms by which higher education publishers increasingly deliver their content—are all based on the same underlying W3C standards.
It's about time.
Bill Kasdorf, email@example.com, is Principal of Kasdorf & Associates, LLC, a consultancy focusing on editorial and production workflows, XML/HTML/EPUB content modeling, standards and best practices, and accessibility. He is a founding partner of Publishing Technology Partners. Active in the W3C Publishing@W3C activity, Bill is the W3C Global Publishing Evangelist. He is a member of NISO, co-chairing two NISO Working Groups, and is an active member of SSP, BISG, IPTC, and the DAISY Consortium. Recipient of the SSP Distinguished Service Award and the BISG Industry Champion Award, he is the general editor of The Columbia Guide to Digital Publishing, serves on Learned Publishing’s editorial board, and is a columnist for Publishers Weekly. His clients have included societies such as NEJM, NAP, IEEE, and ACP; MIT, Harvard, Cambridge, Toronto, and Columbia university presses; publishers like PLOS, SAGE, Norton, Cochrane, and Pearson; and the British Library, the World Bank, OCLC, ORCID, and the EU Publishing Office.