You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found this specification while reading the EU standard EN301549, which (in version 3.2.1) states that "It is best practice to provide meta data on the accessibility of the document within or separate to the document using WebSchemas/Accessibility 2.0". The reference points to a W3C wiki page, which in turn guided me to this Github instance.
The EN 301549 is tightly connected with EU regulation via the Web Accessibility Directive (WAD), and the standard is relevant even in many countries outside of the EU. The a11y-discov-vocab should earn at least some credibility and momentum thanks to the multiple references from the latest version of the EN standard, even if the references are only "best practice" and only indirect via the w3c wiki page!
One of the central requirements in the WAD is that all public sector bodies must provide an accessibility statement for each of their websites and apps (including documents such as PDF files that may be distributed there). It would therefore be useful if the metadata schema pointed out in the EN standard could be used to communicate the URL of the mandatory Accessibility Statement. However, I cannot find a suitable property for this in the specification. I guess I could use schema: accessibilitySummary (https://w3c.github.io/a11y-discov-vocab/#accessibilitySummary ) and put a URL as part of a text field, but having a separate, typed, property such as eg. "schema:accessibilityStatementURL" would be more useful. (Easier to use for automated retrieval, automatically presented as a clickable link, possibly with a standardized symbol, and so on..)
Would you be interested in adding such a property to the specification?
Or, perhaps there are other better options for indicating the location of a relevant Accessibility statement? Is there already a standardized metadata schema for pointing out the location of VPATs, that could be used? (I haven't been able to find one, but it could exist.) Or, a standardized path (part of URL) could be another alternative, similar to how the "/robots.txt" path can be expected to contain site-owners preferences for automated indexing. But for downloadable items such as pdf files a standard metadata element would be a better option since it is not always apparent from what site the file came.
The text was updated successfully, but these errors were encountered:
And, by the way, it would be nice if the specification contained just a small note about its relation to the "WebSchemas/Accessibility 2.0" spec mentioned in the EN301549. So that people following the same path that I followed may get a confirmation they have not gone astray.
Perhaps a comment in the Acknowledgements section, or even in the Change log if this specification can be considered a newer version.
However, I cannot find a suitable property for this in the specification.
No, the metadata was originally developed to describe the properties of the content, not for reporting purposes, and getting new properties into schema.org can be a challenge. For EPUB, we ended up defining our own vocabulary of properties to work around this issue. The certifierReport property serves the purpose you describe, and can be used outside of EPUB. It's just not likely to be widely known or recognized.
A reporting link could be standardized in schema.org or it could be made more broadly available in W3C, perhaps in collaboration with the WCAG folks since they also have a reporting need. To date, the property we defined has served its purpose, so there hasn't been a push to standardize it further.
And, by the way, it would be nice if the specification contained just a small note about its relation to the "WebSchemas/Accessibility 2.0" spec
Hi!
I found this specification while reading the EU standard EN301549, which (in version 3.2.1) states that "It is best practice to provide meta data on the accessibility of the document within or separate to the document using WebSchemas/Accessibility 2.0". The reference points to a W3C wiki page, which in turn guided me to this Github instance.
The EN 301549 is tightly connected with EU regulation via the Web Accessibility Directive (WAD), and the standard is relevant even in many countries outside of the EU. The a11y-discov-vocab should earn at least some credibility and momentum thanks to the multiple references from the latest version of the EN standard, even if the references are only "best practice" and only indirect via the w3c wiki page!
One of the central requirements in the WAD is that all public sector bodies must provide an accessibility statement for each of their websites and apps (including documents such as PDF files that may be distributed there). It would therefore be useful if the metadata schema pointed out in the EN standard could be used to communicate the URL of the mandatory Accessibility Statement. However, I cannot find a suitable property for this in the specification. I guess I could use schema: accessibilitySummary (https://w3c.github.io/a11y-discov-vocab/#accessibilitySummary ) and put a URL as part of a text field, but having a separate, typed, property such as eg. "schema:accessibilityStatementURL" would be more useful. (Easier to use for automated retrieval, automatically presented as a clickable link, possibly with a standardized symbol, and so on..)
Would you be interested in adding such a property to the specification?
Or, perhaps there are other better options for indicating the location of a relevant Accessibility statement? Is there already a standardized metadata schema for pointing out the location of VPATs, that could be used? (I haven't been able to find one, but it could exist.) Or, a standardized path (part of URL) could be another alternative, similar to how the "/robots.txt" path can be expected to contain site-owners preferences for automated indexing. But for downloadable items such as pdf files a standard metadata element would be a better option since it is not always apparent from what site the file came.
The text was updated successfully, but these errors were encountered: