This document is the Gap Analysis Review which presents required features of Spoken Text Pronunciation and Presentation and existing standards or specifications that may support (or enable support) of those features. Gaps are defined when a required feature does not have a corresponding method by which it can be authored in HTML.
Accurate, consistent pronunciation and presentation of content spoken by text to speech synthesis (TTS) is an essential requirement in education and other domains. Organizations such as educational publishers and assessment vendors are looking for a standards-based solution to enable authoring of spoken presentation guidance in HTML which can then be consumed by assistive technologies and other applications which utilize text to speech synthesis for rendering of content.
W3C has developed two standards pertaining to the presentation of speech synthesis which have reached
recommendation status, Speech Synthesis Markup Language
(SSML) and the Pronunciation Lexicon Specification
(PLS). Both standards are directly consumed by a speech synthesis engine supporting those standards. While a PLS
file reference may be referenced in a HTML
page using link rel, there is no known uptake of PLS using this method by assistive technologies.
While there are technically methods to allow authors to inline SSML within HTML (using namespaces), such an
approach has not been
adopted, and anecdotal comments from browser and assistive technology vendors have suggested this is not a viable
approach.
CSS Speech Module is a retired W3C Working Group Note that describes mechanism by which content authors may apply a variety of speech styling and presentation properties to HTML. This approach has a variety of advantages but does not implement the full set of features required for pronunciation. Section 16 of the Note specifically references the issue of pronunciation:
CSS does not specify how to define the pronunciation (expressed using a well-defined phonetic alphabet) of a particular piece of text within the markup document. A "phonemes" property was described in earlier drafts of this specification, but objections were raised due to breaking the principle of separation between content and presentation (the "phonemes" authored within aural CSS stylesheets would have needed to be updated each time text changed within the markup document). The "phonemes" functionality is therefore considered out-of-scope in CSS (the presentation layer) and should be addressed in the markup / content layer.
While a portion of CSS Speech was demonstrated by Apple in 2011 on iOS with Safari and VoiceOver, it is not presently supported on any platform with any Assistive Technology, and work on the standard has itself been stopped by the CSS working group.
Efforts to address this need have been considered by both assessment technology vendors and the publishing
community. Citing the need for pronunciation and presentation controls, the IMS Global Learning Consortium added
the ability to author SSML
markup, specify PLS files, and reference CSS Speech properties to the Question Test Interoperability (QTI) Accessible Portable Item Protocol (APIP).
In practice, QTI/APIP
authored content is transformed into HTML for rendering in web browsers. This led to the dilemma that there is no
standardized (and supported) method for inlining SSML in HTML, nor is there support for CSS Speech. This has led
to the situation
where SSML is the primary authoring model, with assessment vendors implementing a custom method for adding the
SSML (or SSML-like) features to HTML using non-standard or data attributes, with customized Read Aloud software
consuming those
attributes for text to speech synthesis. Given the need to deliver accurate spoken presentation, non-standard
approaches often include mis-use of WAI-ARIA, and novel or contextually non-valid attributes (e.g.,
label). A
particular problem occurs when custom pronunciation is applied via a misuse of the aria-label
attribute, which results in an issue for screen reader users who also rely upon refreshable braille, and in which
a hinted pronunciation
intended only for a text to speech synthesizer also appears on the braille display.
The attribute model for adding pronunciation and presentation guidance for assistive technologies and text to
speech synthesis has demonstrated traction by vendors trying to solve this need. It should be noted that many of
the required
features are not well supported by a single attribute, as most follow the form of a presentation property / value
pairing. Using multiple attributes to provide guidance to assistive technologies is not novel, as seen with
WAI-ARIA where multiple
attributes may be applied to a single element, for example, role and aria-checked. The
EPUB
standard for
digital publishing introduced a namespaced version of the SSML phoneme and alphabet
attributes enabling content authors to provide pronunciation guidance. Uptake by the publishing community has been
limited, reportedly
due to the lack of support in reading systems and assistive technologies.
The common spoken pronunciation requirements from the education domain serve as a primary source for these features. These requirements can be broken down into the following main functions that would support authoring and spoken presentation needs.
When content is authored in mixed language, a mechanism is needed to allow authors to indicate both the base language of the content as well as the language of individual words and phrases. The expectation is that assistive technologies and other tools that utilize text to speech synthesis would detect and apply the language requested when presenting the text.
Content authors may elect to make adjustments of those paramters to control the spoken presentation for purposes such as providing a gender specific voice to reflect that of the author, or for a character (or characters) in theatrical presentation of a story. Many assistive technologies already provide user selection of voice family and gender independent of any authored intent.
In some cases words may need to have their phonetic pronunciation prescribed by the content author. This may occur when uncommon words (not supported by text to speech synthesizers), or in cases where word pronunciation will vary based on context, and that context may not be correctly described.
There are cases where content that is visually presented may require replacement (substitution) with an alternate textual form to ensure correct pronunciation by text to speech synthesizers. In some cases phonetic pronunciation may be a solution to this need.
While end users should have full control over spoken presentation parameters such as speaking rate, pitch, and volume (e.g., WCAG 1.4.2 ), content authors may elect to make adjustments of those parameters to control the spoken presentation for purposes such as a theatrical presentation of a story. Many assistive technologies already provide user control speaking rate, pitch, and volume independent of any authored intent.
In written text, an author may find it necessary to add emphasis to an important word or phrase. HTML supports
both semantic elements (e.g., em) and CSS properties which, through a variety of style options,
make programmatic
detection of authored emphasis difficult (e.g., font-weight: heavy). While the emphasis element has
existed since HTML 2.0, there is currently no uptake by assistive technology or read aloud tools to present text
semantically tagged
for emphasis to be spoken with emphasis.
While text to speech engines continue to improve in their ability to process text and provide accurate spoken rendering of acronyms and numeric values, there can be instances where uncommon terms or alphanumeric constructs pose challenges. Further, some educators may have specific requirements as to how a numeric value be spoken which may differ from a TTS engine's default rendering. For example, the Smarter Balanced Assessment Consortium has developed Read Aloud Guidelines to be followed by human readers used by students who may require a spoken presentation of an educational test, which includes specific examples of how numeric values should be read aloud.
Precise control as to how numeric values should be spoken may not always be correctly determined by text to speech engines from context. Examples include speaking a number as individual digits, correct reading of year values, and the correct speaking of ordinal and cardinal numbers.
Precise control as to how string values should be spoken, which may not be determined correctly by text to speech synthesizers.
Specific spoken presentation requirements exist in the Accessibility Guidelines from PARCC, and include requirements such as inserting pauses in the spoken presentation, before and after emphasized words and mathematical terms. In practice, content authors may find it necessary to insert pauses between numeric values to limit the chance of hearing multiple numbers as a single value. One common technique to achieve pausing to date has involved inserting non-visible commas before or after a text string requiring a pause. While this may work in practice for a read aloud TTS tool, it is problematic for screen reader users who may, based on verbosity settings, hear the multiple commas announced, and for refreshable braille users who will have the commas visible in braille.
Based on the features and use cases described in the prior sections, the following table presents existing speech presentation standards, HTML features, and WAI-ARIA attributes that may offer a method to achieve the requirement for HTML authors. A blank cell for any approach represents a gap in support.
| Requirement |
HTML |
WAI-ARIA |
PLS |
CSS Speech |
SSML |
|---|---|---|---|---|---|
| Language |
Yes |
Yes |
|||
| Voice Family/Gender |
Yes |
Yes |
|||
| Phonetic Pronunciation |
Yes |
Yes |
|||
| Substitution |
Partial |
Yes |
|||
| Rate/Pitch/Volume |
Yes |
Yes |
|||
| Emphasis |
Yes |
Yes |
Yes |
||
| Say As |
Yes |
||||
| Pausing |
Yes |
Yes |
The following sections describe how each of the required features may be met by the use of existing approaches. A key consideration in the analysis is whether a means exists to directly author (or annotate) HTML content to incorporate the spoken presentation and pronunciation feature.
Allow content authors to specify the language of text contained within an element so that the TTS used for
rendering will select the appropriate language for synthesis.
lang attribute can be applied at the document level or to individual elements. (WCAG) (AT
Supported: some)
Example: <speak> In Paris, they pronounce it <lang xml:lang="fr-FR">Paris</lang>
</speak>code>
Allow content authors to specify a specific TTS voice to be used to render text. For example, for content that presents a dialog between two people, a woman and a man, the author may specify that a female voice be used for the woman's text and a male voice be used for the man's text. Some platform TTS services may support a variety of voices, identified by a name, gender, or even age.
voice-family property can be used to specify the gender of the voice.
Example: { voice-family: male; }
Using the <voice> element, the gender of the speaker, if supported by the TTS engine, can be
specified.
Example: <voice gender="female" >Mary had a little lamb,</voice>
Allow content authors to precisely specify the phonetic pronunciation of a word or phrase.
Using PLS, all the pronunciations can be factored out into an external PLS document which is referenced by the
<lexicon> element of SSML
Example: <speak> <lexicon uri="http://www.example.com/movie_lexicon.pls"/>
The title of the movie is: "La vita è bella" (Life is beautiful),
which is directed by Roberto Benigni.</speak>
The following is a simple example of an SSML document. It includes an Italian movie title and the name of the director to be read in US English.
Example: The title of the movie is:
<speak> <phoneme alphabet="ipa" ph="ˈlɑ ˈviːɾə ˈʔeɪ ˈbɛlə">
"La vita è bella"</phoneme> (Life is beautiful),
which is directed by
<phoneme alphabet="ipa" ph="ɹəˈbɛːɹɾoʊ bɛˈniːnji"">
Roberto Benigni </phoneme>.</speak>
Allow content authors to substitute a text string to be rendered by TTS instead of the actual text contained in an element.
The aria-label and aria-labelledby attribute can be used
by an author to supply a text string
that will become the accessible name for the element upon which it is applied. This usage effectively
provides a mechanism for performing text substation that is supported by a screen reader. However, it is
problematic for one significant reason; for users who utilize screen readers and refreshable Braille, the
content that is voiced will not match the content that is sent to the refreshable Braille device. This mismatch
would not be acceptable for some content, particularly for assessment content.
Pronounce the specified word or phrase as a different word or phrase. Specify the pronunciation to substitute
with the alias attribute.
<speak>
My favorite chemical element is <sub alias="aluminum">Al</sub>,
but Al prefers <sub alias="magnesium">Mg</sub>.
</speak>
Allow content authors to specify characteristics, such as rate, pitch, and/or volume of the TTS rendering of the text.
‘voice-rate’ property manipulates the rate of generated synthetic speech in terms of words
per minute.
‘voice-pitch’ property specifies the "baseline" pitch of the generated speech output, which
depends on the used ‘voice-family’ instance, and varies across speech synthesis processors (it
approximately corresponds to the average pitch of the output). For example, the common pitch for a male voice
is around 120Hz, whereas it is around 210Hz for a female voice.
‘voice-range’ property specifies the variability in the "baseline" pitch, i.e. how much the
fundamental frequency may deviate from the average pitch of the speech output. The dynamic pitch range of the
generated speech generally increases for a highly animated voice, for example when variations in inflection
are used to convey meaning and emphasis in speech. Typically, a low range produces a flat, monotonic voice,
whereas a high range produces an animated voice.prosody modifies the volume, pitch, and rate of the tagged speech.
<speak>
Normal volume for the first sentence.
<prosody volume="x-loud">Louder volume for the second sentence</prosody>.
When I wake up, <prosody rate="x-slow">I speak quite slowly</prosody>.
I can speak with my normal pitch,
<prosody pitch="x-high"> but also with a much higher pitch </prosody>,
and also <prosody pitch="low">with a lower pitch</prosody>.
</speak>
Allow content authors to specify that text content be spoken with emphasis, for example, louder and more slowly. This can be viewed as a simplification of the Rate/Pitch/Volume controls to reduce authoring complexity.
The HTML <em> element marks text that has stress emphasis. The <em>
element can be nested, with each level of nesting indicating a greater degree of emphasis.
The <em> element is for words that have a stressed emphasis compared to surrounding text,
which is often limited to a word or words of a sentence and affects the meaning of the sentence itself.
Typically this element is displayed in italic type. However, it should not be used simply to apply italic
styling; use the CSS font-style property for that purpose. Use the <cite>
element to mark the title of a work (book, play, song, etc.). Use the <i> element to mark
text that is in an alternate tone or mood, which covers many common situations for italics such as scientific
names or words in other languages. Use the <strong> element to mark text that has greater
importance than surrounding text.
‘voice-stress’ property manipulates the strength of emphasis, which is normally applied
using a combination of pitch change, timing changes, loudness and other acoustic differences. The precise
meaning of the values therefore depend on the language being spoken.Emphasize the tagged words or phrases. Emphasis changes rate and volume of the speech. More emphasis is spoken louder and slower. Less emphasis is quieter and faster.
<speak>
I already told you I
<emphasis level="strong">really like</emphasis> that person.
</speak>
Allow content authors to specify how text is spoken. For example, content authors would be able to indicate that a series of four numbers should be spoken as a year rather than a cardinal number.
The ‘speak-as’ property determines in what manner text gets rendered aurally, based upon a
predefined list of possibilities.
Speech synthesizers are knowledgeable about what a number is. The ‘speak-as’ property enables some
level of control on how user agents render numbers, and may be implemented as a preprocessing step before
passing the text to the actual speech synthesizer.
Describes how the text should be interpreted. This lets you provide additional context to the text and eliminate
any ambiguity on how Alexa should render the text. Indicate how Alexa should interpret the text with the
interpret-as attribute.
<speak>
Here is a number spoken as a cardinal number:
<say-as interpret-as="cardinal">12345</say-as>.
Here is the same number with each digit spoken separately:
<say-as interpret-as="digits">12345</say-as>.
Here is a word spelled out: <say-as interpret-as="spell-out">hello</say-as>
</speak>
Allow content authors to specify pauses before or after content to ensure the desired prosody of the presentation, which can affect the pronunciation of the pronunciation of content the precedes or follows the pause.
The ‘pause-before’ and ‘pause-after’ properties specify a prosodic boundary (silence
with a specific duration) that occurs before (or after) the speech synthesis rendition of the selected element,
or if any ‘cue-before’ (or ‘cue-after’) is specified, before (or after) the cue within
the aural box model.
Note that although the functionality provided by this property is similar to the break element from
the SSML markup language [SSML], the application of ‘pause’ prosodic boundaries within the aural box model of
CSS Speech requires special considerations (e.g. "collapsed" pauses).
break represents a pause in the speech. Set the length of the pause with the strength
or time attributes.
<speak>
There is a three second pause here <break time="3s"/>
then the speech continues.
</speak>