The Labor Pains of Born Accessible

– Good morning, everybody. It’s really pleasure to be here in this beautiful building and with a lot of friends. I am Cristina Mussinelli. I work for the LIA Foundation. That is Italian Accessible Book. It’s a foundation funded by the Italian Publishers Association. I think this is a very important track. The title is Publisher and Vendors Doing the Right Thing, because in this moment, accessibility, it’s a growing opportunity in the publishing industry, and I think that collaboration between publisher and special organization and all the other working in the publishing value chain is really important.

We have this morning two publishers speaking about their experience, and highlighting the possibility, but also the issue that they face in going mainstream in accessibility. I think it’s important because it’s one of the most important thing if we want to work together, is to better understand the options and the problems that we need to face together and what we need to find a solution. First speaker is Tzviya Siegmund. We have listened to the prince this morning, and let’s say that she is the princess of accessibility in the mainstream publishing. She is the digital book standard and capabilities lead at John Wiley and Sons. Please, Tzviya.

– Thank you. Good morning. Just give me one second. Oh, somebody did it for me, thank you. Thank you, Cristina. I can never quite see over the podium. Thank you so much for having me. Today I’m going to talk a little bit about the labor pains of born accessible. We don’t always get to accessibility easily, and I’ve been striving to get Wiley to accessibility as quickly as possible. But it’s been a long journey, and I’ll talk today a little bit about how we’ve gotten where we are and where we’re headed next. I’ll give you a brief history of Wiley. Wiley develops digital learning, assessments, certifications, and references to help universities, businesses, and individuals bridge between education and employment and achieve their ambitions.

We partner with learned societies and support researchers to communicate discoveries that make a difference. Our digital content, books, and 1,600 online journals build on a 200-year heritage of quality publishing. Five years ago, this slide would have said that Wiley is a publisher. You may notice that the word “publisher” doesn’t appear here. With the ascent of digital products, services, and everything that goes along with that, Wiley has approached a new definition of what it means to be a publisher in this age. With that comes a lot of responsibility. We’ve moved away from just being a publisher that focuses on textbooks, journals, and professional books, to offering services, and with that, of course, comes the responsibility of providing accessible products. Here’s a little bit about me, and thank you Cristina for calling me the Princess of Accessibility.

There are many people here who know far more about accessibility than I do. I’m the Information Standards Lead at Wiley, which means that I take care of our content structure for all of our products, both print and digital, along with a team of a few other people. I co-chair the Digital Publishing Interest Group in the W3C. I also co-chair the EPUB 3.1 Working Group. My co-chair for both of these is the DAISY CTO Markus Gylling. Sorry. I assume you all know Markus on a first-name basis. I dabble in other standards, including ARIA, and other W3C web accessibility initiatives. I also participate in other industry standards organizations such as the Book Industry Study Group, where we’ve worked to bring together other accessibility standards and compile them into some documentation that helps other people gain access to accessibility.

Here’s what I’ll go over today. Content structure, which I think is pretty much the foundation for accessible content. How the Accessibility Tree interprets content, which can get a little bit confusing. We talk a lot about the technicalities of accessibility, and we throw words around, like the Accessibility Tree, and assistive technology. I know that when I first came into this I had no idea what these terms meant. Image descriptions, another area that we all talk about and is crucial to understand, but it’s not necessarily clear what the best way to go about that is.

Testing, and building a born-accessible culture. I should warn you that this is very much a work in progress. I haven’t yet reached what I’ll call accessibility nirvana. I just hope that you can benefit from what I’ve worked on, some of my research, and maybe you can take something away from this. First I’ll talk about why I’m doing this now. Wiley is in the process of overhauling our content model. We had one content model for all of our products for years, books, journals, our learning management system for textbooks, and we’ve had this for years. We’re now shifting away from an XML-based model to an HTML and linked data model. This is an excellent opportunity, and when opportunity knocks, you don’t throw it away.

Congratulations! I’ve been given access to everything and told to make it accessible. Pictured is Edward Munch’s “The Scream.” It’s a little terrifying to be told to make everything accessible. Where does one start? There’s an abundance of documentation online and offline, and here’s a list of just some of the documentation that exists.

There’s the ARIA documentation, The Web Content Accessibility Guidelines, Using ARIA in HTML, the IDPF’s EPUB Accessibility Guidelines, and the DIAGRAM Center’s Image Description Guidelines. Over the last year or so, we’ve written more documentation. Some of it’s supposed to help. Perhaps some of it makes it a little bit more confusing. As I mentioned before, content structure is a really good place to start, because you’re starting from Scratch. That’s Scratch the Cat from the MIT programming language.

The foundation of all products is content structure. Unlike XML, there’s not a strict definition of HTML, of valid HTML, unless you write it yourself in XSD or some other fun programming language. It’s really easy to write valid HTML. It’s a lot less easy to write HTML in a semantically meaningful way. Not all HTML is created equal, of course.

Can you tell which of these conveys more information? There’s the same text in both of these examples. On the left, I have a section tag, an H2 that says “Immunopathogens,” and a paragraph that explains what immunopathogens are, or discussing immunopathogens.

This is from one of Wiley’s fascinating journals about disease. On the right I have a div, a P tag that says “Immunopathogens,” and then that same paragraph in a P tag. Anybody want to tell me which of these conveys more information. The left, correct. Why does that matter? To the sighted reader, these could look exactly the same. Why does the HTML tag matter? Every HTML tag carries native semantics. This is not something they usually teach in HTML school. We don’t usually go to HTML school. We usually just pick it up on our own. But it would solve many of the accessibility problems with static content on the web if people knew about this. HTML is a language of semantics, not just a language of containers. This became even more true with HTML5.

Most of the tags that were added to HTML5 actually conveyed semantic information, not just information like “this is a piece of content.” Those tags say something about what the piece of content is. And, something that I didn’t know until about a year ago, all HTML is mapped to the APIs that communicate with Assistive Technologies through the Accessibility Tree. Ooh, that didn’t come out right. There’s a bunch of gobbledygook on the left, but it just says that this is taken from the ARIA 1.1 Accessibility API mappings. But let’s talk about what the Accessibility Tree is.

I’m going to read this straight off, because it’s not something anybody should memorize. This is full of lingo, and it’s taken straight from the Core Accessibility API mappings from ARIA 1.1. “The accessibility tree and the DOM tree “are parallel structures. “It includes the user interface object of the user agent “and the objects of the document. “Accessible objects are created in the accessibility tree “for every DOM element that should be “exposed to an assistive technology. “generally, if something can be trimmed out it will be “for reasons of performance and simplicity.”

So let’s translate that. Once again, this didn’t come out quite right. Those are code samples on the bottom. I’m guess that this slide, whatever program is displaying this doesn’t really like the font I chose. Another reason why everything– We talk a lot about what’s necessary for assistive technology. I’m hoping that assistive technology would still be able to interpret this. Somebody in the audience can tell me. I’ll thank Jodie Diggs, one of the authors of ARIA, for helping me put together this step-by-step analysis of how assistive technology reads the accessibility tree.

Step one.

The DOM Tree is examined by the user agent to decide whether to include or skip each element. We said before that one of the important parts of understanding what’s in the accessibility tree is whether something should be skipped. Assistive technology likes to skip stuff because it wants to process things quickly. So if there’s something that’s unimportant it just gets cut.

Step two.

A generic or platform-agnostic accessibility tree is built by the user agent based primarily on the DOM Tree. That “primarily” is a very important thing to note. There’s a kind of generic accessibility tree that’s based primarily on the DOM element, so that’s the HTML tags. But there might be some things from the Render Tree, that’s built by the CSS, that are included. Important information there. Then a platform-specific accessibility tree is built by the user agent and exposed to assistive technology. Those accessibility API mappings convey information to each platform’s accessibility tree. There’s one for Microsoft, one for Apple, and one for Linux. Actually two for Microsoft, but we don’t need to get into that now.

Each assistive technology accesses the user-agent-built accessibility tree for that AT’s platform. The stuff that you can’t make out because it looks like nonsense there gives some examples. Let’s say we have a plain old span. The accessibility tree completely ignores that, because it has no semantic meaning. However, if I do span rule equals heading, I’ve conveyed enough information to assistive technology for the accessibility tree to pick it up. Then it’s included in the generic accessibility tree, and then each operating system has a specific meaning based on those mappings, and it gets picked up in a specific way for each assistive technology. I’ve talked a lot about ARIA, and I realized as I was putting this together, I hope that everybody has at least heard it, but we talk about it a lot, and we don’t necessarily give definitions.

Here’s another lingo-full slide that explains it. Also taken straight from the specification. “This specification provides an ontology of roles, “states, and properties that define “accessible interface elements “and can be used to improve the accessibility “and interoperability of web content and applications. “These semantics are designed to allow an author “to properly convey user interface behaviors “and structural information to assistive technologies “in document-level markup.” So ARIA takes content that otherwise might not be conveyed to a reader, or a user, who is non-sighted, and applies semantics so that somebody can navigate through it without the advantages of seeing or perhaps using a mouse.

Let’s take a simple example. The example that I think most people hear is that there’s a rule equals button. Often, people will use something like an image to act as a button. If I am a non-sighted reader, I don’t understand that that, I can’t perceive that that image is actually a button, so I will use the HTML tag image, I will add the ARIA rule equals button property rule, and then ARIA conveys to assistive technology that that is actually acting as a button. How can we use ARIA in publishing? Setting aside interactive content, which is really the primary use of ARIA for now, in our basic content structure we can apply roles in our content model. ARIA can be a little bit overwhelming, admittedly, and it takes a little bit getting used to the lingo. But familiarizing yourself with ARIA is truly worthwhile.

Let’s take a look at this. We talked about HTML elements that have no semantic meaning. Div is one example of that. But if we apply role equals heading and give an ARIA level to it, ARIA level as a property, so div rule equals heading, ARIA level equals three has the same meaning as H3, which is an HTML element. Now, I don’t recommend going through all that just to convey H3, but it gives you an example of what ARIA is capable of. Coming soon, there’s the digital publishing module of ARIA, which is currently in its third draft. We hope that it will come to recommendation, full recommendation along with ARIA 1.1 later this year.

Some examples of what’s possible with the digital publishing module is that you can apply things like the abstract rule to a section. This conveys to the reader that this section is an abstract, and then it will make it a landmark for somebody using assistive technology. So if I create a list of the main sections in a document, I’ll then see the abstract, and I can jump to the abstract. Similarly, we have a role end note. I can jump to the end notes easily. There are a number of other roles, but I haven’t listed all of them here, because I hope you can get to the documentation yourself. What does this have to do with creating a workflow? In my opinion, the only way to construct content that is accessible is to understand what the meaning of every HTML element truly is. When I’m working on this at Wiley, I actually sit with a document called “Using ARIA in HTML,” and look at the semantic meaning of every HTML element.

There’s a table at the end of the document that lists the semantic meaning of every element, and I compare them. One example here that I already mentioned is that div carry no implicit ARIA role. However, aside carries the ARIA role equals complementary. Then you can begin to understand how assistive technology might be reading your content. I wish I remembered what the bottom of that slide said. Then, of course, we know that there’s more than just text. We have to make our images accessible to everybody as well. There are so many options for image descriptions. It can get awfully confusing. Alt text, Longdesc, aria-describedby, the recently deceased, the was a cross-out line there, the recently deceased aria-describedat, and aria-details. It can be difficult to figure out which you should choose.

Alt text is really important for short descriptions. It’s probably the most important, because, as we talked about before, assistive technology is looking to prune elements that aren’t important. If you don’t include a short description using alt text, then the accessibility tree will simply cut it out. So that image as read is not important. We talk about that as null text. If the image is not important, then simply exclude it, and that’s why your assistive technology will jump over it. It’s important to figure out who will write your image descriptions. This is something that we’ve had a lot of discussion about at Wiley.

A lot of people have suggested that the best person to write image descriptions is the author. I personally find that difficult, because it means you’re constantly training people to write alt text. Writing alt text is not something that necessarily comes naturally to people. There’s a lot of training involved. If you read documentation about it, it’s not the same thing as writing a figure caption. People have to learn to write image descriptions. You’ll find that a lot of bad image descriptions out there are a lot like figure captions.

They don’t actually describe images. They talk about what the image is supposed to convey, which is not the same thing. If you have authors write alt text, then you will have to train every single author to write alt text. Then you also get into budgetary issues because authors don’t really want to do more than they’ve been contracted to write. You might want to consider having your production editors, your copy editors, your editorial assistants, write your alt text. But whoever it is, figure out who’s responsibility it is, because somebody has to do it. Then, obviously, you have to run training sessions.

I’ve found that some people actually really enjoy this. They take to it. If you’ve found people in your group who want to do this, then glom onto it. People like different things. I’ve found that with everything that I’ve trained staff to do, there’s somebody out there who enjoys it. Pick it up. Then, obviously, you need to explain the concept. Then write the description yourself. Probably do this before you start the training. You can’t train people to do it if you don’t know how to do it yourself. Close your eyes and perceive the images as somebody who’s using these images. If you cannot understand what the image is supposed to be conveying without looking at the image yourself, then you haven’t done a good enough job. Then, of course, short descriptions may not be enough. Many images, including charts, diagrams of molecules, financial models, infographics, need much more than a short description. Sometimes you don’t get a budget for more than that, but that’s a separate conversation.

HTML and ARIA offer a few options. We have hot controversy about this for reasons beyond me. Long desk is disputed. In ARIA we have aria-describedby, which is for images only. It usually needs to be hidden in some way, but it’s available. Aria-details is coming soon, thanks to the many people in this audience who helped make that happen. It can describe anything in the HTML document, or non-HTML document. It can be used for tables, images, charts, anything along those lines.

There’s no need to hide it, because it can live outside of the document. It can even point to external files, so if you want to describe something that will print out a 3D diagram, that could even be accomplished in aria-details. I didn’t actually give you an answer about which image description type to be used, but there are many options, and I hoped I described the sufficiently so you could choose for yourself. Cop out, I know. Let’s talk a little bit about Testing.

There’s a Rorschach test there. I start with automated testing. There are hundreds–maybe not hundreds. There are dozens of open source tools to check if your content is WCAG compliant. Choose one. There are lists out there of which ones are better than the others. I’ve found that a lot of them are similar. Just pick one, any one, and get started. These tools do have limitations, but they’re an excellent way to get started.

You’ll find out if your links are accessible, if your tables are well structured, and if your headings are navigable. Some will even catch some of those issues that we’ve talked about for years as not being testable. So if you say image, if you see alt equals image, then these tests sometimes will tell you, “Are you sure you meant to say image? “Maybe you need to have a more detailed description there.” Once you’ve gotten through your automated testing and you’ve made all of the corrections, it’s time to put yourself in the users’ shoes. Learn to use a screen reader. Learn to use several screen readers. I recommend starting with NVDA.

It’s a relatively low learning curve, and it’s free. As we mentioned, there are different APIs for every operating system, so you’ll need to test in a lot of different environments. But there’s a lot of testing, there’s a lot that can be accomplished even with just one screen reader. NVDA is a relatively easy way to start. NVDA works well with Firefox. A lot of people are more comfortable starting with VoiceOver for iOS. I found that to be a kind of painful experience myself, but other people tell me it’s the easiest way to go. Last I heard, JAWS was the most popular reading system, excuse me, the most popular assistive technology.

So it’s important to test with JAWS too. I would test with at least one reading system in every browser that your users will use. Then, don’t just read through top to bottom. Try all of the navigation options. List all of the headings. Go through image to image, table to table. Try caret browsing. Then try all of the navigation options that each assistive technology offers. You’ll wonder how it is that your non-sighted readers actually read books, and then you’ll wonder why some of these navigation options aren’t available in every browser, because they make the reading experience so much better.

It’s a combination of, these tools are great for everybody, and my goodness, how do these people who are so wonderful at the jobs they do function from day to day. It’s a combination of awe at how amazing these tools are, and how amazing these people are. Of course, ask people with disabilities if this meets their standards. Last but not least, make changes. If your content doesn’t meet the tests of these tools, and you aren’t making changes, then there’s really no point in testing. This might be the hardest part of building a born-accessible workflow. There are going to be a lot of people in your organization who resist this idea.

Building a born-accessible culture, and there we have a hila cell culture in the picture, can be difficult. Convincing people that accessibility matters may be an uphill battle. But I recommend that you not be deterred. Building the business case for born-accessible is getting a little bit easier, because more people are relying on the tools that accessibility offers. I recommend stressing the business case over and over again. Accessibility benefits everyone. We often call this the curb cut argument. Curb cuts, we know, were originally made for wheelchairs. I think we’ve all used them for our luggage, our baby strollers, our shopping carts. This happens with so many aspects of accessibility. In the EPUB world, we talk about adjusting the font size. This is pretty much status quo in EPUB readers.

I adjust the font size when I’m reading in a dimly lit room and I don’t want to put on my glasses. I guess you’d call that a situational disability. But people just like to adjust the font size, or even adjust the font because somebody prefers to read in Baskerville than in the default font that whatever reading system chose for them. If I had adjusted the fonts on these slides, perhaps you would have been able to see all of my information. So we’re benefiting everybody if we make our content accessible. Situational disabilities and the aging population increasing the number of those who require accessible content.

Situational disabilities can be anything from a noisy room requiring captioning, to reading in a dark room. People really like audiobooks because they listen to them in the car or while jogging. There are so many people who would use audiobooks if we made them more available. If you look at the numbers for audiobooks, they might even be surpassing e-books, but I just made up that statistic. My recommendation is to create accessibility wherever you can. Do it anyway. Sneak accessibility in where possible. That’s how I got started at Wiley.

I was responsible for the EPUB workflow going back to 2008. Back in 2008, EPUB was a little bit different than it is now. We were a little bit stuck in the HTML4 era. It wasn’t necessarily so accessible, but probably better than the PDFs we were creating. But as I learned more about accessibility, and as EPUB developed, my EPUB template got more and more accessible. I would I would say that Wiley’s EPUBs were more accessible or ahead in accessibility than everything else that Wiley was creating.

Of course, demonstrate that accessibility isn’t hurting anything. There’s a big myth out there that accessibility and design can’t work together. I actually the opposite to be the case. If I create a content structure that’s not accessible, a bunch of P’s and divs, sometimes called P soup, it’s really hard to create good CSS, because I can’t find where anything is. Creating selectors in CSS is really hard if everything has the same name.

Demonstrate that including accessibility from the outside improves your workflow. I think I just made that argument. It’s much easier to work with well-structured content. It’s much easier for everybody if they know what they’re looking at. Talk to the web developers in your company, especially if you’re in an education company. There’s somebody who had to retrofit something to make it accessible. It costs millions of dollars. It’s a pain. It’s difficult, and nobody enjoys doing it. If you’re working backwards, it hurts. Just one example from Wiley’s workflow, back when Flash was the option for video, we created lots of video for our educational content in Flash. Millions of dollars later, all of that video is in HTML5.

Obviously, we had to do that for browser support reasons, but it also is a lot more accessible. Now that animation is the thing, when people started to work in Flash, a lot of people cringed and said, “You really can’t do that.” While we’re at it, maybe we can make those animations a little accessible at least. I don’t know what a little accessible means, but at least somebody’s thinking about it. Here’s an incomplete list of helpful resources. You’ll notice that it’s not even alphabetical. It’s just a random list of thoughts. One of those items is the BISG Quick Start Guide to Accessibility.

That document includes about 20 pages of accessibility resources. If you want to dive in further, take a look at that. They’re categorized from things like details about how to implement ARIA, WCAG compliance, accessibility checkers, color contrast checkers. By the way, color contrast is something that’s so easy to implement, and so few people do. Even this slide template, which is Wiley’s slide template, I had to change because the color contrast wasn’t correct. So there’s still a far way to go at Wiley, but it’s a really easy place to start, though. Take a look at some of these documents. Start getting involved. Take a look at what you can do. It’s very easy to start small, and then work your way up. Then, I’ll be happy to take questions, and feel free to get in touch with me.

– [Audience Member] Hi, Tzviya. I have a non-techie question. You talked about the importance of making the business case of doing this. Apparently at Wiley, the business decisions are already taken, and you were given the job of realizing it. Is this from looking, sitting here in Europe and looking over the pond to the US, is this a common pattern that the big publishers are doing this move now, or are you in front of the herd or unique? Do you have other colleagues elsewhere who have tried this and failed in the business sense to make this move? What’s the general trend? I guess that’s what I’m asking.

– First of all, at Wiley, we’ve just gotten started on this. The business case is not completely made. I’ve been campaigning to get somebody who’s job it is to work on accessibility, because I have other jobs also. I can make a content model that’s accessible, but when people start doing things like adding interactive elements, I lose control of the baseline model. I’m hoping that once my content actually reaches the real world it will still be accessible.

But we’re making progress. In the rest of the publishing world, it’s still a little bit of a mixture. In the education space, publishers, I think, are finally recognizing that this is not optional, in part because there have been several lawsuits. There was a large lawsuit against EdX, which is a developer of massive online open courses, or MOOCs, and they were sued as a learning management system for not being compliant as a place of public accommodation, which is the language used in the Americans with Disabilities Act. That scared a lot of publishers. With trade publishers, I don’t think that– I think there’s a long way to go. I’ve heard a lot of resistance. The business case there is more, I think what will sell them more is making sure that they realize that there’s money to be made from this, not the threat of the lawsuit.

– [Olav] Hi, my name is Olav. I’m from the Norwegian Library of Talking Books and Braille. You just said that you’re moving away from an XML based workflow. Does that mean that you’re less strict? Do you feel like well-formed HTML still has a role to play for accessibility content?

– I’m sorry, I heard just the beginning of your question.

– [Olav] You said that you’re moving away from and XML workflow at Wiley. Does that also mean that you’re less strict? Do you feel like well-formed HTML still has a role to play in accessible content?

– Yes. Actually, one of the things I mentioned is that you can’t validate HTML and call it well-formed HTML unless you write something yourself. We have written something ourselves because I think when you’re running an operation that large and you need to ensure that everything adheres to something specific, it’s important to. If you’re running something smaller, just writing your own book, perhaps you can judge for yourself whether it’s well formed. Also, at this point, we’re in a transitional state. Nobody will see this HTML for a few years.

– [Olav] Thank you.

– [Nickel] Nickel Farson, a publisher from South Africa. Thank you very much. I much confess at times I wondered whether I’m listening to a Latin or a Greek lecturer. But I understand it’s a way in which one grows into all the issues. Thank you very much for taking the lead in all of this. My question concerns image descriptions, which I’m also very interested in, because I see it as quite a challenge. What do you think is the future for 3D printing in this, especially in the education environment? I understand the user has to have a 3D printer, obviously. Do you see yourself providing software that will activate a 3D printer? To me it seems a wonderful technology that would enable not only printing papers, but students and learners generally. Do you see yourself moving into such a direction at all? Thank you.

– I think that’s an excellent question. It’s not something I’ve heard others at Wiley speak about, moving into the area of 3D printing. I have heard other publishers talk about moving in that direction. I think it’s something that my colleagues at Wiley, especially in the education area, would have to assess, reassess, once they look at the state of the market. I’ve been focusing on the journals workflow recently.

One of the things I should have mentioned is that, I mentioned that we have one content model for everything, I think. We work on one content model for journals, books, digital products. Because journals are the highest revenue earner, we tend to focus on journals first, then move into other areas. In the past year, I’ve been focused on what happens in journals.

I would think that journals would be a great area to start with something like 3D printing. But the demand for accessible content, or the voiced demand, I should say, for accessible content generally comes in the education area, not in the journals area. It’s something I would bring back to the education group at Wiley, to ask where they are focused in image descriptions and things like 3D printing. I have heard other publishers demand, or be interested in 3D printing for image descriptions.

When the Digital Publishing Interest Group worked with the ARIA Working Group on replacing aria-describedat, one of the requirements we had was that something like a link to a file that explained how to do a 3D printout was a necessary requirement that could not be overlooked. When aria-details becomes a reality with ARIA 1.1, hopefully that will be available. We’ll see about implementation.

– [Nickel] Thank you.

– [Audience Member] What do you see as the advantage of moving from XML to HTML?

– A very short answer? It’s a lighter-weight model, and eventually we’ll be able to write in the same format that our customers see. Because even if you’re working in XML there has to be a transition at some point so that your customers can view an HTML. I’d be happy to talk about this in more detail, because this has been something I’ve been wanting to do for a long time. But I think that I’m supposed to wrap up now. Thank you.

– Thank you very much.

– Thank you.