search

daisy / ace

Ace by DAISY, an Accessibility Checker for EPUB
MIT License
75 stars 22 forks source link

Update new accessibilityFeature vocabulary list with ARIA #369

Closed clapierre closed 2 years ago

clapierre commented 2 years ago

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.

danielweck commented 2 years ago

Fixed via https://github.com/daisy/ace/commit/327f267172d1ae0d9feb0db6a8f7df573a631588

danielweck commented 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?

danielweck commented 2 years ago

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

clapierre commented 2 years ago

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?

mattgarrish commented 2 years ago

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.

danielweck commented 2 years ago

Thank you for your quick feedback. I downgraded the "violation" severity from moderate to minor ( https://github.com/daisy/ace/commit/c44670569035e464451e2fb741a9bf1681fb8d95 )