Closed clapierre closed 2 years ago
Currently Ace reports this unknown value as a "moderate" error. Unknown values not in our current vocabulary list should be marked as informational as the lists aren’t restricted to the vocabulary.
Hello Charles, should Ace report "minor" violations for unknown values only for the accessibilityFeature
metadata, or other properties too?
The reason I am asking is because the specification is not clear about extensibility: https://www.w3.org/2021/a11y-discov-vocab/latest/CG-FINAL-a11y-discov-vocab-20220610.html#accessibilityFeature
Yes I think it should report these as minor violations because the author usually has made a typo say in accessMode instead of "auditory" they used "audio". So I think this should go beyond just accessibilityFeature and should be included for accessMode accessModeSufficient accessibilityHazard as well as accessibilityFeature
Now conformsTo has changed from a URL now to a default set of tags, but I believe we still allow for the URL approach so that might be more difficult to check, and as new HTML specifications get released we probably don't want to have to keep updating this list of valid tags but I will let others weigh in on that debate. @mattgarrish thoughts?
The schema.org definitions only recommend the vocabulary; for example, for accessibilityFeature it says:
Content features of the resource, such as accessible media, alternatives and supported enhancements for accessibility. Values should be drawn from the approved vocabulary.
This is in keeping with how schema.org metadata works -- they often farm out maintenance of vocabularies for properties, like ours, but they don't make restrictions only to the formal vocabularies.
That's why we should keep the severity level low. As @clapierre says, an unknown term could be a typo, but it could legitimately also be a new term that hasn't been standardized yet. We don't want to block people from using new terms.
We may want to add some more info about this to the section on extending the vocabulary. Right now it focuses on creating more specialized values, not entirely new ones.
Now conformsTo has changed from a URL now to a default set of tags, but I believe we still allow for the URL approach
Well, the bigger issue with validating that field is we don't have exclusive control of it. Anyone can list other conformance statements, so I don't know how you'd ever reliably know if there's a typo or not.
In any case, conformance metadata is a bit outside the scope of Ace, as I wouldn't expect it to be there when a user is still evaluating. It's probably better for Ace not to report anything, as if users got a message that an expected conformance string wasn't found it might make them think Ace is telling them their publications are fully conformant.
Thank you for your quick feedback. I downgraded the "violation" severity from moderate to minor ( https://github.com/daisy/ace/commit/c44670569035e464451e2fb741a9bf1681fb8d95 )
We have deprecated the use of accessibilityAPI to include "ARIA" and have moved this to accessibilityFeature instead.
Currently Ace reports this unknown value as a "moderate" error. Unknown values not in our current vocabulary list should be marked as informational as the lists aren’t restricted to the vocabulary.