DITA and accessibility (podcast)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 106 of The Content Strategy Experts podcast, Gretyl Kinsey and Bob Johnson of Intuitive talk about accessibility and the Darwin Information Typing Architecture
“If you’re doing it right, accessibility doesn’t look any different than what you’re doing day to day. You’re just adding accessibility considerations when you author your content.”
– Bob Johnson
Related posts:
Twitter handles:
Transcript:
Gretyl Kinsey: Welcome to The Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about accessibility and the Darwin Information Typing Architecture with special guest Bob Johnson of Intuitive. Hello and welcome everyone. I’m Gretyl Kinsey.
Bob Johnson: And I’m Bob Johnson.
GK: And I am so happy that you are a guest on our podcast today. So, would you just start off by telling us a little bit about yourself and your experience with DITA and accessibility?
BJ: Sure. I actually have routes in component content management that go back before DITA. I worked for a web CMS vendor that published a web CMS that was component based. And we implemented Author-it, which is a component based CMS and authoring tool primarily for technical content. We eventually moved to a DITA publish, which solved some problems for us. And since then, I’ve worked with a number of companies, both on the authoring side and the publishing side. I’ve managed CCMS acquisitions, I’ve managed DITA transitions for companies in the medical device sphere, in software, and in medical reference conThe web CMS vendor is also where I got my experience with accessibility. We wanted to sell to government customers and so we needed to be able to make section 508 compliance statements. And so, I had to study up. Later on, I worked for a company that had been acquired by Oracle. Oracle takes a rather different approach to accessibility than a lot of companies. Where other companies centralize their accessibility practice, Oracle makes each business unit responsible. And so, I took the responsibility for helping this acquisition implement accessibility in its content. When I went looking for documentation about accessibility and DITA , I didn’t find anything.
BJ: So, I sat down with the web content accessibility guidelines and developed a matrix to indicate which guidelines applied to techcomm, which one applied to authoring, which one supplied to publishing. And they built a mitigation strategy based on that. I later shared my experience at DITA North America and have been working since then to share that experience with technical communicators across various markets. You mentioned at one point in our emails, what is accessibility? And that’s a really good question. I’ve never found a legal definition, but what I usually use as a definition is accessibility is the characteristics of a product and its content that allow users with disabilities to access the content or use that product.
GK: That’s great. And from your perspective, based on all of that experience you just described, what does accessibility look like when you are authoring DITA content?
BJ: In all honesty, if you’re doing it right, accessibility doesn’t look any different than what you’re doing day to day. You’re just adding accessibility considerations when you author your content. So, for example, when you add a graphic, you make sure that you add an alt text so that users, for example, on a screen reader can get a description of that graphic. You make sure that your table designs are simple and easily navigated. Designs that look easy to the human eye can be very tricky to navigate on a keyboard, which is what most users on a screen reader will be doing. It also looks like authoring content that’s well structured and very focused so users, for example, with cognitive disabilities, don’t encounter problems or distractions that might make it harder for them to follow the thread of the content and understand it so they can fulfill their tasks.
GK: Yeah. And I know it’s really interesting what you said about images and tables in particular, because I think for a lot of our clients at Scriptorium, that’s one of the areas that when they’re authoring content in DITA, and they become concerned about accessibility or maybe they start to have new regulatory requirements for accessibility, with their content, that tends to be one of the biggest areas they have to start with. And a lot of times when they have legacy content, one of the areas where they haven’t really been addressing accessibility in the past. So, I think that’s a really good starting point that you mentioned.
GK: I want to talk about one other concern that we tend to see a lot, which is when we have something like DITA or structured authoring in general, where your content and your formatting exists separately, then that means there’re going to have to be two maybe different groups thinking about the way accessibility works. So, how can we be proactive in designing accessible content when you’ve got that separation between your content and your formatting?
BJ: The place to start is remembering that there’s more than just visual disabilities when it comes to accessibility. One of the responses I frequently hear when I talk to people about accessibility is, why do we need to do this for a small portion of our audience? And if all you think about is users that are blind, that is a relatively small portion of the audience. But visual disabilities itself is actually larger than just blindness. Visual disabilities also encompasses color blindness. About 8% of North European males and about 5% of North American males are red-green color blind. That’s a substantial portion of any audience. And you have to consider that, particularly when you’re implementing your interface, to make sure that color is not the only signal that something is changing or something has meaning.
BJ: You need to be sure that the form of whatever it is also changes so it indicates that there’s something you need to pay attention to. Similarly, when you’re designing an interface, you need to be concerned with neurological disabilities, and certain rates of flashing are known to induce seizures and you don’t want to flash at those rates. When you’re thinking about authoring, again, you want to think about not just visual disabilities, but physical and cognitive disabilities. People with physical disabilities may be navigating by keyboard similar to users on a screen reader. If they have, for example, carpal tunnel or epicondylitis, which is an inflammation of the epicondyle tendon in the elbow and makes it difficult to navigate by mouse, you may need to use the keyboard in that situation.
BJ: And you want to make sure as the author that you make a table, for example, that’s well defined to navigate. You want to make sure that your text content minimizes distractions for users with cognitive disabilities, like ADD or dyslexia. You want to make sure that it’s well organized, that there are a lot of bullets, that you keep your paragraphs short and tight, you keep your topics short and tight. And you really want to avoid using inline links, because those are distracting for both users on screen readers and users with cognitive disabilities.
GK: That’s a really interesting point about the inline links, because we’ve also seen that pose issues for reuse in DITA as well. But I don’t know that we’ve ever really seen it come up as an accessibility issue, but that is a really great point. And I know we’ve been encouraging a lot of companies that do heavy reuse to get their inline links into something more like a related links list at the end of a topic, rather than sprinkled all throughout. But that’s a really good point too, that it can also really have benefits on the accessibility side to do that.
BJ: Definitely. I have some personal experience with this. I have two children that both have cognitive disabilities, ADD and similar related disabilities. And watching them during the COVID pandemic and having to do their school work remotely and seeing text content that they’ve had to use that has links embedded in the text. They’ve found it easy to get distracted and lose the thread of what they’re working on. And that’s equally important for someone that is using content for a business application, or if they’re a consumer trying to, for example, place an order for a product or a service. You don’t want them to lose that thread and go off and do something else.
GK: Absolutely. I thought it was also really interesting what you said about making sure that your topics are short and focused because that’s another area where a lot of companies have come to us and said “we have legacy content that was written more in kind of a book like format, and we want to get it more modular.” And a lot of times, accessibility is a driving force behind that, especially as they’re going into more online forms of delivery, like Webhelp or HTML or a dynamic portal. So, that is a really interesting point too, of how they can author their topics in a different way that’s better for accessibility. So, that’s all covering the authoring side, but what about on the output transform development side, what can be done with the design and the way that you deliver that content to make it more accessible?
BJ: You need as the publishing designer to make sure that you implement whatever accessibility affordances that your authors design into their content. You also want to make sure you consider some of the color issues that I mentioned earlier, to make sure that those users have the correct signals for content changes, not just around color, but around form as well. You also, if you’ve got any kind of streaming content, streaming audio, streaming video, similar to this podcast, that you also make either a transcript or closed captions available so that users with auditory disabilities can follow along or even access the content. Because obviously, a user with an auditory disability is going to find it very difficult, if not impossible, to listen to this podcast and the transcript is going to make that available to them.
GK: Absolutely. One other question following on from that I wanted to ask is that one thing that we’ve seen sometimes with clients who are trying to take things from their legacy formats into something a little bit more modular is that they tend to have lots and lots of hierarchical nesting. And I wanted to get your perspective on any issues that might cause for accessibility. Because one thing we’ve seen is when you have many, many levels of headings, it can only go so deep in a visual representation before it gets really convoluted and confusing. And I think from an accessibility point of view, a lot of times our advice tends to be to try not to have your nesting and your hierarchy, whether it’s for headings or even list items to go too many levels deep. And I wanted to get your perspective on that as well.
BJ: Now, that’s a good point and both for users with visual disabilities and users with cognitive disabilities. Excessively, deep nesting is really problematic. So, for example, a user on a screen reader, deeply nested content can be very challenging to navigate, especially when you’re navigating by keyboard. So, making a shallow structure is going to be much easier for that user on the screen reader to navigate. A user with ADD or executive function disorder is going to have similar problems navigating an excessively complex structure. It’s difficult for them to keep focus or to focus on their navigation of a very complicated structure.
BJ: So, to make it easier for the users with those disabilities, you really want to focus on making your structure relatively shallow. Three levels deep is about the deepest recommendation for any form of navigation that I have seen by accessibility experts. And by the way, I consider myself an advocate, not an expert. I advocate for implementing accessibility and technical communication content, but I’m not necessarily an expert on accessibility.
GK: Any other final advice or words of wisdom that you have to help people who may be starting to introduce accessible content or address accessibility for the first time?
BJ: One thing is to realize that you don’t necessarily have to do everything at once. Very often, when people look at accessibility, they feel overwhelmed. I usually recommend a three pronged approach to implementing accessibility if you haven’t done it before. Anything that new, anything you doing new starting now, make sure you implement accessibility and follow your accessibility practices. Anything that you touch going forward, whether it’s to implement a new feature or to mitigate a defect, plan for implementing accessibility mitigations as well, as part of that work.
BJ: And then for each period of work, whether it’s a sprint or some other form of work, plan implementation of accessibility mitigations in a section of your content to make that whole section accessible or to implement accessibility in that whole section. Also, work with your leadership to determine what aspects of accessibility you need to implement. It turns out that some accessibility mitigations you implement for certain disabilities might not be good for users with other disabilities. And it’s up to your leadership, your accessibility experts, and your legal team to determine which accessibility mitigations are most important for your organization.
GK: Thank you so much for all of that fantastic information and for joining us on the podcast today.
BJ: Thank you for having me. Glad to join you.
GK: And thank you for listening to The Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.
About the author
