Shortened forms on the Web -
Abbreviations, Contractions, Acronyms, Initialisms, Symbols and other things.

Dr Sofia Celic, Web Accessibility Consultant, Accessible Information Solutions at National Information and Library Service.

Introduction

The impetus for this study was the result of observations made during user-based screen reader accessibility testing and from recent studies in technical writing.

Unexpected or undesired pronunciation by screen readers of some web page content was identified. This was mainly in regard to contractions and initialisms because these are rarely desired to be pronounced as a word. Other key observations included the use of an asterisk to denote mandatory form fields and input format information that was not announced or was pronounced in manner that was not useful to the user.

Technical writing studies introduced the definition of a variety of shortened forms. These are used as the basis for terminology used in this study.

The aim of this study is to get an initial idea of the accessibility of shortened forms on the web, particularly for users browsing with a screen reader.

What are shortened forms?

The Style Manual (6th Edition, Revised by Snooks & Co.) offers the following definitions:

Abbreviations
consist of the first letter of a word, usually some other letters, but not the last letter.
Contractions
consist of the first and last letters of a word and sometimes other letters in between.
Acronyms
are strings of initial letters (and sometimes other letters) pronounced as a word. Examples: QANTAS and SCUBA.
Initialisms
are strings of initial letters (and sometimes other letters) not pronounced as a word. Examples: RACV, ACT
Symbols
are internationally recognised representations of units of measurement, words and concepts.

What do the specifications say?

The Web Content Accessibility Guidelines (WCAG) 1.0, HTML 4.01 specification and the User Agent Accessibility Guidelines (UAAG) 1.0 all refer to the provision of alternative content for abbreviations and acronyms. The implementation of the 'abbr' and 'acronym' elements appears to be limited to the provision of an expanded version and user agents are only required to provide a method for users to access this. None of these documents refer to how a screen reader should render the content of these elements.

WCAG 1.0

Checkpoint 4.2 in WCAG 1.0 states:

"Specify the expansion of each abbreviation or acronym in a document where it first occurs."

The example provided in WCAG 1.0 and in the associated techniques document suggest the use of the 'abbr' and 'acronym' elements as an implementation.

HTML 4.01

The classification of 'abbr' and 'acronym' elements in the HTML 4.01 Specification is as phrase elements that add structural information to text fragments. It continues with the following statements:

"Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers."

and

"The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression."

UAAG 1.0

The User Agent Accessibility Guidelines (UAAG) 1.0 specify "Ensure user access to all content" for Guideline 2. Within this document and the associated techniques document, requirements for the 'abbr' and 'acronymn' elements appear to only be for the provision of the conditional content in the 'title' attribute to the user in some manner.

Method

Test files were set up for acronyms, initialisms, abbreviations, contractions and symbols. For all files except symbols, sentences were constructed with and without markup as follows:

  1. Control sentence with no markup.
  2. Sentence with 'abbr' or 'acronym' element markup but no 'title' attribute.
  3. Sentence with 'abbr' or 'acronym' element markup and 'title' attribute with expanded version.

The following samples of shortened forms were tested:

Acronym:
QANTAS
Initialism:
ACT
Abbreviations:
Approx., Vic. and fig.
Contractions:
Mr, Qld and Pty Ltd

The tests were carried out with Window-Eyes 4.5 and JAWS 4.51. A study undertaken by 'CAMO for persons with disabilities' on "How Assistive Software Supports Web Accessibility" (presented at CSUN 2002) found that 'acronym' and 'abbr' elements are not recognised by the following screen reader versions:

  • Window-Eyes 4.2
  • JAWS 3.5
  • JAWS 3.71
  • JAWS 4.02
  • HPR 3.02

JAWS 4.50 does not support acronym and abbreviation recognition and was omitted from testing. JAWS 5.0 appeared to be identical to version 4.51 in regard to recognition of acronym and abbreviation elements, from information in the accompanying manual, and so was omitted from testing.

In Window-Eyes 4.5, acronym and abbreviation handling are controlled by the following options:

  • announce the presence of the acronym and read the acronym
  • not announce the presence of the acronym but read the acronym
  • announce the presence of the acronym and the value of the 'title' attibute before reading the acronym
  • announce the presence of the acronym and read the value of the 'title' attribute in place of the acronym.

In JAWS 4.51, selection of the 'expand acronyms' setting will result in the 'title' attribute value being read in place of the acronym/initialism, when a 'title' attribute is present.

In addition, a file of symbols generated by entity names and entity numbers was tested. The symbols were ©, ®, ™, °, µ and ½.

Results for 'abbr' and 'acronym' markup

Results for acronyms and initialisms marked up with the 'acronym' element:

Window-Eyes 4.5

Window-Eyes 4.5 did not alter its pronunciation of the acronym or initialism under any setting. Although this is okay for acronyms, it means that initialisms were also pronounced as words. In addition, if the acronym was marked up but no 'title' attribute was provided, the acronym/initialism is omitted.

JAWS 4.51

The 'acronym' element did not alter how JAWS 4.51 pronounced the acronym or initialism, nor did it announce any identification of the acronym element. All acronyms and initialisms were pronounced as a word.

Results for abbreviations and contractions marked up with the 'abbr' element:

Window-Eyes 4.5

Window-Eyes 4.5 produced variable results for the abbreviations tested. In particular:

  • Approx was pronounced "approx" with or without markup.
  • Vic. was pronounced "v i c" if no markup is present, and "vic" when markup is present (regardless of 'title' attribute).
  • fig. was pronouced "fig" if no markup is present and "figure" when markup is present (regardless of 'title' attribute).

Contractions often sounded as though each character was being announced. However, this is most likely due to the lack of vowels.

JAWS 4.51

Use of the 'abbreviation' element did not alter how JAWS 4.51 pronounced abbreviations, nor did it announce any identification of the abbreviation element.

Contractions often sounded as though each character was being announced. However, this is most likely due to the lack of vowels.

Results for symbols

Both screen readers identified all symbols tested and announced them appropriately. Results were identical for symbols implemented as entity names and entity numbers.

Other things....

Mandatory form fields

It is a common practice on the web to use an asterisk ("*") to denote mandatory form elements. In some user tests this indicator has not been announced by screen readers.

Window-Eyes 4.5 and 4.2 did not announce the * at all under default settings. This symbol falls under "maths" for pronunciation. Maths includes: plus, minus, asterisk, forward slash, percent sign, less than symbol and greater than symbol.

JAWS 4.5 and 4.51 announced the * under default settings.

Suggestions:

  • Use the word "required"
  • Include a 'title' attribute with the word "required" included in the value for form elements.

Date format information

Date fields in forms often have format information following the input field.

For example:

missed

  • Do not limit the format of input.

Summary

The use of 'abbr' or 'acronym' elements do not alter pronunciation of their content by the screen readers tested. This can be problematic for some shortened forms, giving a misrepresentation of the content to users browsing with a screen reader. It begets the need for web page developers to mark up every shortened form and include a 'title' attribute. However, this requires some knowledge on the part of the user to set up their system to recognise these elements and handle them accordingly.

It would be useful for developers to provide identifiers for content that should be spelt out by screen readers. In theory, this is a capability provided by aural style sheets. However in practise this technology is not recognised by most current screen readers.

Addendum

As of the 6th December 2003, GW Micro has no plans to support aural style sheets for its Window-Eyes product.

OZeWAI 2003 powerpoint presentation (58 kb)

 


Valid XHTML 1.0!



© 2004 NILS - Privacy Statement
Accessible Information Solutions is a registered business name of the
National Information and Library Service (NILS)
NILS is a subsidiary of:
RBS . RVIB . VAF Ltd.