Writing for Diverse Audiences
Introduction
If your application is used by diverse audiences, you’ll need to write in a way that is easily understood by nonnative English speakers and is easily accessible to users with disabilities. According to the U.S. Government Usability web site, approximately 8 percent of the user population has a disability that impacts the traditional use of a web site. When creating your style guidelines and writing your user interface text, it’s important to remember that the information and textual cues within the user interface should be accessible to these users.
While the number of English speakers in the world is somewhere around 1.8 billion, only a small percentage actually speak English as a first language. In fact, more than 35 million adults in the United States are native speakers of a language other than English (U.S. Census Bureau, 2001). If your application is being translated into languages other than English, you will need to consider the impact of localization and globalization on your text.
This chapter describes the considerations and best practices for creating text that follows standard accessibility and text internationalization guidelines.
Writing Accessible Content
Like web sites, software and web applications are considered accessible if they can be used as effectively by people with disabilities as by those without.1
Generally, people with disabilities are grouped into four major categories:
Visual disability: blindness, limited vision, color-blindness
Hearing disability: hearing loss and deafness
Physical disability: limited movement or fine motor control, difficulty or inability to use a mouse, slow response time
Cognitive disability: cognitive limitations, learning disabilities, distractibility, inability to remember or focus on large amounts of information.
There are many ways the text and textual cues you provide in the user interface can help users with disabilities succeed in using your application. While accessibility guidelines vary from one country to another, most countries use the Web Content Accessibility Guidelines (WCAG) of the World Wide Web Consortium (W3C) as the basis for their accessibility criteria.
Writing Text that Meets WCAG2 Guidelines
Following WCAG2 guidelines as closely as possible will make content accessible to people with a wide range of disabilities and will also make your content easier to read for users in general. Following are the WCAG 2 guidelines you should be aware of when creating your text.
In addition, in the United States, Section 508 of the U.S. Rehabilitation Act mandates that applications maintained by the federal government must be accessible to people with disabilities, and it prohibits federal agencies from buying, developing, maintaining, or using electronic and information technology that is inaccessible to people with disabilities.
The following sections describe how you can create text that meets WCAG 2 guidelines.
Creating Perceivable Content
Perceivable content is content that users can comprehend by relying on the provided visual, textual, or audible cues.
Augmenting Graphics with Text
When graphical elements are used to depict an object or action, the design of the metaphor provides helpful visual cues as to the related object or action. Using concrete metaphors helps users recognize the connection between the graphic and its meaning.
In the following sample, each graphical element is simple and concrete, and the accompanying text clarifies the meaning. This is a good example of how graphics and text should be used together to create perceivable content.
Even the best designed graphics require effort to interpret, and you can’t be sure users understand the intended metaphor. By providing text, such as tooltips or labels describing the graphical element (as in the picture above), you provide the required information and all your users will benefit from the additional input.
In the next sample, the chart is a valuable graphic for showing a visual representation of the information. The application does a good job of providing the information in other ways as well. Users can click on each area of the chart for a definition of each section, and users who cannot use the mouse can see the corresponding information in the table beneath it. This is a good example of how a graphical representation is combined with text to create perceivable content.
Captions and labels are also useful for letting users know when clicking on an element will initiate multimedia that result in playing a video or animation. In this example, clearly labeling the “Play” button ensures that users understand what happens when clicking the button.
Using Assistive Technologies
Assistive technologies also provide a means for helping users interact with your application by using alternative interaction mechanisms. When writing instructions and text strings, it’s important for you to understand how assistive technologies are designed to let your users view, hear, and interact with your content.
Screen Readers
A screen reader is a software application that attempts to recognize and interpret the text and visual elements displayed on the page. The interpreted text is provided to the user via sound (e.g., text-to-speech) or another output device (e.g., Braille Output Reader).
Screen readers are useful for anyone who has difficulties reading the interface text due to visual or other reading impairments, and most operating systems have screen reader assistive technologies built into the system.
You can make it easier for users to see and hear content by following these simple guidelines:
When creating your text, keep in mind that large chunks of text do not read well. Use short, concise sentences and phrasing—which is good practice under any circumstances.
Structure your content to facilitate the good vocalization. Grouping controls either in a frame or with a separator will make it easier for users to understand the page structure and context of your options.
Use consistent text structuring such as punctuation and phrasing.
Use concrete and consistent terminology to describe concepts and actions—for example, Turn on/Turn off, Allow/Deny, Increase/Decrease.
Include units of measure in the main text strings. Screen readers generally move down to the next line of text after an input field. This means that any text appearing after the field will be missed. In the example on the left, users will have no way of knowing that the input field relates to minutes.
Creating Operable Content
Operable content ensures that uses with limited movement are able to interact successfully with your application. At the most basic level, this means avoiding the use of flashing text or text that moves on the page, without a clear way for users to stop the movement.
One common interaction method for users unable to manipulate a mouse or other pointing device is to use keyboard strokes (hotkeys) instead.
Making Functionality Available from the Keyboard
Users who find it difficult to manipulate a mouse or other pointing device may rely on keyboard strokes or other input devices to select options and enter data. These users should be able to move through your pages in two ways:
Using a single keystroke (i.e., tab) or movement to move linearly through the options and fields in the page
Using hotkeys and keyboard strokes to move to specific options and fields
With single keystroke or other touch apparatus used for this purpose, you have little to do other than make sure the cursor moves in the right direction and moves directly from one field to the next, without skipping around the page. When using the keyboard, this movement is generated using the Tab key. For some controls, the arrow keys or other keystrokes may be used in combination with the Tab key. In this example, the user clicks Tab to move through the options and then uses the up and down arrow keys to control the location of the slider.
Hotkeys allow users to move through the pages of your application using the Alt key combined with a keystroke. The hotkey letters appear underlined in the text string, and while this is straightforward, there are some basic guidelines you should follow to make it easier for your users.
Remember that some keys are reserved for standard button actions—A for Apply, C for Cancel, and Enter for OK. Always use these hotkeys consistently throughout your application.
When possible, use key letters that match the related action. Using B for Block or D for Delete makes more sense than using any other letter within the text string.
This is a good example of how hotkeys are matched to the associated actions.
Use key letters that are highly visible. The first letter in a word is easier to find than a letter appearing in the middle of a word. Round letters provide a larger surface for underlining. Letters such as i and l do not provide enough width for the underline to be easily visible. In the following example the l in the second option is the hot key; the underline is difficult to see, especially on higher resolution monitors.
And in this next example, it is difficult to discern which hotkey is underlined for the first checkbox.
Avoid using letters that dip below the text line, such as g and j. The underline is difficult to discern from the dip of the letter. In the following example, the first hotkey is the letter g, and the underline is barely visible.
Links navigating to another page or opening a new page should be clearly written, visible, and easily accessible. The links in the page are clearly written, letting the user know the actions to expect.
Creating Understandable Content
Hopefully, your text is understandable not just for users with special needs, but for all your users. Here are some simple guidelines that will help you structure your content to facilitate reading and create text that is more easily understood by people who may have limited reading or comprehension problems in particular, and by all your users.
Use concise, common words. Use a simpler word where one exists.
Group related controls together in a frame or by using separators.
Use consistent text structuring such as punctuation and phrasing.
Use uniform spacing and follow indentation rules so that users can easily see which controls have dependencies and which do not.
Use the same words for like concepts.
Use your text-writing guidelines consistently across pages and features.
Creating Robust Content
Remember that users are interacting with your content on a variety of platforms and devices. The information you provide and the text cues in your pages should provide a positive, easy to understand experience across platforms and devices.
Write commands, instructions, and labels that are appropriate for different input mechanisms and interfaces (i.e., touch, speech recognition, and mouse-driven applications). Is the user clicking or selecting? Swiping or tapping? Unless you are sure how users are interacting with your application, use commands that are generic, such as “Select” or “Choose.”
Remember that different devices have varying screen sizes and that users may change the font size and resolution for their specific visual needs. Keep text and labels to a minimum to avoid the need to scroll on different-sized screens.
Writing for International Audiences
Whether your application is sold in a box or downloaded from the Internet, you will need to consider ways to make your content easy to read and understand for users who are not native English speakers. The overall term to describe this process is internationalization. Creating an internationalized product also includes localization and globalization processes.
Internationalization is the process of designing an application so that it can be adapted for potential use anywhere in the world. (Microsoft refers to this as “world-ready.”)
Localization is the process of adapting the application for a specific location or region other than the one for which the application was originally developed. This includes translating the text strings and messages within the application as well as modifying other textual cues on the page.
Globalization is the process of creating an application that is suitable across cultures and regions.
You can think of it this way: Internationalization makes sure users can select the date format for their locale, and localization assures the names of the days and months are translated correctly, while globalization assures that the calendar adheres to cultural preferences such as displaying the appropriate holidays for that locale on the calendar.
The infrastructure required for internationalization is built into the software design by the developers. However, providing the right language and cultural references within the application generally falls on the writer.
Considerations for Internationalization
Internationalization implies that users can view the application in the native language of their locale and that the application will display and accept input in the formats appropriate to that locale. In particular, displays and input should be formatted appropriately for objects such as date, time, number, and currency, which are based on the linguistic and cultural preferences of each locale. Because internationalization is built into the product design, it is generally done once during the product development cycle.
Even a simple field, such as entering a short date, can have many variations depending on locale, with some countries using different delimiters (e.g., DD/MM/YY and DD-MM-YY), while others use different ordering (e.g., YY/MM/DD and MM/DD/YY and formats YYYY/MM/DD or YY.MM.DD. In addition, some locales use leading zeros, while others do not (e.g., 05 or 5). You cannot assume that everyone will understand 04/06/02 to mean the same date.
While a long date may be easier to understand, different countries and regions have different ways of spelling out dates. For your application to be world-ready, it should allow the user to select the date and time formatting for their locale.
The following examples show how dates, times, and date preferences are shown for the United States and Mexico.
Considerations for Localization
Localization and globalization processes are implemented and verified as needed throughout the product life cycle. While the main component of localization is the translation of the text strings, there are other considerations regarding the localization of an application.
If your strings are translated into a variety of languages, you can expect words or strings in some languages to be at least 30 percent longer than the equivalent term in English. When writing your text and deciding how it appears in the page, you should allow up to 30 percent extra spacing for each text string appearing in your user interface.
| English | German | Dutch |
| Apply | Anwenden | van toepassing zijn |
| Click to continue | Klicken Sie weiter | Klik om verder te gaan |
| Edit settings | Einstellungen bearbeiten | Instellingen bewerken |
Creating guidelines and a localization checklist helps you create text that is ready and easier to translate and localize when the time arises. And if your application is not translated, but will be used by diverse audiences, these guidelines will help ensure that all your users find your text easy to understand. Following are basic guidelines you should follow when defining your rules and writing your text:
Language Considerations
Decide which version of English you’re using as the primary language. Then use the appropriate spellings and wording for the selected version. Don’t use both American English and British English spelling and terms (e.g., color versus colour).
Write for clarity, using simple English and simple words. Remember that even simple words can be misinterpreted if they have double meanings or could be interpreted in different ways.
| Incorrect | Correct |
| Select whether you want … | Select if you want … |
| Follow this procedure: | Follow these steps: |
| Once you complete this step … | After completing this step … |
| In other words … | (This one should never be used; if you have to explain your text, it probably needs to be rewritten) |
Avoid complex sentences and large blocks of text.
Languages have varying punctuation rules. Keep in mind that capitalization, exclamation marks, hyphens, question marks, and quotation marks are language dependent.
| English | Spanish | French |
| Do you want to save this image? | ¿Quieres guardar esta imagen? | Voulez-vous sauvegarder l’image? |
| Warning! | ¡Advertencia! | Attention! |
Avoid using (s) or/s to indicate plural. Different languages have different plural forms, and these conventions will not translate well. It may be easier to change the way the text is presented if you have to accommodate plurals.
| Incorrect | Correct |
| Select the image(s) | Select the images: |
| Enter the date/s | Enter the dates: |
| Found N item(s) | Items found: N |
Words and Values Using Numerals
Always indicate the correct format for entering numbers. Some countries use a dot as a decimal separator, while others use a comma (1.000 or 1,000).
If users must enter a time, make sure the format for entering the time is clear. Not all users understand and use the same formatting to indicate time, and there are different formats for indicating a.m. and p.m. Also keep in mind that users are located in varying time zones.
If users must enter a date, make sure the correct format is provided and that the interface provides guidance. Having the user select the day, month, and year from a drop-down list or calendar will help avoid any confusion.
If users must enter contact details such as addresses, keep in mind that not all countries have zip codes, and that the format of the address may vary based on location.
If users must enter phone numbers, remember that phone number formats and country codes vary in length and in the number of digits. Allow for these differences, and provide examples as needed for international phone numbers. For example, a U.S. phone number may be presented in any number of ways, depending on the locale of the person making the call.
| Number | Format |
| 555–1212 | Local phone |
| (541) 555–1212 | Domestic |
| +1-541-555-1212 | International |
| 1-541-555-1212 | Dialed in the United States |
| 001-541-555-1212 | Dialed from Germany |
| 191 541 555-1212 | Dialed from France |
Considerations for Globalization
Following globalization guidelines helps ensure that your content matches the cultural preferences of your users. This is important for improving the overall user experience, and it also helps make your customers feel comfortable using your application.
Here are some simple guidelines you can follow for creating content that is globalized for your users:
Colors can have different meanings in different cultures. Before using colored text and placing text on colored backgrounds, research how the colors are perceived in the cultures of your target users. For example, in the following picture, the application uses green for accenting text and for text background colors. This is appropriate use of color since green is associated with money for the target audience (United States). However, if the application was intended for a global audience, green could be problematic as it indicates infidelity or exorcism in China and corruption in North Africa.
If your application includes maps or mentions geographical locations, ensure that any disputed territories or areas are dealt with in a way that is sensitive to your users. Keep in mind that borders also change with time, so it’s best to avoid using border-specific details in your descriptions and text.
Ensure that the titles you provide for areas, regions, dignitaries, or religious leaders are the acceptable and preferred names for the locale. Remember that names of locales and titles of dignitaries change with time. Avoid using time-specific information in your descriptions and examples.
Provide generic examples of names and companies in examples. Using a real company from a specific local in your examples may insult or upset users in another locale. You can avoid this by using generic terms such as “my company” or make up a company name and use it throughout your samples.
If your users must enter an identity number (such as social security, passport, or driver’s license), make sure your application accepts the format for the locale of the user. While the United States generally accepts a social security number for identifying its citizens, not all locales have similarly formatted forms of identification.
Each country has its own way of writing currencies. These variations include the currency symbol and its position, the formats used to show positive or negative amounts, and the punctuation separating numbers (e.g., placement and usage of dot and comma). Allow for these differences in the way currency values are displayed and entered, and specify the currency being shown with the symbol and universally accepted acronym.
In the next samples, you can see the different formats for currency shown in U.S. dollars and German euros.
When your interface provides a unit of measure, remember that most countries use the metric system. Always provide the accurate unit of measure as specified by the International System of Units guidelines for unit measurements and symbols. Common units and their corresponding symbols are shown in the table.
| Quantity | Unit | Symbol |
| Length, width, distance, thickness, girth, etc. | millimeter | mm |
| centimeter | cm | |
| meter | m | |
| kilometer | km | |
| Mass (“weight”)* | milligram | mg |
| gram | g | |
| kilogram | kg | |
| Time | second | s |
| minute | min | |
| hour | hr | |
| Temperature | degree Celsius | °C |
| degree Fahrenheit | °F |
Unit symbols are case-sensitive. Changing the upper-and lowercase letters changes the meaning of the unit.
Units do not have plural forms and should not have a plural “s” at the end (e.g., 1 kg, 2 kg, etc.).
Units are not abbreviations; they are symbols. So, there’s no period after a unit symbol (unless it happens to fall at the end of a sentence).
Summary
In this chapter you learned how to make your content easily accessible to diverse audiences, such as people with disabilities, and to people living in different locales.
Your content should be accessible to users with visual, hearing, physical, and cognitive disabilities.
Following the WCAG2 guidelines will help you create content that is accessible to people with a wide range of disabilities.
Content should be perceivable, operable, understandable, and robust.
Assistive technologies help users interact with your application.
Users who cannot manipulate a mouse or pointing device rely on hotkeys. Use hotkeys that are meaningful and easily noticed.
Help users understand content by grouping objects and using concise language. Your information should be easy to read on a variety of devices.
If your application will be used by people in varying locales, consider internationalization, localization, and globalization issues when designing and writing your content.
1Keep in mind that “as effectively” is different from “as efficiently.” In most cases it will be more cumbersome to use the accessibility features, but that should not prohibit users from completing the core tasks and use the application.