In episode 119 of The Content Strategy Experts podcast, Elizabeth Patterson and Bob Johnson of Tahzoo discuss accessibility when authoring DITA content.

“By its very nature, DITA being strongly structured facilitates more accessible content.”

– Bob Johnson

Related links:

• DITA and accessibility
  
• WCAG guidelines
  

Twitter handles: 

• @PattersonScript
  

Transcript:

Elizabeth Patterson:                   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’ll talk with Bob Johnson of Tahzoo about authoring for accessibility in DITA. Hi, I’m Elizabeth Patterson. Bob, welcome.

Bob Johnson:                    Thank you. Glad to be here.

EP:                   So I think before we dive into our podcast, if you just want to give a brief intro, little bit about who you are, that would be great.

BJ:                    Sure. Currently, I am senior content strategist at Tahzoo. We are a company that specializes in customer experience, user experience, and using structured content to facilitate that. I have been a technical writer for almost 25 years now. I’ve been working with structured content and component content since 2000. I’ve been working with DITA since about 2006. And I’ve been working with accessibility since around 2008. I did some work for Oracle on implementing accessibility in one of the acquisitions about 10 years ago, and began digging into accessibility in DITA. And I’ve presented at a number of conferences and other venues on the subject of implementing accessibility in DITA and why you should implement accessible content.

EP:                   Well, great. Well, we are really looking forward to hearing some of your perspectives today. And we’ve really broken this podcast out into some different sections. But to kind of get things going, how can your designs, so PDF, print books, Web UIs, etc., How can those be made more accessible?

BJ:                    Yeah, that’s a good question. The foundation for whatever your deliverable format is, is the web content accessibility guidelines or WCAG, which is promulgated by the web accessibility initiative of the World Wide Web Consortium. And WCAG outlines what you need to do to make your content accessible. The current version is version 2.0, 2.1, and 2.2, which are cumulative, so 2.1 builds on 2.0. And 2.2 builds on 2.0 and 2.1. The later versions don’t supersede, they simply add more information. The foundation for the web content accessibility guidelines is a set of four principles, using the acronym POUR, P-O-U-R. Content has to be perceivable. You have to be able to get it from the screen into the user’s head. It has to be operable. The user has to be able to jump around, enter data, actually use whatever content is online. It has to be understandable. The user, once it is in their head, has to be able to decipher it and make sense of it.

BJ:                    And then the content must be robust. So if there’s a failure, there’s a fallback, so that the accessible content is still perceivable, operable, understandable to the user. And this is actually not just a backwards compatibility requirement. It’s a forward compatibility requirement. So content has to be compatible with future technologies, not just with current technologies.

EP:                   Right. That makes sense. So I think I want to dive into talking a little bit about structuring DITA content for accessibility. So how does the modular nature of DITA content help make it more accessible?

BJ:                    Well, as we all know, DITA’s a very structured format. And accessibility tools or user assistance tools really rely on that structure, so a screen reader for example, reads what’s called the document object model, which represents the structure of the document, and it uses that to navigate or to help the user navigate through the content. So by its very nature, DITA being strongly structured facilitates more accessible content.

EP:                   What are some challenges for accessibility when it comes to links? How can you optimize your approach for linking and managing related content for accessibility?

BJ:                    Yeah. Links can be troublesome in a couple of ways. One of the more fundamental ways is when the link text is either not very meaningful, or it’s repetitive. So I’m sure we’ve all seen websites that say something like, “Click here for this,” and the click here is the hot text. Screen readers, for example, have the ability to navigate from link to link. And if you’re just going from click here, to click here, to click here, that’s not very meaningful. The user doesn’t know. Where’s that link going to go? So you want to be sure that your link text is meaningful. So you want to know either the title of the resource you’re going to link to, or you want a meaningful text that communicates to the reader where they’re going to go, so they understand if they activate the link where they’re going to go.

BJ:                    The other challenge that links create is if they’re inline. Now I’m sure we all have seen a lot of pages with inline links, and it seems very natural. I mean, we’ve seen inline links from the very beginning of the world wide web. But inline links can be very disruptive for users on screen readers when the screen reader encounters the link. It stops and announces, here’s a link, and then reads out the link and then the target for the link. For a user with a cognitive disability like ADD or executive function, those inline links can be very distracting. So when someone encounters a link and clicks on it, they may lose where they are. And it can be very easy in a browser to lose your way back to where you started.

BJ:                    So it’s good practice to pull your links out of the running text, so they’re no longer inline, and organize them in groups, usually after the text so that the user’s reading flow or narrative flow is not interrupted. And then they can go directly to the links. And this is something I’m challenged on frequently because inline links just seem very natural. And I have to admit it took me a while to come around because it seemed natural to me. And what really changed my mind more than working with other accessibility experts was my own children with their own cognitive disabilities encountering problems caused by inline links. And that was the point where it became very real to me. And so I do have an understanding of why it seems unnatural. But I also have an understanding of why you want to do it.

EP:                   And I know in addition to links, that tables can also be difficult for accessibility sometimes. Is there a way you can structure your tables to make them easier to navigate?

BJ:                    So two things, one, you want to keep your structures standard and you want to keep your structures regular and consistent. And what do I mean by that? You really don’t want to merge cells in your table because it makes navigation inconsistent. When you’re navigating through the table, and if you’re on a screen reader, for example, or if you’re a user with a motor disability, and you need to use the keyboard to navigate rather than the mouse, when you tab into a merged cell, the browser really doesn’t remember where it came from. And so when you tab out of that cell, you can lose context. What typically happens is the browser defaults to the first row or column in that merged cell. And then when you tab out, you go there, which you continue on in that first column or first row, which may not be where you came from.

BJ:                    You also want to be careful because table designs that look meaningful may be difficult to build a mental model. It’s important for people on screen readers particularly to remember that they’re not viewing the table. They’re building a mental model of that table. And you need a very well structured, regularly structured, consistently structured table to help them build that mental model.

EP:                   Okay. That’s great information. So in addition to kind of going off of the tables, I want to talk a little bit about objects and resources that you include in DITA content, and how to make that accessible. So for example, what is needed to make images accessible? Are there any particular challenges around images with text, like callouts?

BJ:                    Well, let’s start with images in general because one of the first things people think about when they start thinking about accessibility is, oh, we need to add alt text to our images, and that’s very accurate, in fact. But alt text needs to be meaningful, so it’s not useful to, for example, repeat the file name as your alt text. You want to have alt text that explains what it is that the image is depicting. So this is a screenshot of the default whiffle jangle dialogue with standard configuration, so that users on a screen reader or other low vision users understand what the image actually is.

BJ:                    If you have a complex image, it is acceptable for the alt text to say, “The image is described in more detail in the running text,” and to indicate if it’s running text before or after the image. When it comes to call outs, we have to remember that low vision users probably are not able to perceive the details within the image, so callouts, you probably want to use a table to index to the call out IDs. But even those in the image are probably not accessible to a low vision user. So you want to be sure that your alt text clarifies that. You have a table that is indexing that callout text to the index numbers in the image.

EP:                   And what about audio and video?

BJ:                    So under the 21st Century Video Accessibility Act, organizations over a certain size, and it’s a surprisingly small size, it’s 50 employees, are required to provide transcriptions or closed captioning for streaming audio and video. What you can do leverage that using your DITA content is to build that transcript from the DITA content customizing a map that actually is attached to your streaming audio or streaming video that describes what is being said in the audio.

EP:                   So I want to take a minute to talk about localization considerations. Are there any interactions or connections between accessibility and localized content?

BJ:                    There are, particularly tying into that principle of being understandable. You want to be sure that the language of your text is called out so that if you’ve got a user on a screen reader, for example, it’s read out in the correct language. So for example, if you have the strings C-H-A-T, you want to specify that my language is US English, so the screen reader pronounces it as chat, as in a small conversation like we’re having right now, as opposed to if it’s in French, it pronounces it in French as the word for a small feline. So making sure that your language is specified in your content, and if you have strings not just … You don’t just specify at the topic level, but if you have strings within the content that are in a different language, you want to be sure that language is specified as well, so the screen reader can read that and call out the content correctly.

EP:                   Great. Well, I think this has been very useful. And I think that is a great place to wrap up, so thank you so much for joining us, Bob.

BJ:                    Thank you for having me. Glad to help.

EP:                   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.

The post Accessibility when authoring DITA content appeared first on Scriptorium.