EmotionML comments from WAI_PF

    PF were invited by the MMI WG to review the Emotion Markup Language 1.0 specification:

http://www.w3.org/TR/2011/WD-emotionml-20110407/

PF appreciates this opportunity, and apologizes for forwarding these
comments late. We hope they are still helpful.  We thank Lisa Seman and
Leonie Watson for their work preparing and leading PF's review of this
specification.

Our Comments

We believe that Emotion ML is a positive step towards interoperability. The
emotion behind speech is very much part of the content, so Emotion ML has
terrific potential for accessibility. To build on this, we've put together the
following points for consideration by the MMI WG.

1. Use cases.

    It would help people understand the accessibility potential for Emotion ML if some specific accessibility use cases could be included. Although there might be some overlap with existing use cases, the author/user requirements are quite distinct. Some possible use cases might be:

- Emotion ML is used for media transcripts and captions. Where emotions are marked up to help deaf or hearing impaired people who cannot hear the soundtrack, more information is made available to enrich their experience of the content.

- Emotion ML is used for content that's translated into synthetic speech. This would make more information available to blind and partially sighted people, and enrich their experience of the content.

- Emotion ML is used to make the emotional intent of content explicit. This would enable people with learning disabilities (such as Asperger's Syndrome) to realise the emotional context of the content.

2. Ease of use.

    It's often easier to encourage people to think about accessibility if the author requirements are as minimal as possible. Adding accessibility into some of the examples provided within the specification would make the code quite verbose, and would therefore add a burden onto the developer.

    One possible solution might be to change some of the Emotion ML tags into attributes that could be applied to any element. For example:
<span emotion-category="irritation">Well of course, you would do that!</span>

    Could be used instead of:

<emotion>

<category name="irritation"/>

<span > Well of course, you would do that </span>

</emotion>
 
    Another example (using SMIL) might be:

<s>

<emo:emotion >

<emo:category name="doubt"/>

<emo:intensity value="0.4"/>

</emo:emotion>

Do you need help?

</s>

    Could become:

<s em- category-set=http://www.example.com/emotion/category/everyday-emotions.xml em-category"doubt"  em-intensity value="0.4">

Do you need help?

</s>


    Or alternatively could become:

<s>

<emo:emotion em- category-set=http://www.example.com/emotion/category/everyday-emotions.xml em-category"doubt"  em-intensity value="0.4"/>

Do you need help?

</emo:emotion >

</s>
 
    It might also be helpful to change the name of the attributes, to clarify the fact they relate to emotions. For example, the category attribute could become emotion-category or even em-category (although this is slightly less clear). ARIA uses this approach to good effect for example.

3. New vocabularies and extensions.

    Emotion ML indicates that user defined custom vocabularies do not need to relate to existing vocabularies (although redundancy should be avoided). To some extent this could put the interoperability of the specification at risk.

    One solution might be to create a requirement that user defined custom vocabularies make the relationship with existing requirements explicit. For example, if you wanted to define a new term "contentment", the author of the custom vocabulary would need to say something like:

contentment is a type of happiness 
contentment  overlaps with satisfaction by 80% 
contentment  overlaps with relaxed 70% 
contentment  excludes anger 
contentment  excludes excitement by 90%

    Our definition of contentment might not be exactly right, but the aim is to make the term machine understandable (and hence interoperable).

    This suggestion isn't something that would be necessary at this stage in the lifecycle of the specification. It may be something for consideration in the future though.

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Monday, 20 June 2011 23:14:21 UTC