role values

[marisademeglio]

What values are allowed for role? We say it's for "semantic information" but we don't specify vocabularies or allowed terms.

[marisademeglio]

the term role is loaded; maybe use something else?

[swickr]

The term "role" appears in Synchronized Narration, draft CG report as of 2019-09-15

[BigBlueHat]

You might exploring using the purpose word from Web Annotation Data Model's Motivation and Purposes section. There's also a means to extend that list itself--which would mean both communities can benefit. 😃

[marisademeglio]

@BigBlueHat I'm looking at that now and I wonder if we don't have a different meaning here. Web Annotations says:

`purpose`:  
The reason for the inclusion of the Textual Body within the Annotation.
There MAY be 0 or more purposes associated with a TextualBody.

Whereas here we are not talking about the reason for inclusion but rather the description of the grouping. E.g.

{
  "role": "body",
  "narration": [
    {
      "text": "#doctitle",
      "audio": "doc.mp3#t=0.0,2.60"
    },
    {
      "text": "#s1",
      "audio": "doc.mp3#t=2.60,8.11"
    },
    {
      "role": "example",
      "narration": [
        {
          "text": "#ex-p1",
          "audio": "doc.mp3#t=0.0,2.41"
        },
        {
          "text": "#ex-p2",
          "audio": "doc.mp3#t=3.62,5.91"
        },
        ...
      ]
  }
}

And the function provided by identifying such structural groupings is so that readers can stop listening to them and return to the main body flow ("escaping") or default to having them not read in the first place ("skipping").

The values for our roles feel similar to DPUB-ARIA to me.

Would purpose: "example" be using the web annotations definition of purpose correctly?

[marisademeglio]

This is still an open issue. I think the most likely role role vocabularies would be WAI-ARIA Document Structure and DPUB-ARIA.

My questions are:

• should we be agnostic or have built-in support for these role values?
• if we remain agnostic, how complicated is the mechanism by which an author would have to include a reference to a role vocabulary of their choosing? Say they are using a JSON serialization of SyncMedia and want to reference DPUB-ARIA roles. How trivial is this?

[marisademeglio]

Leaning towards built-in support for WAI-ARIA and DPUB-ARIA, and not EPUB SSV.

Aside: here are all the EPUB SSV terms that do not map to DPUB-ARIA:
https://gist.github.com/marisademeglio/609e65ebb7c7bd1b2b2099aa1cb7a0c3

[marisademeglio]

If we are defining SyncMedia as SMIL + customizations prefixed with sync:, how does role fit in? The Role Attribute spec says its namespace is http://www.w3.org/1999/xhtml. Do we include this and prefix role accordingly, or do we define our own sync:role and, as HTML5 has done, remain consistent with the definition of the term given by the Role Attribute spec?

[iherman]

The role attribute was originally defined as a generic attribute for XHTML. However, by now, it has been so closely associated with the ARIA work that I would consider it as essentially owned by that community. I do not know of any significant usage of xhtml:role for anything else. It is a pity (after all, I could imagine to use role as HTML5 compatible alternative for epub:type) but that boat has sailed.

I.e., if we want to use it for sync, using a different namespace would be the way to go imho. Actually, just to avoid confusion, I would prefer to use a different term. (And I would let my native Anglo-Saxon speaker friends to come up with a suitable alternative…)

[marisademeglio]

@iherman if we want to indicate ARIA roles, from the vocabularies WAI-ARIA document structure and DPUB-ARIA, would it be ok and not confusing to use role ?

[iherman]

@iherman if we want to indicate ARIA roles, from the vocabularies WAI-ARIA document structure and DPUB-ARIA, would it be ok and not confusing to use role ?

I think so, yes. We should ask our colleagues in the ARIA group, but I don't see reason why not.

[marisademeglio]

@iherman if we want to indicate ARIA roles, from the vocabularies WAI-ARIA document structure and DPUB-ARIA, would it be ok and not confusing to use role ?

I think so, yes. We should ask our colleagues in the ARIA group, but I don't see reason why not.

Good idea, who do you think I should reach out to?

[iherman]

@iherman if we want to indicate ARIA roles, from the vocabularies WAI-ARIA document structure and DPUB-ARIA, would it be ok and not confusing to use role ?

I think so, yes. We should ask our colleagues in the ARIA group, but I don't see reason why not.

Good idea, who do you think I should reach out to?

@mattgarrish @TzviyaSiegman, you worked with the ARIA folks more closely than I did, what do you think?

[mattgarrish]

after all, I could imagine to use role as HTML5 compatible alternative for epub:type

Well, epub:type was based on that XHTML role spec, as we were told not to go near that role attribute. If past discussions are any indication, the boat is not returning to reconsider it in HTML, in no small reason because it would now conflict with the accessibility use.

if we want to indicate ARIA roles, from the vocabularies WAI-ARIA document structure and DPUB-ARIA, would it be ok and not confusing to use role

You'd be limited to these roles, I believe, unless you work with the ARIA group to develop another extension.

I can't say if the usage proposed here is fully in keeping with ARIA, though, as I've never seen roles used outside of HTML/SVG. You're not exactly creating a mapping for the operating system APIs. What you want is to lay structure over a more generic language to enable higher-level navigation. That's kind of in keeping, but beyond my level of knowledge of the goals of ARIA.

@joanmarie and @jnurthen can certainly help with these discussions.

[marisademeglio]

That would be great, @joanmarie and @jnurthen, if you are able to help us out here, we would really appreciate it. Here is a summary thus far:

Background

This CG is preparing a synchronized media format which will cover creating presentations like, for example,

• an HTML document plus audio narration
• an HTML document plus sign language video
• an audio book with fine-grained structure (even if there's no text)

Our format is based on SMIL and describes a presentation as a timeline of media segments. There are no native document structure semantics, as the elements are for things like timing and rendering media.

We would like our format to be able to include document structure information so that user agents can provide a richer experience. For example, an audio book could have pagebreaks, an acknowledgment, examples, footnotes, etc.

Question

If our term vocabularies are WAI-ARIA document structure, landmark roles and DPUB-ARIA, can we use the role attribute?

Example

Our latest draft has an example of what this might look like. (In that example, we have role prefixed as sync:role, which could be replaced with a different namespace if role has one that's more appropriate).

[iherman]

Looking at the latest version of the Sync Media document, which uses sync:role and takes the values from DPUB-ARIA or WAI-ARIA: I am beginning to wonder whether that is o.k.. The values used in DPUB-ARIA, for example, are very accessibility oriented, also in the sense of being used in conjunction with a series of aria-* attributes and related to the accessibility tree. If we use role, would we take over the aria-* attributes into Sync Media, too? Does this all really work?

I am not an expert on ARIA, though.

Note that, as I asked in #35, if Sync Media is a superset of the EPUB Sync Media, then the epub:type attribute can also be used. Would this clash with sync:role? Similar discussion may come up in the EPUB 3 WG at some point. Worth keeping an eye on this, and possibly sync the discussions...

@mattgarrish @dauwhe @wareid @shiestyle

[marisademeglio]

I think we definitely need some outside guidance regarding using role.

I wouldn't think that we would pick up aria-* attributes (I assume you mean the long list under "Inherited States and Properties", e.g. here). In the case that the SyncMedia presentation references an HTML document, those attributes would be covered already, and the role duplication by SyncMedia is a (significant) player convenience. In the case that the SyncMedia presentation has no HTML component (e.g. audio-only but using SyncMedia for sub-toc structuring), I am having trouble mapping the aria-* attributes in a meaningful way.

Regarding a clash with epub:type, if we migrated epub:type to sync:role, there are some terms from the EPUB SSV that have no equivalent role value. I don't know how pressing it is for publishers to be able to mark up their SyncMedia documents with these values -- they didn't make it into DPUB-ARIA so I don't know what that says about their relevance.