Mismatch in the accessibility references in the current text and schema...

[iherman]

The current draft says:

The infoset SHOULD include a link to an accessibility report when one is available for a Web Publication. It is RECOMMENDED that the report be included as a resource of the Web Publication.

which suggests that the acceessiblity report is more a structural property (i.e., linking out to a full report) rather than descriptive. This is in contrast with the discussion in Toronto where accessibility was listed as a descriptive property

Cc @avneeshsingh @GeorgeKerscher

[iherman]

My proposal would be to allow for both: recommend the usage of the accessibility terms of schema.org but, also introduce a structural property for an accessibility report.

[laudrain]

Structural properties are supposed to "express key structures" (https://www.w3.org/TR/wpub/#infoset-expl).
Personally, I don't see accessibility metadata expressed in a report to be "key structures".
But more as giving global information on the accessibility state of the publication.

[iherman]

@laudrain: the properties described in schema.org (see also the relevant wiki page) may be enough then, at least in the core manifest. If so, the description of the infoset item may have to be changed...

[laudrain]

@iherman: you mean that "linking out to a full report" implies "structural property" ?
But it could also be "extensibility" as links to other "metadata records" are in 3.5 Extensibility.
Then the proposal could become:

• a11y properties in schema.org in 3.3 Descriptive properties
• link to the full a11y report in 3.5 Extensibility
  What do @avneeshsingh @GeorgeKerscher think?

[iherman]

Yes, that is an alternative, too.

[GeorgeKerscher]

Hi, Sorry for being so slow to respond, but DAISY meetings in Germany. I believe this is descriptive in nature about the publication. However, there should be metadata about the publication that is carried in the publication. So, from that perspective, would it be a resource, but not in the reading order? Best George From: Ivan Herman <[email protected]> Sent: Monday, June 11, 2018 5:19 AM To: w3c/wpub <[email protected]> Cc: George <[email protected]>; Mention <[email protected]> Subject: Re: [w3c/wpub] Mismatch in the accessibility references in the current text and schema... (#216) Yes, that is an alternative, too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3HSJc9tnDc7vjGRJ5Uk405Cvn0hAm7ks5t7lJAgaJpZM4UiRKS> . <https://github.com/notifications/beacon/AG3HSK151WIzU_v3imDriyyjdHeECjYVks5t7lJAgaJpZM4UiRKS.gif>

[iherman]

@GeorgeKerscher this may then be another example for the separate 'list' discussed in #225. Which is perfectly fine, it only requires to define another 'rel' value to identify that this is a report, and the rest falls out painlessly...

[avneeshsingh]

The accessibility metadata is mostly for discovery. The external report provides felexibility beyond schema.org accessibility metadata. It can also have ONIX codes in it.

I think that we are discussing the list of resources and not resources in default reading order. So, does the recommendation to include accessibility report in list of resources create any major problem?

[iherman]

I think that we are discussing the list of resources and not resources in default reading order. So, does the recommendation to include accessibility report in list of resources create any major problem?

No:-) The only reason I raised this is when mapping the infoset onto the manifest, we end up with two different things:

1. usage of the schema.org accessibility terms that you know very well
2. the possibility to add link to a separate accessibility report

And my only question was whether it is all right to have both. I have the impression that we are fine having both indeed...

[avneeshsingh]

Indeed.

[clapierre]

Yes we would want to have both, as ONIX currently doesn't support all of the new accessibility metadata for conformance and discovery but does allow for a link to a report which would include anything it currently does not support, so having both would be ideal.

[iherman]

Changing this to editorial, I think we have an agreement