To produce accessible documents, you have to keep in mind that you are designing for both people who can see your documents and for those who have to listen to a description of your documents. Rather than focusing on making the document look a certain way, you should focus on making sure your content is properly tagged and described, so that adaptive technology can effectively convey the content of your document. You can still utilize visual design, but you should make sure that your content is still understandable without the visual styling.
You should try to avoid using extra spaces, extra tabs, or extra blank lines to create a particular visual appearance. This could cause your authoring tool to generate misleading or extraneous tagging for your document. You can usually achieve the same effect by modifying the Style settings in Word or the CSS on a web page.
Computer applications often handle words as text – strings of individual characters and spaces – and this is why you can often copy and paste words and passages from one application into another. This is also why adaptive technology like screen reading programs can audibly read out text from web browsers and other programs.
Words that are part of a graphic image, however, cannot be read by screen readers. You need to provide some kind of alternative representation of the content and/or function of the image. This could be in the form of a hidden description (known as "alt text"), a description elsewhere in the text of the document, or even a separate document.
Both of the documents in the illustration above contain the same words, but the one on the left has visual cues that help the reader understand the structure of the document and make the content easier to absorb. To make these cues available to users of adaptive technology, we have to tag, or mark up, the parts of the document to identify their function. Semantic markup is tagging that conveys meaning, rather than just controls presentation.
It's a common practice to use visual characteristics such as font face, size, weight, color, and positioning to set things like headings apart from the rest of the text. But these visual cues are generally unavailable to someone listening to the text being read out by a screen reader program. So when creating a web page, Word document, or Google Doc, you should use the authoring application's Heading feature to mark text as headings, rather than applying visual styling directly to text. In Word and Google Docs, you can set the visual styling for each type of heading, so that marking a heading also controls its visual appearance. When creating web pages, the heading styles are often defined by a stylesheet that controls the formatting for some or all of the website, but the styling can be overridden for individual instances in conjunction with using the appropriate heading tag.
Heading tags have numbers that indicate a hierarchical level. Heading 1 is used as the page title, and is used only once per page*. One or more Level 2 headings are used to divide the page into sections. If it's necessary to further divide a section into sub-sections, you would then use Level 3 headings. You should avoid skipping levels.
*HTML allows only one Level 1 heading per document; PDF allows multiple Level 1 headings.
You generally don't have to manually mark paragraphs. Pressing the Enter key when typing into a word processor or web authoring tool tells the program that you want to the end the paragraph, and it will use that to automatically tag the paragraphs.
When making lists, use the application's list-making function. rather than manually inserting a bullet character or number and at the end of each line pressing Enter or placing a line break. This way, the screen reader will announce each list item as an item within a list, rather than as separate paragraphs. It can also tell users how many list items they can expect to hear.
Ideally, you should only create tables to present tabular data. Avoid using tables as a visual positioning tool, i.e., creating a table with invisible lines just to lock objects into a grid. The screen reader will describe each cell as a table cell.
Headings within a table should be marked as table headings, so screen readers can properly describe the contents of table cells.
See the W3C-WAI tutorial on creating accessible tables for detailed information on how to create different types of tables.
The WebAIM Color Contrast Checker lets you enter the color codes for text and background to see if they have sufficient contrast. The standard is a little more lenient for large text – 14 pt (typically 19 pixels)* bold or 18 pt (typically 24 pixels) normal. The ColorZilla extension for Chrome and Firefox lets you identify the codes for a color you hover over in your browser.
*Font size in print is measured in points (about 1/72nd of an inch) while font size for screens is measured in pixels (picture elements – individual dots of light that form the image). Because different monitors have different-sized pixels, there is no firm conversion between points and pixels.
Do not rely on color alone to communicate, as this could make information inaccessible to people with color blindness. You may have to use labels or patterns in addition to color when creating charts or graphs, and provide alternative text when necessary.
Some people reportedly find it bothersome or even distressing to view large areas of red. I have not yet found a formal recommendation to avoid red.
When text is arranged in multiple columns, or is placed in multiple areas of the page, it is possible that the text may not be read out in a logical order. You may need to use accessibility tools, such as those in Acrobat Pro, to check and correct the document's reading order. Or you might be able to rearrange the content to address the problem.
The details of visual formatting and styling are often not conveyed to users of adaptive technology, so you should try to avoid relying on these kinds of design elements to communicate content. If you want to use visual styling to do something like emphasize a word or a passage, make sure the content is still understandable without the styling.
Unfortunately, some of the problems of this nature can be difficult to address due to limitations of the authoring tools and/or shortcomings in adaptive technology applications. Just try to be aware of the potential problems, and do as best as you can to address the most egregious instances.
Users of screen readers may skim through a document by jumping from link to link. You should make the text for each link descriptive. Avoid ambiguous link text like "click here".
Adaptive technology provides capabilities to people with disabilities. Screen reader programs like JAWS and NVDA read out text in web browsers and other programs, using synthesized speech. They also give context to the text by telling users when they are reading out things like headings, items on a list, or data within a table. Another form of technology are refreshable braille displays, which are electro-mechanical devices that convert screen text to braille.
People with impaired vision may be able to read a screen by enlarging the text and images. A well-designed web page is a good format for these users because text can re-wrap to remain on the screen, obviating the need to scroll horizontally.