DPUB spec role definitions should use a standardized prefix such as "dpub-*"

[cookiecrook]

Each of these roles should use the dpub- prefix to avoid confusion and name collision with the main ARIA spec. If they are useful enough for mainstream adoption, we can coordinate the names when the roles are pulled into the main ARIA spec. e.g. dpub-chapter would very likely be adopted as an unprefixed ARIA role "chapter", but "dpub-locator" is still just a link and would likely never be brought into the main spec. Authors can specify these today as role="dpub-locator link" (this is a valid ARIA 1.0 syntax) and the UAs will fall back to the link role appropriately, while still allowing parsers access to the dpub-specific role.

[cookiecrook]

From 9 March 2015: https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0021.html

[halindrome]

This ties into the more generic conversation that PF needs to have about extension specifications. However, it is my intent and belief that any roles in an ARIA extension module that becomes a Recommendation are by definition "in the main ARIA spec". In the same way that HTML5 extensions are in part of HTML5. The PFWG obviously needs to come to grips with this.

Regardless, at TPAC in the joint meeting with DPUB and also in the PF Meeting where this was later discussed the group agreed that the roles introduced in this extension would be closely coordinated with the work on ARIA Core and that they would not need to be prefixed. The DPUB community has heretofore rejected prefixing of roles.

I strongly object to requiring that these or any roles be prefixed as a default state. If a role is clearly domain specific, then it probably make sense. Otherwise, we are just relegating them to a ghetto where they will languish.

[cookiecrook]

The rendering engines do not distinguish between context of roles. Once it's in, it's in. The DPUB roles could be used in non-DPUB contexts (expected and desired), but without the prefix it'd be confusing to authors where the definitive list of roles is for each context, or how to choose the right role for their needs. Many of the DPUB roles (e.g. "chapter") are of broad interest and should be pulled into the main list. Some of the DPUB roles are DPUB-specific (e.g. "dpub-locator" is just DPUB subclass of the "link" role) and therefore would never be in the main list, so they should maintain the contextual prefix in perpetuity.

[cookiecrook]

Otherwise the average web developer is going to be thoroughly confused when to use a "link" role versus when to use a "locator" role. Proliferation of the ARIA API is not a theoretical problem. We already have a lot of confusion around some of the 1.0 roles and attributes.

[joanmarie]

With respect to potential confusion, see issue #43.

I don't think we necessarily need prefixes, but I do think we need to make the intended usage of these roles more clear in the spec. And anything that could be programmatically validated (like a required context role, presence or absence of states, etc.) would be cool.

[richschwer]

One thing we need to be realistic about is that authoring tools are going to inject these semantics in books - not people. Authoring tool manufacturers will not have the same level of confusion. We really need to think about how many authors will be hand editing in these roles. Also, we need to think about how many of these really need to go out to the broader web community vs. being placed in a book.

I don't see the existing dpub semantics going into SVG drawings for example. So, at this point I would not even think about including the dpub semantics in SVG.

[halindrome]

Good point.

Just to argue the other side of this for a minute, if these things are really only used by authoring tools... then who cares what they are named? They could be named 1, 2, 3, and bagel. Am I missing something?

On Thu, Apr 23, 2015 at 8:54 AM, Richard Schwerdtfeger < notifications@github.com> wrote:

One thing we need to be realistic about is that authoring tools are going to inject these semantics in books - not people. Authoring tool manufacturers will not have the same level of confusion. We really need to think about how many authors will be hand editing in these roles. Also, we need to think about how many of these really need to go out to the broader web community vs. being placed in a book.

I don't see the existing dpub semantics going into SVG drawings for example. So, at this point I would not even think about including the dpub semantics in SVG.

— Reply to this email directly or view it on GitHub https://github.com/w3c/aria/issues/36#issuecomment-95593876.

Shane McCarron halindrome@gmail.com

[joanmarie]

But there is nothing preventing web content creators from using these roles. Thus as @cookiecrook stated, it is expected and desired that those content creators will use at least some of them. It would be cool, for instance, to be able to jump to the table of contents in wiki articles.

Given that web content creators might choose to use these roles, and given that we're all sharing the same rendering engines, I myself would like to see additional guidance, required context/owned children, and the like so that web content creators who are considering using some of these roles will use them appropriately.

[halindrome]

Absolutely @Joanmarie - and I am certain none of the editors would disagree either. More guidance is always better!

[klown]

@richschwer

I don't see the existing dpub semantics going into SVG drawings for example. So, at this point I would not even think about including the dpub semantics in SVG.

I can't tell: is the above paragraph an argument for or against the use of a prefix? :-)

[cookiecrook]

@richschwer

One thing we need to be realistic about is that authoring tools are going to inject these semantics in books - not people. Authoring tool manufacturers will not have the same level of confusion.

I'm not convinced either of those assumptions is true.

We really need to think about how many authors will be hand editing in these roles. Also, we need to think about how many of these really need to go out to the broader web community vs. being placed in a book.

This statement seems ambiguous. It may reinforce the point of my objection, or does it? Certainly we can all agree we need to "think about it."

I don't see the existing dpub semantics going into SVG drawings for example.

Why not? Graphic novels? Fixed layout EPUB?

So, at this point I would not even think about including the dpub semantics in SVG.

As Joanie and I mentioned above, they would be included because the same rendering engines render both contexts. There is no separation, and nothing to prevent authors from mixing and matching, which is why I object to the unprefixed values. I think the graphics module should follow the same pattern.

[cookiecrook]

My opinion is to let the publishing experts pick whatever roles and role names they like, as long as there is no risk of collision or confusion with the unprefixed values. If DPUB wants an "dpub-abstract" role, that's fine, but we'd call it "summary" or "tldr" ;-) in the unprefixed list. The rendering engine would then implement the new unprefixed value as an alias like we have currently for the "none" and "presentation" roles.

More examples:

• "dpub-chapter" would likely come straight in as "chapter"
• "dpub-locator" would not be necessary in the main list b/c it's just a "link"
• "dpub-epilogue" and "dpub-afterword" would probably also fall back to "chapter" in the main list, though authors would be welcome to use the prefixed value in a web page context like role="dpub-epilogue chapter"
• "dpub-part" would likely not be brought in as-is to avoid author confusion with the vague name. The existing "region" or various landmark roles may already be equivalent.
• "dpub-biblioref" should just be a link with a rel value, such as <a href="#" rel="biblio"> Again, the link role is already sufficient here.

This pattern allows extension specs to experiment and add prefixed roles unhindered, but still allows the ARIA WG to maintain some level of order over the central list.

[sideshowbarker]

If these DPUB properties are not for ARIA/accessibility purposes, I don't believe they should be using the role attribute to begin with. There's certainly nothing that requires DPUB to use the role attribute; HTML has other extension points DPUB could use for this. I realize that the role attribute was originally intended as a general-purpose extension point but in practice it now might just as well be named "aria-role", because that's where the actual utility of it is now, in the real world, with already-deployed Web content.

But if the other reality is that DPUB spec is at this point likely to succeed in shoehorning these non-ARIA properties into the role attribute, then I believe the best workaround for addressing the conflict is to make them prefixed, as the description of this issue proposes.

[TzviyaSiegman]

Please see minutes from meeting at TPAC at which this decision was made http://www.w3.org/2014/10/30-dpub-minutes.html#item02

[richschwer]

James' concern is that his views were not adequately represented at the TPAC meeting. I see that he was not presented or minuted in the meeting.

[halindrome]

These roles are definitely for ARIA/A11Y purposes.

On Fri, Apr 24, 2015 at 9:34 AM, Tzviya notifications@github.com wrote:

Please see minutes from meeting at TPAC at which this decision was made http://www.w3.org/2014/10/30-dpub-minutes.html#item02

— Reply to this email directly or view it on GitHub https://github.com/w3c/aria/issues/36#issuecomment-95950115.

Shane McCarron halindrome@gmail.com

[iherman]

Mike,

The DPUB IG did consider various avenues, including the HTML extension points. However, the usage of the @role attibute was favoured exactly because it was also bound to accessibility (an extremely important aspect for publishers). This was why DPUB favours this route.

The fact that @role can be used for accessibility as well as other purposes is of a huge value in my view.

Ivan

---

Ivan Herman Tel:+31 641044153 http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)

On 24 Apr 2015, at 16:21, Michael[tm] Smith notifications@github.com wrote:

If these DPUB properties are not for ARIA/accessibility purposes, I don't believe they should be using the role attribute to begin with. There's certainly nothing that requires DPUB to use the role attribute; HTML has other extension points DPUB could use for this. I realize that the role attribute was originally intended as a general-purpose extension point but in practice it now might just as well be named "aria-role", because that's where the actual utility of it is now, in the real world, with already-deployed Web content.

But if the other reality is that DPUB spec is at this point likely to succeed in shoehorning these non-ARIA properties into the role attribute, then I believe the best workaround for addressing the conflict is to make them prefixed, as the description of this issue proposes.

— Reply to this email directly or view it on GitHub.

[richschwer]

@James I am not convinced that authors will be authoring books by hand except in some very isolated places.

[sideshowbarker]

Cc @ljwatson

[LJWatson]

We need to look beyond DPub in this discussion. We need a strategy that will allow us to extend the role taxonomy into the future. It's unlikely that things will stop at DPub and SVG.

If we don't, the role taxonomy is likely to become unusable - either by authors or by the people that create authoring tools. Prefixes seems like a good way to approach things.

[richschwer]

@ljWatson we will be using prefixes for graphics (SVG, Canvas, etc.). ARIA be using prefixes with a "-" separator. On the DPUB ARIA call I indicated that the hyphen would be used for taxonomy delineation as needed. That does not mean we need to use prefixes for dpub but there is not doubt we will need them to prevent name collisions. We are already discussing other taxonomies for assessment and also STEM. WebApps will probably have some too.

[LJWatson]

@richschwer

Thanks Rich, good to know. If we're going to use prefixes for some categories, wouldn't it make sense to do the same for DPub as well?

[richschwer]

The digital publishing community was extremely resistant to using prefixes. Given the extensive use of ARIA coming into digital books I would like to accommodate them. Here are some specifics:

• The education community is adopting ARIA in QTI testing in EPUB books
• The EPUB structural semantics that came out of DAISY was not adopted, in large part because, as the publishers did not want name spaces. This is why they came to the ARIA task force. They also want to use the role attribute to leverage the HTML validator. The DPUB-IG was vehemently against using hyphenated roles for similar reasons.

It is extremely important to me that we facilitate better access to books for all users. I would much rather assist the digital publishing community (as long as they keep the list of core roles small) to put them on the same level as the core aria specification that does not have hyphenated roles.

However, if they plan on growing this much bigger we are going to have to draw a line in the sand and require hyphenated roles. The original EPUB structural semantics spec. was huge and some of the semantics included hyphens which would create other problems that all of us in ARIA are concerned about. So, yes at some point it will make sense to do the same for DPUB.

[mattgarrish]

Why isn't an RDFa model being used if you are going to use prefixes? It seems like a more advanced model than character strings to begin every role name (even when the modules are already encapsulated).

It would also give the ability to define default contexts using initial context documents. If EPUB only wants to recognize core + publishing, it potentially could. If web generally wants to be inclusive of all extensions, equally possible.

Given the distaste for prefixing generally, I don't expect it gets us any closer to a palatable solution, but it would allow for isolation and naming/defining roles as preferable to the community proposing them.

Literal prefixes, second-class vocabularies, no extensibility and roles that get duplicated and changed between vocabularies doesn't sound like it's going to lead to great things.

[halindrome]

Oh. Well, yes. The RDFa model is far superior. No question. And is specifically referenced and endorsed by the Role Attribute specification. However, the people who maintain the validator refuse to allow extensible role values with arbitrary vocabularies. I have gone round and round on this. x:myRole would be great! Built-in extensibility. Built-in ability to follow-your-nose to decode semantics assuming the vocabulary is well defined (as required by RDFa). Yes please.

Hyphens are a silly compromise.

On Sat, Apr 25, 2015 at 11:13 AM, Matt Garrish notifications@github.com wrote:

Why isn't an RDFa model being used if you are going to use prefixes? It seems like a more advanced model than character strings to begin every role name (even when the modules are already encapsulated).

It would also give the ability to define default contexts using initial context documents. If EPUB only wants to recognize core + publishing, it potentially could. If web generally wants to be inclusive of all extensions, equally possible.

Given the distaste for prefixing generally, I don't expect it gets us any closer to a palatable solution, but it would allow for isolation and naming/defining roles as preferable to the community proposing them.

Literal prefixes, second-class vocabularies, no extensibility and roles that get duplicated and changed between vocabularies doesn't sound like it's going to lead to great things.

— Reply to this email directly or view it on GitHub https://github.com/w3c/aria/issues/36#issuecomment-96232923.

Shane McCarron halindrome@gmail.com

[mattgarrish]

Ah, that's what I expected I'd hear, but not having the background thought it was worth asking...

Having to find two ways to express content roles, one for accessibility benefits and another for things not quite necessary to expose, is going to be a hard sell. Publishers will want one attribute, but sounds like validation will prevent that.

[halindrome]

No - it just means if you want to use the validator we either need to 'splain it to the maintainers harder, or use hyphens.

On Sat, Apr 25, 2015 at 11:49 AM, Matt Garrish notifications@github.com wrote:

Ah, that's what I expected I'd hear, but not having the background thought it was worth asking...

Having to find two ways to express content roles, one for accessibility benefits and another for things not quite necessary to expose, is going to be a hard sell. Publishers will want one attribute, but sounds like validation will prevent that.

— Reply to this email directly or view it on GitHub https://github.com/w3c/aria/issues/36#issuecomment-96235496.

Shane McCarron halindrome@gmail.com

[cookiecrook]

All the benefits of name-spacing, none of the validation problems. The core spec could even reserve specific recognized prefixes such as pub-* (maintained by DPUB), g-* or graphics-* (maintained by SVG?), etc.

This also allows for vendor experimentation, too. e.g. shipping "-webkit-foo" prior to standardization for the "foo" role.

[cookiecrook]

@mattgarrish wrote:

If EPUB only wants to recognize core + publishing, it potentially could. If web generally wants to be inclusive of all extensions, equally possible.

That's precisely the idea.

[cookiecrook]

@halindrome wrote:

These roles are definitely for ARIA/A11Y purposes.

Not all of these are for accessibility. As mentioned above, "locator" is just a link and screen readers are unlikely to expose it as anything but a standard link. So what's the point of adding the new role? DPUB wants it for parsing.

That's an okay use for @role in my opinion, but the fallback accessibility role should be maintained: <span role="dpub-locator link"> (accessibility falls back to ARIA 1.0 "link" role)

Or better <a href="#" role="dpub-locator"> (falls back to the native element's implicit "link" role for accessibility)

These examples are valid ARIA 1.0 syntax and would work in browsers today.

[mattgarrish]

The role is intended to be used on an a element. Its purpose is to identify the references back into the content, since those links often come off as meaningless without additional context. Publishers often use a series of linked numbers; for example, at the end of a glossary entry if there are multiple locations in the content to reference. Footnotes often get littered with these links, as well.

If you want to argue that's valueless, that's fine, but there are no parsing requirements attached to it.

[cookiecrook]

@mattgarrish wrote:

...those links often come off as meaningless without additional context.

What context does a sighted user have to distinguish this additional meaning? If it's just a linked number near some other text, a blind user would have all the same distinguishing info that sighted user would have.

[mattgarrish]

I agree it's not optimal for sighted readers -- it's an often-discussed and lamented problem for its ugliness -- but why not start addressing it where and how we can for those who get presented the links?

I don't see harm coming from having rich data, even if it does get largely ignored as you suggest may happen.

[cookiecrook]

If the value and understandability is debatable for sighted users, I don't see value in adding a new role. That just further complicates ARIA adoption, role proliferation, and confusion for authors, implementors, and potentially even users.

[cookiecrook]

If DPUB wants to use it for parsing or to provide some new functionality (inline link reference or something), then we could revisit. If this is just an academic exercise in semantics, let's wait until it's proven its worthiness. Given the author confusion with some of the 1.0 roles and attrs, I think it's desirable to keep the role list as small as possible. Graphics will have some special roles (charts, indeces, etc.) and DPUB has some great ones like chapter and subtitle, but if this is just some minor semantic modification of link, we should keep it a link. The EPUB spec could standardize some rel values for the variants.

We've gotten off-topic. Back to the prefixing debate?

[mattgarrish]

We should probably give people's inboxes a break until the call... ;)

Enough positions have been stated on prefixing of this particular vocabulary that I don't expect we'll resolve it before then.

[richschwer]

+1

[sideshowbarker]

I don't see harm coming from having rich data, even if it does get largely ignored as you suggest may happen.

There's been a lot of discussion over many years about why it’s harmful to put invisible metadata into a document if it’s metadata that is largely just going to end up being ignored or unused. I won’t try to summarize all the arguments against it here but instead hope my assertion that many people including me do actually find it harmful can be accepted as an additional data point in this discussion.

[sideshowbarker]

If the value and understandability is debatable for sighted users, I don't see value in adding a new role. That just further complicates ARIA adoption, role proliferation, and confusion for authors, implementors, and potentially even users.

If DPUB wants to use it for parsing or to provide some new functionality (inline link reference or something), then we could revisit. If this is just an academic exercise in semantics, let's wait until it's proven its worthiness. Given the author confusion with some of the 1.0 roles and attrs, I think it's desirable to keep the role list as small as possible.

I strongly agree with these points from @cookiecrook and believe that they align well with the design principles that have guided the development of the HTML language over its entire history and in particular over the last 10 years or so during the development of HTML5.

I think any related work should try very hard to align with those design principles unless there’s a really compelling reason to break away for some very particular case.

[sideshowbarker]

We've gotten off-topic. Back to the prefixing debate?

The prefixing proposal should also be considered in light of design principles that have guided other work on the Web platform, and precedents set by years of previous work in other groups.

The use of prefixes is cases like this is something with many years of precedent behind it.

In this particular case, the use of the dpub- prefix seems to me to be in part an indication that there's not yet wide agreement about all of these new DPUB role values being completely necessary. It’s a concrete way to indicate that they're being provided for real-world use while still under consideration (I would hope at least) for at least some of them to eventually become part of the standard core set of ARIA role values defined in the ARIA spec itself.

But if the anticipation is instead than none of these would ever become a core part of ARIA itself, then I’d suggest they not be made valid at all, even if prefixed.

I don't believe the role attribute should be used for open-ended experimentation with values that have no chance of ever becoming part of core ARIA.

We know the ARIA spec leaves it up to each host-language spec to determine what restrictions each language wants to place on the use of the role attribute. And in the case the HTML language at least, the HTML spec by design very intentionally restricts use the role attribute in a way that's very different than, say, the class attribute or data- attributes or whatever other similar sorts of extension points the platform provides for open-ended use.

[mattgarrish]

I don't see harm coming from having rich data, even if it does get largely ignored as you suggest may happen. There's been a lot of discussion over many years about why it’s harmful to put invisible metadata into a document if it’s metadata that is largely just going to end up being ignored or unused.

In my defense, that part of the discussion was around a claim that the publishing roles would not get supported outside of publishing.

My hope and expectation is that they would, but, my return question was: if they are not, is it harmful to have the role there and ignored as some extra semantic information outside of the contexts that support it? How do we know support won't grow if we can't even try?

I wasn't suggesting we would pollute documents with information for no purpose. Calling it "rich data" probably distracted from that question in hindsight.

The roles we've proposed have the goal of providing more meaningful structures for navigation and consumption, which has been their use in DAISY and EPUB. Identifying the context of the book allows for quick navigation to key locations; it allows for intelligent UI (footnotes, go to print page equivalent functionality, announcement of current location, etc.); it allows, perhaps most importantly, for readers to follow the logical reading order and skip over all the secondary content that clutters the markup.

[TzviyaSiegman]

Thank you for your feedback. This issue has been resolved by editing the document to comply with the rules for extending ARIA (https://www.w3.org/WAI/PF/wiki/ARIAExtensions).