Adding facilities for pronunciation semantics

Corresponds to issue number 49

Problem statement / use cases

• When authoring documents with technical terms, specialized terms or neologisms authors need a way to convey the pronunciation of such terms and abbreviated forms
• Authors often need to provide sufficient information to ensure aural UAs correctly pronounce homographs which differ in pronunciation
• Authors often need a simple way to specify the pronunciation for an abbreviation without requiring knowledge of phonetic alphabets
• Authors of HTML may not always have access to stylesheets to provide CSS based pronunciation authoring
• For neologisms and other specialized terms, there’s little a user can do to provide their own user stylesheet to pronounce such terms.

Proposed solutions

• a phonetic attribute for elements introducing terms (e.g., DFN, DefiningTermsEtc: DEFINE, DefiningTermsEtc: T term, VAR, ABBR, DefiningTermsEtc: PN proper noun) that accepts a string value of phonetic Unicode characters (from the IPA only; for other phonetic alphabets, authors should use stylesheets)
• an expressedas attribute for abbreviated forms (ABBR, VAR and ACRONYM attributes) that takes the values of: 'characters', 'word', or 'phrase'
• add a homophone attribute for authors to specify a natural language word pronounced the same as the introduced term (or authoring tools could provide this functionality by translating homophones into phonetic IPA strings)
• UA norms to provide pronunciation support for retrieving and accessing pronunciation information
• UA norms for adjudicating between HTML authored pronunciations and CSS authored pronunciations (e.g., CSS takes precedence over the expressed-as attribute which takes precedence over the phoneme attribute which takes precedence over homophone attribute

Details

While authors can already use CSS and the style attribute for including phonetic information (IPA-based and others) within a document. There is no way to do so in HTML itself. While having multiple ways to include phonetic information is desirable and CSS should probably override HTML phonetics (to permit user and secondary author handling of phonetics), there should certainly be a way to express phonetics within HTML as well. After all the pronunciation of a word is a part of its semantics For example, consider homographs with different pronunciations. The meaning of the word “wind” cannot be determined solely from its spelling. If the word “wind” appeared in a list for example, insufficient context is available to determine its pronunciation or even its meaning.

Aural UA conformance norms

Unless otherwise overridden by CSS or HTML pronunciation attributes, Aural UAs should draw on a localized dictionary to pronounce dictionary words (those found in a comprehensive dictionary for the locale). For dictionary words with multiple pronunciation, aural UAs may provide a mechanism for users to select the preferred pronunciation variant for each such word. For unfamiliar words UAs may provide a mechanism to spell out the word and allow users to define the pronunciation.

For documents providing CSS or HTML pronunciation mechanisms these must override the normal dictionary pronunciations. Aural UAs must treat CSS pronunciations as overriding the HTML expressedas, phoneme, and homophone attributes. Aural UAs must treat the phoneme attribute as overriding the homophone attribute.

General pronunciation norms

HTML should encourage a multi-pronged approach in UA handling of the pronunciation of words.

• From the start, pronunciation in aural UAs has to be a plaintext phenomenon where words from a specific language are mapped through a dictionary to phonetic characters for with speech synthesizers. Since particular words sometimes have variant pronunciations, UAs should provide a mechanism for user to select among the various pronunciations for a word when the dictionary contains more than one. While languages in plaintext are specified by the Unicode language tag characters (U+E0020 – U+E007F), in HTML these language tags should be avoided and instead authors use the lang and xml:lang attributes to specify language.

 * Authors also use technical terms, neologisms other seldom used words where authors may not expect them to appear in a standard UA dictionary. In these cases authors should append pronunciation information to the terms either through:

• the phonetic attribute (preferred)
• the homophone attribute for authors unfamiliar with or not totally adept in the IPA
• CSS stylesheet ID selectors or the style attribute to declare a CSS based pronunciation
• Authors might also make use of a homograph where the meaning — which the pronunciation depends upon — is ambiguous. In these circumstances, authors should also use
• the phonetic attribute (preferred)
• the homophone attribute for authors unfamiliar with or not totally adept in the IPA (for example using homophone='reed' or homophone='red' for ”read” (spelled: R E A D)
• CSS stylesheet ID selectors or the style attribute to declare a CSS based pronunciation
• Users or secondary authors might make use of user stylesheets and other CSS stylesheet to override the pronunciation of terms in the HTML document.
• Aural UAs may provide a user dictionary based mechanism to permit users to provide their own pronunciations for abbreviations, neologisms, and technical terms.
• Users and authors may use CSS to control the verbosity of spoken HTML by using CSS content property as recommended in the CSS3 Speech Module.
• Aural UAs may also provide a supplemental user dictionary to correct mispronounced words in documents so that users do not have to listen to the same mispronunciations each time a particular intricate string is encountered.

Examples

Discussion and evaluation

Applicable Design Principles (proposed)

(see: Design Principles (proposed))

• Support existing content: The use of a new attribute leaves existing content unaffected.
• Degrade gracefully: Degrades gracefully in that legacy UA will ignore the attributes.
• Don't reinvent the wheel: The proposal makes use of existing IPA characters and also allows CSS overrides for pronunciation.
• Evolution not revolution: Simply adds a few attributes.
• Solve real problems: For newly introduced terms and abbreviations, there is no way for speech synthesizers to otherwise determine pronunciation. Authors may provide CSS based pronunciation, but only for authors with CSS access (for example not in some content management systems).
• Priority of constituencies: This deals with problems facing users and authors and in a manner friendly to implementations in that only those already addressing pronunciation need to add new methods.
• Media independence: Facilitates the visual display of phonetic information or speech synthesis using phonetic information.
• Universal access: Facilitates access by aural browser users among others.
• Separation of concerns: Provides better separation between semantic markup and styling by providing authors with a means within HTML to express pronunciation that would otherwise only be available in stylesheets. Pronunciation is an important part of the semantics of terms.
• Well-Defined Behavior:
• Avoid Needless Complexity:

Email

WG members should post feedback and other discussion to the WG’s list serve (the URI for the links below provides date information). Search on this email subject.

Threads

See also

• AbbrAndInitialisms: Abbreviated forms
• DefiningTermsEtc: Defining terms, variables and abbreviations

• TableOfContents: An Index to HTML Wiki Space
• HTML: HTML Wiki Space Main Issues Page