How do you design technical documents for different accessibility needs?

You can't know who will ever use your documentation throughout its lifetime. That is why you need to follow WCAG guidelines from the start, whatever you create for whatever purpose. The nice thing about following standards is that it will make it easier for all users of the documentation, not only those with other accessibility needs.

When it comes to accessibility, there may not be any correlation between accessibility and the audience. It is best to adhere to an established accessibility standard from the get go. WCAG is a good start and you can further tweak by your research regarding any specific accessibility you might need for the document.

I remember that when working in the defence industry, my company was providing radar jamming courses to fighter pilots from a foreign country. Because these pilots were on a course, there was no opportunity to interview them. However, after the pilots read our initial draft manuals, we were informed to reduce the amount of information because either they knew, or, could easily workout the basic setup of the equipment from their own experiences. A case where manuals having to be revised from the normal format, due to the high intelligence of the audience!

This is technical writing 101. Any kind of documentation should follow these principles. From an accessibility point of view, a strong adherence to conciseness and organising content into small chunks are essential.

You do this for any documentation. Period. This is not an accessibility-specific concern. LinkedIn wants me to add additional characters. So I did.

Be sure to watch for and avoid words that have multiple possible meanings. This was a specific concern when I worked with technical documents that were going to be translated and localized, but it's good practice in any kind of professional communication, to improve clarity. Watch also for words that look or sound similar, but mean different things. Words like "prescribe" and "proscribe", for example, have completely opposite meanings, and can be easily misunderstood by some audiences.

Always a good thing to do. Though as covered in other documentation knowing your audience and their requirements/ expectations, is also important. You will always need to write clearly. Concisely may however need tailoring according to the: - type of documentation. - audience of the document. For example, guides for non-technical/ new users, may need to be less concise to provide additional support to the users. Than would be the case for technical users referring to a technical document. Though it is possible develop a writing that meets both requirements at the same time, if needed.

Why are they calling this something you do for making documents more accessible? These are things you do for all types and manner of documentation. Has anyone noticed the number of webpages providing the ability to have the content read to you? That isn't only for those with special accessibility needs. Some people prefer listening. You don't make documents accessible to open them to an additional set of people. You make them accessible because it helps all people.

Knowing your audience (KYA) as suggested and described above is a must. If you add consideration of the adult visual-auditory-kinesthetic (VAK) learning modalities to KYA when designing and producing any technical content, you add a new level of respect and compassion to the presentation of your content for your diverse audience. But if you partner such consideration with following WGAC guidelines, you will nuance the connection of the content to different audience members in ways they have not experienced before.

Knowing your audience (KYA) as suggested and described above is a must. If you add consideration of the adult visual-auditory-kinesthetic (VAK) learning modalities to KYA when designing and producing any technical content, you add a new level of respect and compassion to the presentation of your content for your diverse audience. But if you partner such consideration with following WGAC guidelines, you will nuance the connection of the content to different audience members in ways they have not experienced before.

For example, designing for users with low vision, the recommended practices are: > Ensure high contrast and legible font size > Publish all data on web pages (HTML) > Use a blend of color, shapes, and text > Maintain a linear, logical layout ensuring text flow and visibility at 200% magnification > Keep buttons and alerts contextual Avoid: > Poor color contrast and small fonts > Hiding information in downloadable content > Solely using color to convey information > Dispersed content making users scroll horizontally at 200% magnification > Actions disconnected from their context

Colour type and colour contrast considerations are a major consideration for an technical documentation. As are other visual characteristics of the documentation, e.g. font type face, font size, the what different headings are defined, etc. As, it is important to remember colour blindness, for example, is not the only visual disability your reads may have. So remember to consider the font type, font size, colour, etc., when defining your documentation. For consistency, I recommend defining template(s) using a standard suite of styles, to aid the application of your required standard(s), along with ensuring a consistent branding of your documentation.

Part 1 To me, the very approach of this document is wrong. Doesn't it aim at collecting expert knowledge that would be valid in any situation? "Truth", "relevance of what you write" is permanently changing, depending on the use context. One way to know if your technical document is of any use at all would be, of course (and beyond doubt) - to test it. However, way ahead of that, you need to assess your readers' information needs. This is before you start thinking of placing your hands above your keyboard to press the first key. There is no way to automate technical documentation, as far as it is a human process aimed at compensating "built-in" incomplete engineering.

I strongly suggest testing the accessibility of documents with many available tools. For HTML documents try to navigate with a screen reader. You can also use WAVE Web Accessibility Evaluation Tools to find a testing solution for your document type.

One of the difficulties that I have faced over the years is getting to the stage where you are face-to-face with the person you are designing documentation for. In some industries engineers have no option but to see you, their salary and yours depended on these meetings. However, in some industries such as defence, there was a real reluctance by some of the senior engineers (not all the senior engineers), to meet with you. This was because they were researching topics whose outcomes could change in short periods of time. If they provided information, that could change in a matter of weeks, then that research might reflect on their careers in a few years time. Consequently, and deliberately, I had to arrive unexpectantly on these people.

In my experience , the best way to deliver the query is to highlight what has to be asked by the respondents in a more precise and accurate manner than secondly explaining what they haven’t previously provided.