Rendering and Accessibility

We've received multiple questions about rendering and accessibility. TechDoc attempts to be as accessible as reasonably possible but it needs your help as well. Accessibility is all about providing extra information to assist people with disabilities to understand what you trying to convey whether the person is visually impaired (blind, color-blind, needs large magnification, etc.) or physically impaired (unable to use a mouse or keyboard effectively, etc.)

TechDoc addresses the user interface but it cannot address the user content – the documents (Word, Excel, PDF, etc.) that you put into TechDoc. In order for your documents to be 508-compliant, you must create them that way. Here's just a couple of examples of why TechDoc can't automate this for creators. Note that the examples reference Word, but they apply to any application that you use to create user content...
  • Every graphic you place in a Word document is supposed to have alt text on it for the visually impaired. If the you insert a picture into your document, TechDoc has no way of knowing what to set the alt text to so that the reader would know what the picture is meant to show. And the caption isn't about what's in it but more about why you included it. For example, think of a launch photo. It may not be about the rocket per se. The appropriate alt text for the photo might be "This picture shows the rescue vehicles parked at a safe distance from the pad during the Falcon Heavy's maiden launch on February 6, 2018".
  • When you create a table in Word, depending on the styling of your table, Word may not be able to determine if or where the column headings are (none, horizontal, vertical, or both). You may have to make changes manually to the table so that Word can tell. If Word can't tell your intent, TechDoc can't either...
  • If you use any fancy text placement such as text boxes, comments, pictures or graphics with captions placed on the page and out of the text flow, etc., Word may not be able to determine the proper reading order of the text on the page. In this case, you have to manually do things to let Word know what the reading flow is.
  • You can choose foreground and background colors that cause text to have too little contrast between them and the background, which is considered to be a 508 violation. Again, that takes the user deciding how best to change the colors to avoid the problem and make sure that people with vision can still see everything you intended for them to see too. Darkening the background might visually hide arrows you have pointing from the text to objects on the diagram, etc.
  • Lot's more issues that require you, the content creator, to make choices on how to address accessibility problems...

The first time our team did 508-compliance checking on the TechDoc manuals, it took days and lots of tough decisions for us to resolve all of our issues. There is definitely no way to automate those decisions for the content creator.

As for render, every reasonable attempt is made to maintain the accessibility from the source documents to the rendered PDFs that are generated by the render process. However, it is your responsibility to place an accessible document into TechDoc in the first place.

Product Type: