Webinar transcript: Accessible Publishing Made Easy (July 2016)
This webinar was recorded on 13 July 2016. For more details, see the related post on the Typefi Blog.
CHRIS HAUSLER: It’s 12 noon where I am, and we’re going to get started. It’s Chris Hausler from Typefi, I’m the Business Development Manager.
Also on board we have Chandi Perera, the CEO of Typefi. He’s been with Typefi for over 10 years now. He’s been in the publishing industry for a number of years and was actually CIO of Lonely Planet before moving to Typefi, so he has extensive experience both on the vendor side and the publishing side.
We also have Gabriel Powell on board as well, he’s a Senior Solutions Consultant here at Typefi and also an author who wrote Instant InDesign. He is also an implementation manager who has done a lot of different types of implementations of InDesign and Typefi. He’s a certified trainer for InDesign and really enjoys helping our customers automate their publishing processes.
So we’re going to be going through some slides explaining about Typefi and then Gabriel’s going to do a demo showing how that gets done, and then get into some questions and answers. As a part of the GoToWebinar session session there is a questions tab, so if you have questions along the way feel free to enter those into the questions tab. We’ll either address those as they go along or at the end we will have a question and answer panel where we can answer any of those questions.
Thanks for joining us and have a great one. Turning it over to Chandi.
CHANDI PERERA: Hello everyone, good morning and good afternoon depending on where you are. Welcome to the Typefi webinar on accessible publishing. I’m going to take you through a quick introduction to accessibility, why it’s important, some standards on how to publish accessible content, and then Gabriel is going to take us through some practical examples of publishing accessible content.
Then, as Chris mentioned, we will have a Q&A session so if you do have any questions, as they come up please put them into the questions panel and we will get to them at the end.
So what is accessibility? Accessibility is enabling everyone regardless of disability or special needs to read, write, hear and interact with content. The goal of accessibility is to create an inclusive society for people with visual, auditory, physical and cognitive disabilities, especially in a society like today where access to information is critical.
Especially taken from a publishing point of view, accessibility is best tackled when features for accessibility or requirements for accessibility are considered right at the start of the product development process. So that means you think about what you need to do for accessibility all the way along, even before the authoring stage or the product development stage, and that makes life simpler. I think trying to add accessibility right at the end becomes like a ‘tag on’ process; it’s always going to be much more troublesome, and we’ll show you what we mean by that in a few minutes.
Before we get into the meat of the presentation, I want to share a quote with you. This is Stevie Wonder at the 2016 Grammys. “I just want to say before announcing the winner that we need to make every single thing accessible to every single person with a disability.” That is quite a true statement, and hopefully sets the scene for this webinar.
So what is a disability? It depends on the end user. So there are people with a visual disability, for example blindness, but there’s also low vision, colour blindness, photosensitivity and other visual disabilities. There’s auditory disabilities, for example deafness and hearing impairments. And there are physical disabilities, for example limited movement or restricted movement, and so on.
So quite often, even in publishing, when we are thinking about accessibility we can’t just think about people who are visually impaired. We should also think about all the possible disabilities and, of course, things like cognitive disabilities if that is relevant.
Some individuals may have more than one disability, so when you are designing your product it might not be enough just to design it for somebody who is visually impaired or totally blind. There might be somebody with low vision or colour blindness, or somebody who has perfect vision and perfect auditory capabilities but is movement impaired. It’s important to keep all these things in mind.
Why is accessibility important? Well, almost everyone will be temporarily or permanently impaired at some point in their life. That could be as simple as having your hand or arm in a cast and you can’t do things, or it could be that if you are lucky enough to survive to old age, and there’s a lot of people who do survive to old age right now, they’re going to experience increasing difficulties in functioning, especially in accessing information.
Here’s some stats from the United Nations. There’s about 650 million people, about 10% of the world’s population, live with some form of disability right now. I have been corrected in the previous webinar that in some countries it is significantly higher than that based on census and self-reported data.
About 60% of people who are visually impaired are aged 50 years or older. Considering the majority of participants in this webinar are from Europe or the United States and some from Australia, in developed countries there is an aging population and that’s quite a substantial demographic shift, but also it’s an aging population that is quite affluent, and who have been used to getting information quite regularly in the past.
So there actually is quite a good commercial market for providing accessible information. Overall, the over 50 age group comprises about 20% of the world’s population and it’s currently growing.
That’s a commercial reason why you should make content accessible. But really, more important is that there is an ethical duty for a publisher to make content accessible. If you’re publishing content you should make it as accessible as possible, and if the commercial and ethical doesn’t sway you, for most of you there will be a regulatory reason to make content accessible. There are regulatory and legal requirements.
When you talk about the regulatory requirements, probably something you want to discuss is the UN Convention on the Rights of Persons with Disabilities. It’s a fairly simple convention to read, and if you type that into Google you’ll be able to get the full text of that. But I’d like to focus on Article 9, which actually talks about “to promote the design, development, production and distribution of accessible information and communications technologies and systems at an early stage, so that technologies and systems become accessible at a minimum cost”.
It’s really important to become accessible at a minimum cost. Making your content accessible does not have to be an expensive project that breaks the bank, so to speak. It can be done at a minimum cost and we’re going to show you how to do that, and in some cases most of our customers have done it at cost neutral. So previously where they didn’t have accessible information, after a project they did, and the overall cost increase was nil or the difference in cost of production was nil.
About this UN Convention, there are some countries that have not signed it, they are in grey on this map here. Not many, but there’s a few. There are countries that have signed the convention, and then there are countries that have signed the convention and have a protocol in place to implement it, so that means there’s a legislative framework in implementing that. Then there are countries that have signed the convention and ratified it, that’s a significant chunk. They may not have a protocol in place or they already have a protocol in place, but that’s not tied to the convention. And then there are countries that have ratified the convention and signed it, and have protocols in place.
You can see by that, that most of the world, a significant chunk of the world’s population, have signed the convention and they either have a protocol in place, or ratified and have a protocol in place. It is a big part of the world who is taking action really quite seriously.
There has been some very very recent developments in this space, and that comes in the form of the Marrakesh VIP Treaty. If you’ve been watching the accessibility space in the last few months you’d be very well aware of this. The Marrakesh VIP Treaty is formally known as the Marrakesh Treaty to Facilitate Access to Published Works by Visually Impaired Persons and Persons with Disabilities. Bit of a mouthful, so it’s generally referred to as the Marrakesh VIP Treaty.
Now this is a treaty on copyright, of all possible things, allowing for copyright exceptions to facilitate creation of accessible content or accessible versions of content. So, for example, if a specific chunk of content in only available in non-accessible formats, the Treaty allows for creating an exception to copyright laws, so an accessible version of that can be created by somebody other than the rights holder.
So obviously as publishers and rights holders, we probably don’t want this to happen. You do want to create all the versions of the product yourself, and it is highly encouraged that you create the products yourself.
51 countries signed the Treaty, 20 countries have ratified it, and the 20th country to ratify it was Canada on the 30th of June a few weeks ago. And the Treaty comes into effect three months after that, so it will come into effect on the 30th of September. More or less at the end of summer this Treaty will come into place. At that point if you’re selling to or from one of the ratifying countries, or from any of the signatory countries, there will be a significant impact from this Treaty.
The impact might not be directly on a publisher, but the people who need accessible content would actually be able to get accessible content if they’re from these countries without the option of breaching copyright.
There’s also lots of national legislation. Most of the world has national legislation. I am going to cover some very high level legislation or Acts here. In Europe and the European Union there’s the European Accessibility Act. Within the UK there’s the DDA, the Disability Discrimination Act.
Within the US there’s quite a few Acts or pieces of legislation; the most famous of that is probably Section 508 of the Rehabilitation Act, and the Americans with Disabilities Act, and if you’re in textbook publishing or educational publishing, the Individuals with Disabilities Education Act is also quite important because that talks about how educational content should be made accessible, especially if it’s using Federal money of if it’s purchased using taxpayer funds.
Of course in Australia there’s the Disability Discrimination Act and so on and so on. It’s a very long list and I’m not going to go through the whole lot, but generally most countries have legislation and regulations that require you produce content accessibly if you are producing certain types of content.
So that’s why you should do it, now how should you do it? What makes a document accessible? The primary thing that makes an item of content accessible, regardless of the disability, is coherent and consistent writing. The second most important thing is correct semantic structure or appropriate semantic structure.
This means headings, sub-headings, sections; the content is broken down clearly. Lists are done as lists; rather than paragraphs with little circular glyphs at the side of bulleted lists or numbered lists, you are creating proper lists. Creating tables rather than words or numbers with tabs in between them. Images – it’s very important if you have images that convey information, that you create alternate text or descriptive text about the image so that people with visual impairment can actually know what’s in that image, because obviously they won’t be able to see that.
Very very important, and a lot of people do miss this, is the identification of the language the publication is in. Generally this is important for digital publications, not for print. The reason is that if you open up a website or an EPUB or a DAISY file or a PDF online, what you don’t fill out is the language of the PDF. If a machine tries to read that, the first thing it needs to know is what language it is in. Because a French reader trying to read an English document or an English reader trying to read a French document – it is funny, but if you need that information it’s not very funny. So it is very important to put the language type and other items in there, and we will discuss that in a little bit as well.
Having resizable text is important. Sometimes you can’t get that, especially if it is PDF or print, but generally it is always preferable to provide a format with resizable text next to it. Ideally something like a HTML or EPUB, where a reader with low vision can actually increase the font size so they can read it better – it’s a better format. Obviously there are some documents that you need to see in a layout, but provide a version of that that might not be as high fidelity with resizable text so the readers with low vision can actually also engage.
Also it’s really important to have proper colour contrast. Lots of organisations have branding colours and so on, but when you’re producing documents, it’s always good to do it in something that has strong contrast like black on white. Don’t use a background colour and a foreground colour, or a text colour and a paper colour that’s too close together so there is less contrast, because that does make it hard to read and engage with. And the same thing applies for EPUB designs and so on.
There’s a number of accessible formats that you can implement these ideas on. The first one of these is print. Print is still king. I know, print is dead, long live print, but really, around the world print is still most the most widely published and engaged with format out there.
How do you make print accessible, you might ask? You can’t make it accessible for everybody, but because of the width and breadth of distribution, not having print will actually make the information inaccessible to a lot of people. If you do want to make print more accessible, especially for people with low vision or movement impairment or things like that, there is a very good set of guidelines from the RNIB, the Royal National Institute of Blind People in the UK. There’s a link to that at the end of this presentation.
By the way, the presentation and the video of this presentation will be made available on our website after this and you will all get an email on the links to that. So there will be a link to the RNIB guidelines on clear print.
With this, some summary points here. Always use high contrast colours for text and background so that the two do not merge into each other. Sometimes you might think from a design or aesthetic point of view, having colours that make it look more interesting on the page might be preferable. But really when you need to think about accessibility, you need to think about aesthetics versus would this document having an image in the background make it more readable or less readable.
Those are the types of considerations that should become primary considerations versus the design aesthetics, because there are some really good documents that have some amazing design aesthetics but are also highly accessible, and that should be your target.
Generally it is recommended that printed material is most readable in black and white, and the RNIB recommends to keep your text large, preferably 12 to 18 points depending on the font obviously, there are some fonts that are slightly larger at 12 points and some that are smaller, but definitely around 12 to 18 points is best.
Very important, avoid complicated or decorative fonts, things that are cursive fonts, or fonts that are hard to read. They might again provide that aesthetic element that you like, but really when you’re trying to express information or communication information, keep the font simple and that does make it easier to read and understand.
Finally, they do recommend you use matte or non-glossy finish to cut down on glare, because if you do have a glossy finish and you have a visual impairment, even a little bit of glare can make it quite difficult to read the document.
HTML is the other most-used format used in the world today outside print. HTML actually does have some very good web accessibility standards. The leading standard or the most adopted and popular standard is the Web Content Accessibility Guidelines version 2.0. This is provided by W3C, the World Wide Web Consortium, and it provides three levels of compliance, Level A, AA and AAA.
Also, WCAG 2.0 is referred to in lots of legislation around the world. Many countries actually refer to this standard in legislation saying if you want to be accessible, this is what you need to do. They might refer to the W3C standard itself, or they might take the concepts within that and embed that in the legislation. This is a really good reference on how to make content accessible, and there is lots of material online on how to do that. If you’d like to talk to us, please reach out and we can also help you.
Having said this, getting to level A should be relatively straightforward. There isn’t a lot to get to Level A; it’s the minimum criteria. If you do a website there’s plenty of checkers online where it will check your website or check your content to make sure it’s Level A compliant, or AA or AAA compliant. Generally, getting to AAA is quite difficult and does require you to think about your content differently, but getting to A should be relatively simple for almost all of you, and getting to AA should be relatively straightforward for most of you. Again, feel free to reach out to us if you do need any help getting up to these.
The third format I want to talk about is DAISY. DAISY stands for Digital Accessible Information System. This is somewhat of a legacy format today. It’s a digital format, a talking book format. It is developed and maintained by the DAISY Consortium, it is standardised to ANSI/NISO Z39.86, and very importantly it does not preserve layout. But it is still very very widely used.
It uses these assistive devices. There’s some pictures of that, there’s lots of these around the world these days, and what you do is you load your data file into that and it reads it out to you. So if you’re in Australia you get an Australian accent; if you’re in the US you get an American accent; if you’re in the UK you get a British accent. It is quite familiar and quite easy to use, big buttons and so on.
This is DAISY version 3. Really, what we’re talking about is DAISY 1, 2 and 3, but version 3 really is the most popular now. But there’s DAISY version 4, and DAISY number 4 is the same as EPUB version 3. So there will not really be a DAISY version 4 and DAISY version 5.
DAISY and EPUB came together when EPUB 3 came around, so it is the same standard. So if you do all the thought of putting descriptive text on images and all of that when you’re creating an EPUB file, then you are actually creating a DAISY 4 file, and you can have the same features you have in a DAISY file in an EPUB 3 file.
The benefit here is that if you do create EPUB 3, not only are you meeting the requirements of DAISY readers that can read this, but you are also meeting the requirements for distributing this file through the iBooks Store or Amazon or any of the other commercial channels. Also, where you traditionally might have had to create just a DAISY file, now you can create an EPUB file that might meet both requirements.
It is really important to note here that the number of devices that are DAISY 4 compliant is not as heavy as the number of devices that are DAISY 3 compliant, so there’s a lot of people who have DAISY 3 readers who don’t have DAISY 4 readers or EPUB readers, so it is recommended that if you can make it work, you create a DAISY file as well as an EPUB file.
It is also important to note that many EPUB readers lack accessibility features so if, for example, you have an EPUB reader that doesn’t have a text to voice capability, it doesn’t really help. It might read an EPUB 3 file, but it definitely doesn’t have the accessibility features that might help like a read text out loud function.
Finally I want to talk about a format called PDF/UA, or PDF Universal Accessibility. It’s an ISO Standard, and it’s very much about making a PDF that is screen readable. Again we will give you some examples of that in a little bit. The big difference between a normal PDF and a PDF/UA document, is that a PDF/UA document contains extra metadata to help a screen reader, and help machine navigation and machine readability.
So it has information in the document that talks about document structure, how to read it, if it’s a multi-column document or if it has boxes or tables; it has all that information about how the screen reader should be navigating through the document to read out loud.
The reason you might want to do a PDF/UA output for your accessibility is if the layout of the document actually conveys information. For example, there might be some publications where the text is not the only information that’s conveyed, but how it’s presented on the page is also relevant.
Obviously that’s not ideal for somebody who is visually impaired, but for somebody who is movement impaired for example, they can still read the document, they can still see it, but having a screen reader means the screen reader will keep pace and flip the pages and go along. The person doesn’t have to do any of that, but they can still read the document in context or in layout. Again, you do need to have things like alternative text for graphics and so on, so it is easy to follow.
The biggest benefit that I mentioned is that it preserves the layout, while things like DAISY or EPUB may not preserve the layout as intended in the original.
Wrapping all of this together, there’s a number of standards that cover accessibility. The first or one of the very earliest standards is the Web Content Accessibility Guidelines version 1 from 1999. There’s also Section 508, I mentioned that a few times. It’s kind of a legislative framework as well as a set of de facto standards on accessibility. There’s WCAG 2.0 which came around in 2008, there’s PDF/UA which I mentioned from 2014, there’s large print and clear print guidelines, there a DAISY standard, and an EPUB standard. So there’s a lot of standards and guidance available to you on how to publish accessible content.
So when you’re doing that, how do you go about implementing accessibility? The very important item here is first you need to decide on a realistic target. You can start off by saying I’m going to go for AAA out of the box – yes, go for it, that’s great! But generally take it in baby steps, I think. I assume if you work for a publisher there’s a day job, so you have to keep the publishing operation running. You can actually do enough accessibility still, without having to get to AAA.
Also one single format generally will not be enough to meet accessibility needs. For example, if layout is important you should do perhaps PDF/UA, but you should then also provide a DAISY file or an HTML file or an EPUB file. Without the layout you might only get 80 percent of the information, but 80 percent of the information is better than zero percent of the information. That is a piece of feedback I’ve gotten almost constantly, but definitely in one case, where somebody came and said, “Look, some accessibility is better than no accessibility.” So if you think you can only go 70 percent of the way, go 70 percent of the way, because that is still a benefit.
Consider printing as many output types as possible at the minimum cost. As in, don’t try and break the bank, but if you can afford to create both a PDF format and a DAISY format, then create both of them, because there are people who can engage with DAISY, there’s people who can engage with PDF. By providing more output formats, the better the access to your information will be.
These are some of the references – WCAG references, content accessibility guidelines, clear print from RNIB, the World Report which Gabriel will touch on in a minute, and the Marrakesh VIP Treaty. Again, if you do need any information please feel free to ask.
At this point I’m going to hand over to Gabriel to show us some practical examples of accessible documents.
GABRIEL POWELL: Thanks Chandi. We have a great showing today, that’s awesome. I’m glad to see such a great turnout.
You know, Typefi has helped numerous organisations around the world produce accessible publications with minimal effort. For example, the World Health Organization in Geneva used Typefi to automatically produce both their World Health Report and the World Disability Report in multiple accessible formats. I have here an example of that.
So here is the World Health Report. It was published in multiple languages and for each language we have four formats. We have an accessible PDF, we have here an EPUB file that targets generic e-book readers, and another e-book file that can target Kindle devices so that you get the best reading experience on whatever device you are reading that on. Then we also have a DAISY format. It is a zip file and inside it we have the various parts of that DAISY file. I’m going to introduce you to each of these formats.
Here we have the World Health Report – this was the PDF that was generated – and then we also have here the World Report on Disability. I’m just going to talk about what makes this PDF document accessible.
One of the important things is that the text is searchable, so I should be able to search for a particular word and find it throughout the document. You don’t want to place your text within images, for example; that would make it not accessible.
Furthermore, the PDF has metadata so if I go to the properties of this PDF we can see that the basic metadata has been entered and, of course, the language has been specified. In addition, the TOC links – that is, a table of contents – needs to be clickable, so we have clickable bookmarks that correspond to those links.
Hyperlinks must be clickable. So there are various references in the document and they are clickable. Here is a reference to a bibliographic reference, and it takes me right to that. If I highlight a URL that’s an external link, that will take me to a website.
In addition, you want the document to have an underlying semantic structure, and that is done using tags. Tags identify the structure of the document and all of the parts of the document. So, for example, if I click this tag over here on the left, I’m taken to its corresponding text on the page. This tag structure is what is read aloud by a screen reader. Therefore, it’s really important to have this tag structure because the screen reader doesn’t actually read what you see on the page.
With that said, we also have alternative text. This figure needs to have an alternative text description so that it can be read aloud and the reader can understand or the listener can understand what that figure is. That alternative text is hidden behind the scenes into the tag, and here it is, the alternative text. This would be read aloud to a screen reader.
Furthermore, tables have also been correctly tagged. So if I were to select some of this text, I can find the tag from that selection and show you that this table has been tagged as a table so that a screen reader can easily move through that table and read out every piece of text and in the correct order.
So those are just the most important accessible features for PDF; that’s what makes a PDF accessible.
Let’s take a look at the e-book. The e-book is also searchable. I could enter a word into this search box and it would find it. We have a clickable table of contents, and as Chandi mentioned we have resizable text. This is important for accessibility so that anyone can read the page comfortably.
So those are some EPUB accessible features. By its very nature – EPUB being based on HTML – it is more or less accessible out of the box, but you can always add more accessibility features to it to give the reader an even richer reading or listening experience.
Then of course we have DAISY; the DAISY file being a digital talking book. I have a reader here that will read a DAISY book out loud on my computer, although most DAISY book files are read aloud on a device. I’ll open up this file – so the device would have already found it and opened it. In any case it’s being read aloud at the moment and, as you can see, every time a blue word is highlighted that’s being read aloud. You may not hear it…
DAISY READER: …one point one, universal health coverage takes a broad…
GABRIEL POWELL: …but that’s how that would work. Now that’s being read aloud.
So you’ve seen accessible PDF and EPUB that’s accessible, and a DAISY file. So you might wonder how are these outputs generated? Next I’m going to introduce you to a project that we put together for Standards Australia, and I’m going to show you the steps that they used to publish a wayfinding standard in an accessible format both for PDF and DAISY.
This is the original Word file and this is what they author. They export this Word file to an XML file. I’ll just quickly show you that XML file. It’s highly structured and it has tags to indicate what everything is – paragraphs, lists, and even tables.
So that’s a structured XML file, and what I’m going to do is run a Typefi workflow with this XML file to create the output for PDF. So I’ll go ahead and do that. I’m going to open up the Typefi server and I’m going to point out two workflows as indicated by this space rocket icon.
This is a workflow. We have one for generating PDF and another for generating DAISY. I’m going to show you that a workflow is made up of multiple actions. So this has multiple steps from converting the XML file, to removing conditionalised content to prevent it from appearing in the PDF file.
So there might be EPUB content that I don’t want to appear in the PDF. With Typefi I can create a single-source Word document that has all the content for both formats – PDF and EPUB or DAISY – and then I can add conditions or apply conditions to that content to make EPUB-only content or PDF-only content. This condition can strip out the content that shouldn’t appear for any given output. That’s going to create an InDesign document and finally export the PDF.
So how does that work? When I want to produce output, I’m just going to select the desired workflow and run it. I’m going to be asked for an import XML file, so I’m going to select that same XML file we were just looking at and click ‘Run’. That’s going to step through the actions in that workflow, including creating an Adobe InDesign document.
I have an InDesign template that I’ve created, and this XML document is now going to be placed within that, and Typefi is going to use InDesign to generate the pages very quickly. This full document is over 100 pages, and on the Typefi server it takes just under two minutes to produce.
For this particular demonstration I’ve removed a few pages just to make it go a little faster, but here you can see Typefi is generating those pages. It is applying the correct formatting to the pages, it creates the table of contents, generates the PDF now, and that PDF is being made accessible, so all the accessibility features that are required are being built right into that PDF.
The job is completed. Let me show you. When you’re ready you can collect your output. I have the final document here; I’ll go ahead and open up that PDF and this is what it looks like. So it has all the same features of that other document I was showing you a moment ago to make it accessible, and furthermore if I were to run the DAISY workflow that would produce a DAISY file and again I could open this and begin reading it.
DAISY READER: Opening book. M E zero sixty four. Closing book.
GABRIEL POWELL: So it’s quite amazing to know that you can start with a Word document, export an XML file, and have two output formats in just minutes. That’s quite amazing!
Next I’m going to show you what it would look like if you didn’t have Typefi. Obviously if you don’t have an automated production system like Typefi, you’re going to have to manually produce the file, so in this case we would use Adobe InDesign to manually produce the file.
It really is just a flat file. Because I’ve created it by hand, I’m also going to have to add all the accessibility features by hand. To draw a comparison, I’m going to open up the same chapter as generated by Typefi, and I’ll show off a couple of the features that Typefi automated in order to make the PDF output accessible.
Here we have a number of tags in this document but they don’t exist in the hand-made document. These tags are applied to the content to identify it, such as a Heading 1, Heading 2 – all of that content is identified in order to tell the screen reader how to read it and in what order to read it. Over here on the left I have a structure panel and you can see as well that this is important for ensuring the reading order of the document.
Furthermore, with Typefi you have what are called anchors. You’ll see there is this box here, and we have an anchor that is pointing to the location that it was referenced in the content. Since this anchor is located here, we can determine the correct reading order of this box, whereas if you were to go to the same page in a manually-generated InDesign file there is no anchor say you’re going to have to manually determine where that box should be located to get the correct reading order.
In addition we have metadata, so the metadata is all automatically placed into the file whenever it is produced by Typefi.
Furthermore, all of the running headers and page numbers have been assigned or tagged as what are called artifacts. An artifact tells the screen reader not to read that content. So that’s important – you wouldn’t want the screen reader to read this running header every time it turns the page, so all of that was automatically assigned during the process of generating this file through Typefi. If you were manually producing this, you would have to go through each running header and identify it as an artifact.
I’ll just go ahead and contrast this a little bit more, and I’ll export to PDF from this file. This is the file that was manually produced, so I’ll go ahead and export it as it is, and I’ll even include a couple of accessibility features – bookmarks, and make it a tagged PDF so we get that structure we saw earlier – and I’ll go ahead and export it. So that’s producing the PDF. It’s almost finished. Great, I’ll go ahead and open it up.
So here’s the PDF exported from that manually-generated file, and you do get a few tags but these tags are not optimal. This was generically tagged and a few things are working, but some tags need to be modified. We had done that automatically through Typefi.
Furthermore, these images will not have alternative text applied to them because I haven’t added alternative text. If I open that up, if I locate the tag, I can then find the image – here it is – and with that figure selected we can find out does it have alternative text? And no, it is missing, so that should have been there. In other words, I would have to manually enter that alternative text.
So they’re just quite a few details that would need to be added to the PDF or the InDesign file to make this accessible and, as you can imagine, if you’re producing a lot of material, manually doing this work is really not very cost effective. It can cost a lot of time and money to do that.
And I would like to pass it off, I think I’m actually just finished if we are going to leave some time for questions. In summary I just want to reemphasise that Typefi can help you build automatic, standards-compliant accessible features right into your publishing workflows and, most importantly, without increasing your composition costs. So I’ll pass it off to Chandi.
CHANDI PERERA: Thank you Gabriel. I think at this point I want to see if you have any questions.
CHRIS HAUSLER: Yes, there are some questions. The first question is kind of a statement as well, and that is Amazon is not in love with EPUB, it’s MOBI.
CHANDI PERERA: They are certainly not in love with EPUB, but fortunately you can convert EPUBs to Kindle files – both formats, KF8 and AZW. Unless you enjoy building them from scratch, which I’m yet to find somebody who does.
CHRIS HAUSLER: (Laughs) Yes! Then another comment is “alt text” at the start of alt text?
CHANDI PERERA: Yes, oh, I should have mentioned that. This is something we actually learned from the World Health Organization. So, they actually decided to do that with their accessible documents, because if the content is being read aloud and you are visually impaired, you don’t know where the normal content stops and where the alt text starts. So it is always good to say ‘alt text starts here’.
So that if you’re having a discussion, say you’ve read a scientific paper or you’ve listened to a scientific paper and you’re having a discussion, if you had the screen-read version you might have heard some extra paragraphs that the other person didn’t. Or they might have had a different interpretation of that chart. So we actually found that it’s a very good idea to put the word “alt text”, and then this is the alt text.
And actually they received very very good feedback when they started doing that, so we actually recommend that if you’re producing output, especially when there’s long descriptions like charts or figures, always put “alt text” there.
CHRIS HAUSLER: Super. Where do we get the alternative text for graphics? We demonstrated that it would…
GABRIEL POWELL: I can answer that. The alternative text for graphics for the wayfinding standard was written right into the Word file. There was a style applied to the alternative text and it was called ‘long description’. And when that Word file was exported to XML, the long description was placed into the correct location within the structure of that document, so then it would automatically appear in the image as alternative text when it’s run through Typefi. There are other ways of doing it, but that is one that was chosen.
CHANDI PERERA: To add to that, the long descriptions or the alternative text always came from the publisher. Quite often the publisher went back to the author or the subject matter experts to write it. In a very few cases they actually hired somebody externally to write it, but generally it’s best to get that done by the author or subject matter expert in the field.
CHRIS HAUSLER: Then, the screen reader says “picture”, so you know there exists alt text. If it sounds like text, then it is actual text, not alt text.
CHANDI PERERA: Some screen readers do, but not every screen reader does that. Again, that was news to us when WHO did some of their testing, which is where having the “alt text” is quite useful.
CHRIS HAUSLER: Is there a US organisation championing accessibility in design in publishing?
CHANDI PERERA: There is quite a few. There are a number of organisations in the US, depending on which segment or sector you’re looking for. If you ping us later, we can provide you with some introductions.
CHRIS HAUSLER: Are you familiar with NIMAC files?
CHANDI PERERA: We are, and we can definitely produce the NIMAC files from the XML or from the Word document going to XML, as long as the content and metadata is there. It does require some extra metadata to be included in the document, so as long as the publisher or the content creation process and editing process includes that content, the NIMAC files can be produced.
CHRIS HAUSLER: All right, a few more questions. How would you produce a Braille document from Typefi?
CHANDI PERERA: Typefi actually doesn’t produce Braille documents. There are different Braille standards around the world, strangely enough, but modern Braille printers have a certain set of file formats they accept, and we can produce that file format from the XML. So what Typefi does, is we convert Word to XML or whatever format to XML – if you have XML you use that already – and then output different formats. And one of those formats or a few of those formats you can output are the Braille-specific printer formats.
CHRIS HAUSLER: OK. Could you make math equations accessible in PDF?
CHANDI PERERA: Million dollar question. It depends on how you want to make it accessible. So there are two approaches. One approach is to use MathML. MathML has the semantic structure of the equation in there, so if the screen reader’s capable of interpreting the MathML, then the screen reader can read that out.
But sometimes the screen readers are not capable of doing that, or the DAISY readers or the assistive devices can’t do that, so an alternate option to that is – and some of our customers do this – they create images of the math and that can be done using a product like Design Science’s MathType or a whole bunch of stuff.
And then the written description of the equation is placed in the alternative text. So, for example, if the equation is E=mc2, then the alternative text says “this is an equation – e equals m c squared”.
It depends on what you’re trying to express and what you’re trying to achieve by doing one approach versus the other, but those are the two most popular approaches we see.
CHRIS HAUSLER: And how do you structure the content?
CHANDI PERERA: If you’re starting from Word it is structured using paragraph styles, character styles, Heading 1, Heading 2, Heading 3, body text, tables, multi-level lists, and so on. If you’re in XML, the structure is very much inferred from that, and the structure is applied again by an editorial or subject matter expert, so an editor, or a technical editor or author, would know what a Heading 1 is and what a sub-section is.
After it’s laid out, if you give it to somebody – imagine reading a document, and you understand the language it’s in but you actually understand none of the material – it’s very difficult to understand the structure of the document. So it’s always better to have the document structured by a subject matter expert.
CHRIS HAUSLER: Just two more questions, really. Must the website have resizable content if the browser can do that for you?
CHANDI PERERA: If the browser can do that, that’s great. Make sure your CSS hasn’t set it up so it’s so restrictive that it can’t resize the content, or if the size is too big it becomes unreadable because it starts overlaying on images. There are plenty of very good guides online. If you go to the WCAG sites, there’s plenty of online guides on how to do this properly.
CHRIS HAUSLER: Just as a reminder, this video and also the slide deck is going to be available on our website, and we’ll let everybody know.
Is Typefi involved in the development of the draft WCAG 2.0 ‘sufficient techniques for EPUB’?
CHANDI PERERA: No, we are not part of the standards committee. We watch that very carefully, but we are not part of the standards committee on that one.
CHRIS HAUSLER: There are many EPUB 3 readers and various accessibility readers. They all interact with various capabilities. How do you handle delivering one EPUB file for all readers?
CHANDI PERERA: That’s a very good question. It depends on your EPUB file. Most of our customers at least create two EPUB files, one for more ‘feature-full’ readers and one for readers that have less features. We have customers who create up to 10 to 20 different types of EPUB files. Because the whole process is automated, you can create as many different variants as you want. You can create ones that are optimised for iPad, and ones that are optimised for KF8 files, that are optimised for Kindle Fire, and AZW files that are optimised for Paperwhite Kindles, and NOOKs, and Digital Editions, and so on.
The challenge is, as a publisher you need to decide how many targets you’re going to do, because if you try and optimise it for each different platform it’s a lot of effort, but it also gives you a great experience on all the different platforms. You then have to deal with file management and all of that, but if you’re willing to put in the effort, you definitely can create individual ones for all the different platforms.
If you’re trying to create one file for everybody, then it has to be pretty close to the lowest common denominator. So, for example, you can’t include audio and video if one file is going to go to everybody, because a Kindle Paperwhite – a very popular reader – can’t deal with audio and video, and so on. So it’s a bit of a balancing act.
CHRIS HAUSLER: And here’s a magic question – how are you producing the XML that creates the InDesign and PDF, instead of going from Word to InDesign to XML?
CHANDI PERERA: No, we are going from Word to XML, and then XML to InDesign, or XML to EPUB, or XML to DAISY. So actually one of Typefi’s core components is the Word to XML conversion.
CHRIS HAUSLER: Okay, hopefully that answers the question. We’ve already talked about math – if there’s more questions related to those specific requirements and things like that, it’s probably for more detailed discussion down the road. If we didn’t answer your questions directly, we can follow up and get those questions answered directly.
We want to thank everybody. I think that’s all the questions – I’ll just see if any new questions have popped up, they keep popping up as people ask questions – yeah, I think we’ve already sort of addressed the math question to a degree that we could in two minutes. There are definitely more questions about that, and that might bring on another webinar on math.
Again, thank you everybody for attending, thanks for the great questions. Again, this will be available online in a day or so. We’ll let everybody know where that will be. Chandi, is there any other conclusions out of this?
CHANDI PERERA: Accessibility is important. It’s commercially viable, it is ethically the right thing to do, and quite often it’s a legal requirement to do it, and you can do it at a relatively very low cost. Actually a very low cost, that is the experience of most of our customers. So I would recommend you look at it – there’s lots of material online, and if you do want some help from us, feel free to reach out to us. Our details should be on your screen – our email address and our website, typefi.com. Reach out to us and we’ll be happy to help you.
CHRIS HAUSLER: Great. Thanks, and have a great day!
Slide Deck (PDF)
Links to resources (external websites)