Publisher contact for additional accessibility information

[mattgarrish]

Issue on the “EPUB Accessibility 1.1” Recommendation

Describe the problem

There currently isn't a way to provide a publisher contact email to request additional information about a publication. In ONIX, for example, this information can be expressed in List 196 Code 99.

Describe the fix or new feature you propose

We should consider adding a new property to the accessibility vocabulary to express this information, such as a11y:publisherContact.

[mattgarrish]

FYI, schema.org has a contactPoint property under Organization. If we use dc:publisher as an equivalent of schema:publisher we could use this property, but it would lead to some ugly hacking and refinement chaining:

<dc:publisher id="pub">Acme Publishing</dc:publisher>
<meta property="schema:contactPoint" id="pub-contact" refines="#pub">https://schema.org/ContactPoint</meta>
<meta property="schema:email" refines="#pub-contact">[email protected]</meta>
<meta property="schema:contactType" refines="#pub-contact">accessibility</meta>

I have no idea what the value of schema:contactPoint could realistically be, as it's supposed to group the other two properties. Dropping in the URL of the schema.org type it expects is just a hack. But if we keep on hacking we could take it out and have:

<dc:publisher id="pub">Acme Publishing</dc:publisher>
<meta property="schema:email" id="pub-email" refines="#pub">[email protected]</meta>
<meta property="schema:contactType" refines="#pub-email">accessibility</meta>

But I'd personally leave this kind of solution for the day when we have a better metadata framework. It's not valid without a lot of massaging back into schema.org form and it adds a lot of needless work to walk the refines attributes to figure out what you're dealing with.

[clapierre]

I agree Matt, and who knows they may use that metadata for some other reason not specifically for accessibility related questions, vs. editorial questions like "Why is Page 23 repeated twice?"

[mattgarrish]

After discussing this in the call today, there are two options we can consider.

The first is to create an individual named property like a11y:publisherContact. An example of the markup would be:

<meta property="a11y:publisherContact">[email protected]</meta>

The primary benefit of this approach is simplicity. It doesn't require chaining metadata statements together to figure out if you have the right piece of information. The con is that there are two other onix accessibility contact fields that could be useful to add in the future, so we'd have to keep adding new options for each.

The second option is to use the refines attribute with a property like role, allowing for a more generic name like a11y:contact. The markup for this could be:

<meta property="a11y:contact" id="contact">[email protected]</meta>
<meta property="role" refines="#contact">publisher</meta>

The pro of this approach is that it only needs one property. The cons are that it relies on refines, and we know people often omit it, and that it would require defining an additional set of values for the role property. It would also require changing role so that it can modify other meta tags.

[clapierre]

@mattgarrish maybe add additional role's here that are being considered as there is only 1 currently "publisher" and it may not be clear the advantage of one over the other.

[mattgarrish]

For a trusted intermediary, the single property option might be

<meta property="a11y:trustedIntermediaryContact">[email protected]</meta>

And the role option:

<meta property="a11y:contact" id="contact">[email protected]</meta>
<meta property="role" refines="#contact">trusted intermediary</meta>

(I recall three contacts being mentioned, but when I look at code list 196 I only see trusted intermediary as another contact. If someone knows of another, feel free to add.)

Edit: fixed the property name in the role option.

[mattgarrish]

The decision on the task force call today was to add properties for both publisher and trusted intermediary contacts.

[iherman]

This was discussed during the pmwg meeting on 29 May 2025.

View the transcript

Implementation details of EPUB metadata for publisher contact.

<AvneeshSingh> w3c/epub-specs#2702

AvneeshSingh: should we be using role or another dedicated metadata

mgarrish: I'd go with minting our own new property - using refines is too complicated

AvneeshSingh: agree

---

[mattgarrish]

I'm wondering if we have enough information to make this change yet. I started to add the two properties yesterday, but aside from who the email belongs to there's no difference between them.

Some questions that led me to include:

• is it ever the case that a publication has both a publisher and a trusted intermediary contact, or should you only set one or the other?
• in the display guide we were only asked about display the publisher contact, so is it even common that trusted intermediaries are specified?
• do we plan to display both the publisher and trusted intermediary contacts if they're present or only select the publisher?
• do we plan to differentiate who the email goes to or do users even care about this? (i.e., would the contact always have a generic lead in like "For additional information please contact: [email protected]" regardless of who it goes to?)
• do we plan to plan to display the email address directly or make it a mailto: with the publisher or trusted intermediary's name as the link?

Depending on how we answer these questions would change whether we need one or two contact properties, and whether we'd need another property to name the trusted intermediary. Going strictly by what we do for onix right now, we only need to capture the publisher contact.

[GeorgeKerscher]

I know the term trusted intermediary from its use with the Accessible Books Consortium (ABC) where they sign up libraries serving persons with disabilities as trusted intermediary who provide content to people registered with the library.

I do not think that this term would apply to published information from a publisher. I think of a department within a publisher that can handle accessibility questions. If there is no accessibility contact, the person would contact the publisher through their main contact. I think that if there was an accessibility contact, the connection would be more direct.

[mattgarrish]

That's what has me wondering if we really need two properties for this or if that's making a semantic distinction that never makes it to the end user. Is there always just a single contact email and it goes to either the publisher or a trusted intermediary?

If so, do we really need two new properties?

When I looked at the onix techniques, it only accounts for displaying the publisher contact and ignores trusted intermediaries, which makes me worry that we still need to put some thought into the display of this metadata before we jump to adding the properties.

[GeorgeKerscher]

If trusted intermediary meaning is the same as in ABC, I do not know why it would be in the publisher's metadata. Perhaps check with ONIX experts for clarity. @[email protected]

Hopefully this will get to Chris; I don't think he is listed in this repo.

[mattgarrish]

Right now the plan is to not use the refines attribute so these would be contact emails for the publication and not tied to other metadata.

If the property is a11y:contactEmail, for example, then we could use one email to capture who to contact, whatever their role.

We can make two properties and name one for the publisher and one for the trusted intermediary, but if we're giving trusted intermediary contact information do we need to tell the user the name of the trusted intermediary, too, or just give an email address? And, again, is it ever the case that we would present two contact emails to users or is that just going to confuse them?

[iherman]

This was discussed during the pmwg meeting on 04 September 2025.

View the transcript

Publisher contact for additional accessibility information: Issue #2702

<AvneeshSingh> w3c/epub-specs#2702

mgarrish: we don't have a way to put in contact info for metadata.
… in display guide we don't account for 2 fields we have publisher / trusted intermediary contact. Do we need 2 contact fields for EPUB maybe an accessibility contact field. not sure when you would have 2 contacts. why contact the publisher or the intermediary, did we ever try to display this in the display guide but maybe only this is in ONIX. what are we accounting for here? Why don't we display trusted intermediary's. What are

we expecting for a11y contact email 1 field, 1 value and we don't care which it is.

AvneeshSingh: maybe EAA has a part in this.

George: in WIPO they have a trusted intermediary. from our perspective the publisher contact would be the one we would want to display.

gpellegrino: I agree that is the data we are using in the ONIX techniques. publisher contact. 1 contact field generic could be a specialized library just a11y contact.

AvneeshSingh: MTM in Sweden is assigned as supervisory agency for implementation of EAA for eBooks, in such cases the contact of such supervisory agencies would be prefered. So, it would be good to have a generic field for email.

mgarrish: a11yContact or something like that. that works. I need to check the display guide but if the display guide may need to be updated since it might call out the "publisher" specifically I can create a new issue for that if thats the case.

---