Where the technology support it ensure that all content is provided with a primary language, specified with an international language code specified in the document. When a change of language occurs make a note of the change of language with a mechanism provided by the technology. Often in languages include 'borrowed' words. For example English takes the phrase 'laissez faire' from the French, however it has been almost naturalized into the language. Many authors would choose not to mark this as a change of language because it has been naturalized, however screen readers and audio browsers are not capable of pronouncing this correctly without the language change being noted. 'Laissez faire' is pronounced "lay-sez fair" however a screen reader might pronounce it "la-is-sez fair-ee" because it is trying to apply English grammar rules to the word. This will not be true of all borrowed words but authors should be aware of the issue and try to ensure that phrases which may be mispronounced by assistive technology are marked up as a change in language.

It is imperative however that any significant changes in language of a document are marked up. If a document contains several primary languages, it should be marked with the primary language as that with the most content and the rest declared individually in blocks.

A person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Grammar checkers will help to ensure that the textual content of your page is correct. This will help readers for whom your document is not written in their native tongue, or people who are just learning the language of the document. Thus, you will help increase the comprehension of your page. Issue 304 - Internationalization issues - "spell" implies applicability only to letter-based languages.

The following writing style suggestions should help make the content of your site easier to read for everyone, especially people with reading and/or cognitive disabilities. Several guides (including ) discuss these and other writing style issues in more detail.

To help determine whether your document is easy to read, consider using the Gunning-Fog reading measure (described in with examples and the algorithm online at ). This algorithm generally produces a lower score when content is easier to read. As example results, the Bible, Shakespeare, Mark Twain, and TV Guide all have Fog indexes of about 6. Time, Newsweek, and the Wall St. Journal an average Fog index of about 11.

Good link text should not be overly general; don't use "click here." Not only is this phrase device-dependent (it implies a pointing device) it says nothing about what is to be found if the link if followed. Instead of "click here", link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page". Note that for the latter case (and other format- or language-specific documents), content developers are encouraged to use content negotiation instead, so that users who prefer text versions will have them served automatically.

If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.

If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.

A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to skip navigation mechanisms more easily to find important content. This helps people with learning and reading disabilities but also makes navigation easier for all users. Predictability will increase the likelihood that people will find information at your site, or avoid it when they so desire.

Examples of structures that may appear at the same place between pages:

A navigation mechanism creates a set of paths a user may take through your site. Providing navigation bars, site maps, and search features all increase the likelihood that a user will reach the information they seek at your site. If your site is highly visual in nature, the structure might be harder to navigate if the user can't form a mental map of where they are going or where they have been. To help them, content developers should describe any navigation mechanisms. It is crucial that the descriptions and site guides be accessible since people who are lost at your site will rely heavily on them.

When providing search functionality, content developers should offer search mechanisms that satisfy varying skill levels and preferences. Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.

Declare technology

Ensure that the technologies that are relied upon by the content are declared and widely available.

A validator can verify the syntax of your pages (e.g., HTML, CSS, XML). Correct syntax will help eliminate a number of accessibility problems since software can process well-formed documents more easily. Also, some validators can warn you of some accessibility problems based on syntax alone (e.g., a document is missing an attribute or property that is important to accessibility). Note, however, that correct syntax does not guarantee that a document will be accessible. For instance, you may provide a text equivalent for an image according to the language's specification, but the text may be inaccurate or insufficient. Some validators will therefore ask you questions and step you through more subjective parts of the analysis. Some examples of automatic validators include:

An automated accessibility validation tool such as Bobby (refer to ).

Validators usually report what issues to solve and often give examples of how to solve them. They do not usually help an author walk through each problem and help the author modify the document interactively. The WAI Evaluation and Repair Working Group () is working to develop a suite of tools that will help authors not only identify issues but solve them interactively.

If an applet (created with either OBJECT or APPLET) requires user interaction (e.g., the ability to manipulate a physics experiment) that cannot be duplicated in an alternative format, make the applet directly accessible.

If an applet creates motion, developers should provide a mechanism for freezing this motion (for an example, refer to ). Also, please refer to the next section for information about making audio and video presentations accessible.

For more information about developing accessible applets, please refer to [JAVAACCESS] and [IBMJAVA]. These companies have been developing an Accessibility API as well as making the Java Swing classes accessible.