It is generally accepted that a best practice of accessibility for people with cognitive disabilities is to avoid the use of non-literal text. It has been suggested that Ruby, an emerging HTML 5 and CSS 3 feature, could be used to provide literal alternatives.
Non-literal text includes idioms, colloquialisms, sarcasm and metaphors.
The W3C defines Ruby as:
… short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation.
Retrieved from: http://www.w3.org/TR/ruby/
In H62: Using the Ruby element, the WC3 describes how to:
… use ruby annotation to provide information about the pronunciation and meaning of a run of text where meaning is determined by pronunciation.
Retrieved from: http://www.w3.org/TR/WCAG-TECHS/H62.html
It is obvious, then, that the primary purpose of Ruby is for pronunciation assistance. The connection between Ruby and non-literal text is not immediately apparent. It becomes a little more so with the last part of a statement from the same document:
Ruby Annotation allows the author to annotate a “base text,” providing a guide to pronunciation and, in some cases, a definition as well. (emphasis added)
Ruby Use for People with Cognitive Disabilities
Using Ruby for providing definitions is the connection. I believe discussions about this began with an article published in 2002 by Lisa Steeman. She proposed that, for people with cognitive disabilities:
Non-literal text could be marked up in ruby and a literal translation attribute added to provide a literal alternative.
Ms. Steeman provided this sample code:
<p>The Prime minister wants to
<rb>have his cake and eat it too</rb>
<!– the metaphorical expression –>
<rt>get the benefit of seeming inflexible now, but be able to change his mind again later</rt>
<!– the rt element can be rendered alongside, or instead of, the rb content, according to the styling –>
in this instance.</p>
Retrieved from: http://www2002.org/CDROM/alternate/689/
It is clear from the above example how Ruby could technically provide literal alternatives. In practice, I think it won’t work. Definitions of non-literal text such as sarcasm and idioms are open to wide interpretation. They are also culture dependent. This means people will see different definitions for the same non-literal text, which will be confusing. Furthermore, attempts at such definitions are likely to be clumsy and difficult to understand, such as the above example. Ruby should not be used for this purpose.