Context usually helps

In most situations, the meaning of heteronyms will become clear once we see the context in which they are used. In ‘After dinner, she was feeling quite content’, we know that ‘content’ is referring to a feeling. And in ‘She wrote the content for this article last night’, we know that ‘content’ is now referring to the words she wrote.

Sometimes the meaning may be unclear

But what about this: ‘She gave a small bow to the princess as she walked by’? Does ‘bow’ mean that she curtsied, or did she give the princess a ribbon for her hair? Without knowing the pronunciation of the word, the meaning would not be clear.

For someone listening to a web page rather than looking at the words on the screen, there may be a different problem.  A vision impaired person using a screen reader may not realise that two meanings were possible. They may just accept the meaning based on the pronunciation the screen reader gives them.

Provide a pronunciation or rewrite the sentence

In cases like the princess and the bow, the Web Content Accessibility Guidelines 2.0 (guideline 3.1.6) suggests we provide a pronunciation so the meaning is clear. We can do this by linking to a sound file or glossary, or providing the pronunciation beside the ambiguous word. This solution requires more effort of our users, however, as they will need to listen to the audio, follow a link to the glossary, or work out the correct pronunciation from the guide provided.

For heteronyms, a better solution would be to rewrite the sentence to avoid the ambiguity. So either ‘She gave a small curtsey as the princess walked by’ or ‘She gave the princess a ribbon for her hair as she walked by’.

Of course rewriting the content may not be a solution for this problem in other languages.

Web Content Accessibility Guidelines references

• Pronunciation: understanding success criterion 3.1.6
• Providing the pronunciation immediately following the word: technique G120
• Linking to pronunciations: technique G21
• Providing a glossary: technique G62

The Web Content Accessibility Guidelines 2.0 suggest we write content that requires reading skills no more advanced than lower secondary education level (7 to 9 years of education). This is to help people with reading disabilities, such as dyslexia. However, there is evidence that writing in a plainer, more readable style benefits everyone, including the organisation that owns the content.

Measuring reading level

Reading level is measured by formulas based mainly on word and sentence length. Two readability testing tools are built into Microsoft Word: Flesch Reading Ease and Flesch-Kincaid Grade Level. You’ll need to enable them and then run the spell-checker. When the spell-checker has finished, Word shows the readability statistics.

If you don’t have Word, you’ll find a range of readability testing tools on the web.  Avoid using tools that test the whole page. Including navigation and other page elements will skew the results.

To meet the accessibility guidelines, your content should have a Flesch Reading Ease score over 50, or a Flesch-Kincaid Grade Level of 9 or lower.

Example readability test

Here’s an example, using content from the Centrelink (an Australian government agency) website.

Interpreter and translation services

To help customers understand Centrelink services, Centrelink provides interpreters at no cost to customers.

Where necessary to support a claim, Centrelink also provides a free translation service for customer documents.

Interpreters contracted by Centrelink are covered by confidentiality provisions and a Code of Ethics, which means customers can be reassured that any information learned through an interview conducted by an interpreter will remain confidential.

Bilingual staff may be available in some Centrelink Customer Service Centres to help with brief customer enquiries. If an interpreter is not immediately available, Centrelink staff may use a telephone interpreter service to assist customers.

I copied this text into Word and ran its readability tests. This showed a Flesch Reading Ease score of 16.6 (too low) and a Flesch-Kincaid Grade Level of 15.8 (too high).

Readability test results

Retest after removing proper nouns

The guidelines let you remove proper nouns from content before testing because it can be hard to find shorter words to replace them. So I retested the content, using ‘X’ to replace the proper nouns and titles (so I was still testing sentences of the same length). The results: a Flesch Reading Ease score of 40.6 and a Flesch-Kincaid Grade Level of 12.5. The reading level is still too high.

Readability test results: retested content

Rewrite with shorter words and sentences

To lower the reading level, we would need to rewrite the content using shorter words and sentences.  Below is my rewritten version. It has a Flesch Reading Ease score of 58.8 and a Flesch-Kincaid Grade Level of 8.3.

Free interpreter and translation services

To help you understand our services, we provide free interpreters. We can also translate your documents if you need to include them with a claim.

If our interpreters are not available we may use telephone interpreters. Some of our staff speak other languages and may also be able to help with short enquiries.

Our interpreters follow a Code of Ethics and must keep your information private.

Readability test results: rewritten content

Problems with readability scores

Readability testing is easy to do, but has significant weaknesses:

• Grade-level scores for the same text differ when using different formulas
• All words of the same length are treated equally, yet ‘agree’ is probably less difficult than ‘concur’
• Shorter words are treated as easier words, but ‘abide’ is probably more difficult than ‘tolerate’
• Shorter sentences are always considered easier to read. However, a sentence of 20 words is not necessarily easier to understand than one of 22 words
• Sentence structure and style are not considered. The use of passive voice, double negatives, nominalisations, noun strings, idioms and other writing problems are not factored into the formulas
• The length, structure and layout of the content are ignored. Long, poorly organised content with rambling paragraphs and few headings is likely to be less readable than well designed content
• The use of graphics to support or present content cannot be measured by readability formulas
• The degree of difficulty of certain concepts or topics is not given any weight
• Readers’ interest and motivation are ignored, along with their existing knowledge of the topic
• It is difficult to get meaningful results from testing tools when there is extensive use of dot points or tables, as is often the case on the web.

Use readability scores carefully

Despite these problems, some argue that readability testing helps them identify or get agreement that content needs to be rewritten or tested with users. If you use a readability testing tool, be aware of its weaknesses, and avoid rewriting content just to get a lower score. For instance, as I rewrote the Centrelink content, I aimed to:

• Avoid using difficult words (‘contracted’, ‘confidentiality’, ‘provisions’, ‘conducted’)
• Use more familiar words (‘help’ instead of ‘assist’, ‘private’ instead of ‘confidential’)
• Cut back on wordy phrasing (‘free’ instead of ‘at no cost to customers’)
• Replace some nouns with personal pronouns (‘we’, ‘our, ‘you’ instead of ‘Centrelink’ and ‘customers’).

This lowered the reading level, but hopefully it also made the content easier to read.

Web Content Accessibility Guidelines references

• Reading level: understanding success criterion 3.1.5
• Making the text easier to read: G153
• Providing a text summary that requires reading ability less advanced than the upper secondary education level: technique G86
• Providing visual illustrations, pictures, and symbols to help explain ideas, events, and processes: technique G103
• Providing a spoken version of the text: technique G79
• Providing sign language versions of information, ideas, and processes that must be understood in order to use the content: technique G160

Readability and plain language references

• Readability formulas
• Be cautious about using readability formulas
• The place of readability formulas in technical communication (PDF 1,000 kb)
• Adult Literacy and Life Skills Survey, Australia 2006
• Low literacy users: writing for a broad consumer audience
• Plain language: the bottom line
• Writing for dollars, writing to please

Abbreviations are shortened word forms such as ‘Dr’ for Doctor and ‘St’ for Street. They also include:

• Acronyms: a single word formed from letters taken from a group of words, and pronounced as a word. Some examples are TESOL (teaching English as a second language),  AGIMO (Australian Government Management Office), and WANAU (Web Accessibility Network for Australian Universities)
• Initialisms: like acronyms, but some people treat them as a different type of abbreviation because they are not pronounced as a word.  Some examples are CD (compact disc), GST (Goods and Services Tax), and ATO (Australian Taxation Office).

Guidelines recommend explaining abbreviations

The Web Content Accessibility Guidelines 2.0 recommend explaining an abbreviation the first time you use it on a web page, or explaining it each time if you use the same abbreviation to mean different things on a single page (Dr for Doctor and Drive, for instance).  The guidelines indicate that you don’t need to worry about explaining abbreviations when they:

• Have become so common, they’re considered part of the language. Laser (Light Amplification by Stimulated Emission of Radiation) and DVD (Digital Versatile Disc) are good examples. Many people don’t know or remember the expanded form of these words
• Are business names, such as IBM (which was International Business Machines but is now known as IBM).

Explanations are not the best solution

Explaining abbreviations is not always the best approach. Instead, we should try to avoid using them. Here are five reasons why.

1. Can be confusing or annoying

Some people will be confused, even if you explain the abbreviation. Every instance of it can be troubling, or even annoying, because it is unfamiliar or hard to pronounce.

Abbreviations can have this effect on anyone. A participant in our recent usability testing commented:

“Institutions and governments love acronyms. They live and breathe by acronyms, which mean everything to those who are used to them, but mean very little, and are just a confusion for people who don’t use them.”

2. Meaning can be mistaken

Abbreviations are not always unique. Users may mistake the meaning of an abbreviation you use, with another they are more familiar with. You might mean the graphic file format when you use PNG, while a user may think you mean Papua New Guinea.

Sometimes the context isn’t clear enough to prevent users making this mistake. Several years ago when testing university websites, I noticed that several students were confused by the abbreviation EFTSL. It meant ‘equivalent full-time study load’ and was used in discussing course costs.  Many students thought it had something to do with ‘electronic funds transfer’, though they couldn’t account for the meaning of ‘SL’.

3. Explanation may not be noticed

Because people tend to scan-read web pages, some may not notice the explanation of the abbreviation if they don’t read the part of the content where you first explained it. And it can be annoying having to scroll up and search for the explanation.

4. Takes more effort to learn and remember

Every time you use an unfamiliar abbreviation, your reader has to learn and then remember it. This adds to the cognitive effort required to read your content.

For some — people with dyslexia, short term memory problems or attention or focus disorders — this extra effort may be too much to ask.

5. Can break reading or task flow

If you’ve provided the explanation through a link to a glossary, users may need to click on the link, navigate to the glossary and then return and resume reading the original page. This breaks the flow of reading and the user’s task.  Some may get distracted or forget what they were doing or and not finish their task.

Even if you’ve included the explanation as a pop-up or mouse-over, users still have to hover over or click on the word, and again, reading flow is interrupted.  People with disabilities that make it hard to maintain reading flow will be more inconvenienced than other users.

How to avoid using abbreviations

Use a pronoun

Use a word taken from the name

Use the long form

In some cases, you may be able to use the long form rather than abbreviating it.

Don’t use an abbreviation if you only use the long form once

If you only refer to the long form of an abbreviation once on the page, there is no need to use the abbreviated form.

Web Content Accessibility Guidelines references

• Abbreviations: understanding success criterion 3.1.4
• Providing the expansion or explanation of an abbreviation: technique G102
• Providing the abbreviation immediately following the expanded form: technique G97
• Providing definitions for abbreviations by using the abbr and acronym elements: technique H28
• Linking to definitions: technique G55
• Using the link element to link to a glossary: technique H60
• Providing a glossary: technique G62

Jargon

Jargon is language used by people within a trade, profession, group or organisation.  By definition, it is often not shared beyond the group that uses it. This can create problems for people reading your content if they are not from your organisation or profession and the terms you use are not well known to them.  Here are some examples.

• footway (footpath)
• waterway (creek, canal, river, lake, sea, ocean)
• revolving credit facility (overdraft, line of credit)
• transfer station (rubbish tip)
• testamur (degree certificate)

Idioms

An idiom is a word or phrase that means something different to the literal meaning of the words within it. Idioms often rely on a shared cultural background. Australians use idioms that other English speakers may not understand and vice versa. Here are some examples you might hear in a business context.

• belt-tightening (cut expenses)
• cash cow (product or service that creates a lot of income)
• empty nesters (people whose children no longer live at home)
• jump through hoops (deal with a lot of difficulties)
• plug (promote something)
• rally the troops (motivate people)
• through the roof (very high, higher than expected)

Idioms can create problems for people with English as a second language, even though they may know the meaning of each word within the phrase. And anyone trying to translate idioms from one language to another is likely to run into trouble. The Web Content Accessibility Guidelines include these great examples:

• In English, “spilling the beans” means “revealing a secret.” However, “knocking over the beans” or “spilling the vegetables” doesn’t mean the same thing
• In Japanese, the phrase “さじを投げる” literally translates as “he throws a spoon,” but it means that there is nothing he can do and finally he gives up
• In Dutch, “Hij ging met de kippen op stok” literally translates as “He went to roost with the chickens,” but it means that he went to bed early.

Avoid this language if you can

Accessibility guidelines suggest that you can use definitions, glossaries and dictionaries as a way of explaining jargon and idioms. However, these approaches require your users to make more of an effort to understand you. A better, more user-friendly option is to avoid this kind of language whenever you can.

Web Content Accessibility Guidelines references

• Unusual words: understanding success criterion 3.1.3
• Providing the definition of a word or phrase used in an unusual or restricted way: technique G101:
• Linking to definitions: technique G55
• Using inline definitions: technique G112
• Providing a glossary: technique G62
• Providing a function to search an online dictionary: technique G70
• Using definition lists: technique H40
• Using the link element to link to a glossary: technique H60
• Using the dfn element to identify the defining instance of a word: H54

• Screen readers use the right pronunciation rules for the language
• Web browsers display the characters for the language properly. This is particularly important if the language uses a different alphabet or is read from right to left.

Identifying language changes will help people with reading and cognitive disabilities using text-to-speech software to read web content. It will also help vision impaired users who use screen readers that convert text to synthetic speech. It may also help people recognise that an unfamiliar word or phrase is from a foreign language when it is displayed with diacritical marks or in another alphabet.

Using foreign language markup

Many web writers will be unaware of foreign language markup. Most content management systems won’t have a menu option allowing you to label foreign passages or phrases. You may have to edit the HTML source code or get help from a developer—at least the first time.

The markup you use will depend on whether you are editing an HTML or XHTML page, and where the foreign language passage occurs in your content. Here are a couple of simple HTML examples with the language attribute emphasised.

A French quotation on an English language page.

<blockquote lang="fr">
 La vérité vaut bien qu'on passe quelques années sans la trouver. Renard
 </blockquote>

German phrases on an English language page.

<h3>Common greetings</h3>
 <ul>
 <li><span lang="de">Hallo</span> (Hello)</li>
 <li><span lang="de">Guten tag</span> (Good morning)</li>
 <li><span lang="de">Guten abend</span> (Good evening)</li>
 </ul>

When foreign language markup is not necessary

Some foreign words and phrases have become part of English and do not need to be identified as a foreign language. Many words of French origin, such as rendezvous, avante-garde and bon voyage, are now considered part of English. Similarly, some specialist terms used in certain professions—homo sapiens or habeas corpus, for example—do not need to be labelled as foreign language terms.

Web Content Accessibility Guidelines references

• Language of parts: understanding success criterion 3.1.2
• Using language attributes to identify changes in the human language: technique H58

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6
• Images of text: accessibility for web writers, part 7
• Page titles: accessibility for web writers, part 8
• Link purpose: accessibility for web writers, part 9
• Headings and labels: accessibility for web writers, part 10
• Section headings: accessibility for web writers, part 11

If you are publishing content written by others (policies or media releases, for example), you may not be able to add section headings. But it is a good practice to do so whenever you can. Blog posts can also be improved by the use of section headings.

Other guidelines on headings

The Web Content Accessibility Guidelines include two other guidelines on headings. The first recommends the use of appropriate heading tags (h1 to h6), to show the structure of the content. Part 3 of this series discusses this guideline. A second guideline suggests writing descriptive headings. This was the topic of part 10.

Web Content Accessibility Guidelines references

• Section headings: understanding success criterion 2.4.10
• Organising a page using headings: technique G141

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6
• Images of text: accessibility for web writers, part 7
• Page titles: accessibility for web writers, part 8
• Link purpose: accessibility for web writers, part 9
• Headings and labels: accessibility for web writers, part 10

Descriptive headings and labels are important for people with disabilities. People who read slowly or have problems with short-term memory will benefit from well-labelled chunks of content, rather than having to take in an entire page or article. Vision impaired users of screen reading software will be able to skip to and read each heading to get the gist of the content. Those using screen magnifiers will also be able to get a quicker overview.

Using meaningful headings and labels will also help your search engine ranking, particularly if you use keywords: the terms or phrases your users are likely to search with.

Tips for better headings and labels

• Clearly describe the content or purpose of the page or article in the main heading
• Write sub-headings that describe, summarise or clearly label each part of the page or article
• Avoid teasers or cute, catchy phrasing that may not be clear to all users
• Use keywords or keyword phrases, particularly in the main heading
• Avoid jargon, acronyms and other shortened forms unless they are familiar to your target audience
• Start headings and labels with distinguishing information, so those who only see or listen to the first few words can distinguish it from earlier and later headings
• Take care using questions as headings as they can push distinguishing words away from the start of a heading
• Be concise. Headings that wrap to a second line may be harder for some users to see or understand
• Write in sentence or title case. Uppercase may be harder for some people to read

References: Web Content Accessibility Guidelines

• Headings and labels: understanding success criterion 2.4.6
• Providing descriptive headings: technique G130

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6
• Images of text: accessibility for web writers, part 7
• Page titles: accessibility for web writers, part 8
• Link purpose: accessibility for web writers, part 9

Meaningful links are vital for making content more accessible to people with disabilities.

A series of 'read more' links can create usability and accessibility problems

  Meaningful links help users with disabilities

• Vision impaired users who use screen reading software to listen to a web page can ‘scan’ a page by jumping from link to link. They can also open up a list of links on the page and use that to decide how to move forward. Well written links will help these users navigate with confidence and efficiency
• People with limited vision may use screen magnifier software. If a link is clearly described, they will not have to scroll around text near the link to figure out where it leads. This will save them time and effort, and reduce the chance of them clicking on links that are not relevant
• Users with reading or cognitive limitations can be confused or distracted by bland or ambiguous links. Meaningful links will reduce these problems and save time that would otherwise be lost by following irrelevant links
• People with mobility impairments who cannot use or control a mouse may have to expend a lot of energy to move through a page. Following misleading links can cause fatigue. Well-written links will limit this.

'Click here' links shown in a screen reader's links list

Tips for better links

• Clearly describe the content or function of the link. Avoid using ‘click here’, ‘read more’ and other ambiguous labels
• Use meaningful words, particularly keywords (terms users are likely to search with) as these will act as trigger words, drawing users’ attention to the link. Using keywords will also improve search rankings
• Place keywords as close to the start of the link as possible. This aids scan reading and screen reader users, who often only read the first word or two in a link
• Avoid using URLs as links. URLs can be ambiguous or difficult for some users to understand. For links to email addresses, use the email address as the link text. This makes the link purpose obvious and allows users to cut and paste email addresses into web mail clients
• Avoid using the same link text for links that lead to different places unless doing so would clutter the visual design (For instance, a hotel booking site may show a list of hotels in an area. Each has a link to a map, photos, rooms, features, and so on. Distinguishing each of those by adding the hotel name may create visual clutter. Instead, you could add some distinguishing words that are hidden from the visual display. See the Web Content Accessibility Guidelines, technique C7: Using CSS to hide a portion of the link text)
• Keep links concise while including enough information to allow users to identify the linked resource
• Position links carefully within content. Links embedded in paragraphs can be a distraction from content that users may need to read. They may also end up wrapping to another line, making link fragments hard to scan-read
• Warn users, within the link, when links will open documents (PDF, Word and so on). Include the document type and size within the link
• Avoid opening links in new windows, except for documents and help text. Warn users within the link when help text will open in a new window
• Don’t link just because you can. Only include links that are directly relevant to the tasks users may be doing. If you must include links to sources, do so at the end of the content

Web Content Accessibility Guidelines references

• Link purpose (in context): understanding success criterion 2.4.4
• Link purpose (link only): understanding success criterion 2.4.9
• C7: Using CSS to hide a portion of the link text

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6
• Images of text: accessibility for web writers, part 7
• Page titles: accessibility for web writers, part 8

Many web pages have poor page titles. PDF, Word and PowerPoint documents usually fare worst, with many having no title.

Lack of awareness leads to poor page titles

Web writers are sometimes unaware of the page title—what it is, where to find it, or how to write it. Some content management systems are set up to deal with this issue and create the title from the main heading (the <h1> tag). Some add the site name. This is a good starting point, but sometimes the title needs more context than this provides. And most content management systems cannot create titles for non-HTML documents.

The best approach is to ensure web writers understand why page titles are important and where and how to write them. Content management systems should continue to create a default title, but should be set up to allow writers to edit the title.

Understanding the role of page titles

The page title is the text that appears within the <title> tags. You can see it in the mark-up of a page by viewing the source code.

Web browsers and page titles

Web browsers use the page title to label browser windows, tabs and links added to bookmarks or favourites. They also use it to mark entries in your browsing history.

The screen shots below show how important the page title is for orientation and re-finding content. Good page titles help users move confidently between windows or tabs and easily re-find things they’ve viewed recently or saved to their favorites.

How Internet Explorer uses the <title> in the title bar, tabs and favorites

How Internet Explorer uses the <title> in its history

Search engines and page titles

Search engines usually display the page title as the linked text in search results. One notable exception is when pages (particularly non-HTML documents) have no title. Google creates a title to help users decide if the page is relevant.

The screen shot below shows how important page titles are in helping people find content when they search. In this example, several pages have similar titles, forcing users to read more to figure out what each page is about.

Another reason for writing good titles is search engine ranking. Search engine optimisation experts advise that the terms used in a page title play an important ranking role.

Google uses the <title> to link pages in search results

Social media and page titles

The page title is often used as the default text when sharing links using social media. Facebook (shown below), LinkedIn and most link shortening services (often used for sharing links on Twitter because of the 140 character message limit) use it. Better page titles will help users who share your content.

Facebook uses the <title> for links posted to your wall

Writing page titles

If you’re publishing:

• Web pages using a content management, you’ll need to find out if and where you can edit the page title. Usually, there will be a  field on a metadata screen. Sometimes your content management system may not let you edit the title. In this case, find out how the title is created. If it is based on the main heading (the <h1> tag), then you’ll need to write something suitably descriptive there
• PDF, Word or PowerPoint documents, you’ll find the title field under different menus depending on the tool and version you’re using. For Acrobat 9, go to File > Properties. For Word 2010, go to File > Info > Properties.

We’ve put together some guidelines on writing better page titles. We’ve considered accessibility, along with usability and search engine optimisation.

See: Writing page titles: tips for web writers

Web Content Accessibility Guidelines references

• Page titled: understanding success criterion 2.4.2

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6
• Images of text: accessibility for web writers, part 7

People with low vision who use screen magnification software to enlarge content so they can see it, may also find it difficult to read an image of text.  The text can become too pixelated to be legible when the image is magnified. The smaller the text, the more pixelated it will become.

Text in images pixelates when enlarged

Use style sheets to style text

The best approach is to ensure all your text is styled using cascading style sheets (CSS).  If you want a particular font, size, colour or alignment, talk to your web designer or developer to see if they can create a style for you to use.

You should always use styled text rather than images of text for:

• Headings and sub-headings
• Captions for photos and graphics
• Pull quotes or other feature text
• Text in the body of your page
• Text or data in tables

Sometimes an image of text is acceptable

You can use an image of text for:

• Your organisation’s logo
• Presenting a font when the content on the page is about a particular font (for instance, in a font library)
• Presenting information in its original format when this is essential to the content (for instance, an image of an historical document).

The Web Content Accessibility Guidelines 2.0 describe a few other scenarios where developers can use images of text.

Web Content Accessibility Guidelines references

• Images of text: understanding success criterion 1.4.5
• Images of text (no exception): understanding success criterion 1.4.9

Earlier articles in this series

• Introduction: accessibility for web writers, part 1
• Text alternatives for images: accessibility for web writers, part 2
• Info and relationships: accessibility for web writers, part 3
• Sensory characteristics: accessibility for web writers, part 4
• Colour: accessibility for web writers, part 5
• Contrast: accessibility for web writers, part 6