Matt Garrish

This may be where ISO comes in, then. I don't believe we have any problems getting an erratum done there, so maybe the compatibility section we ultimately add to 1.1...

> The accessibility summary adds additional information that cannot be obtained by the other accessibility metadata. Right, otherwise the summary would potentially be a redundant duplication of everything these guides...

Isn't the problem that they're an extension of HTML that isn't formally recognized by HTML itself? (i.e., the validators have been modified to allow the attributes even though the standard...

> Remember when we discussed with [@sideshowbarker](https://github.com/sideshowbarker) on the HTML alternative of `epub:type`, and we got to `epub-type` as the way to go? Right, but that would be to make...

> but, afaik, there much more... That's not the definitive list, though. Each element defines what it allows through its accessibility considerations section. Those lead you to the HTML in...

> Would you raise an issue or should I? You've raised it here so feel free to open the spec issue, too... 😄 > Shouldn't we list that as acceptable...

Sorry, I forgot to mention that the result file (resource.feature in the parent directory) also needs changing because there's an additional non-preferred media type - it's bumped from 6 to...

> We need a different media type and I assume not a completely fake one. The best I can find is to switch it to `application/x-font-woff` and replace the font...

There are some brief instructions on building epubcheck in the [repository's readme](https://github.com/w3c/epubcheck?tab=readme-ov-file#building-epubcheck).

> Currently, section [2.3 Non-accessibility metadata](https://www.w3.org/community/reports/publishingcg/CG-FINAL-a11y-display-guidelines-20250422/#non-a11y-meta) says: Having contradictory information potentially not even near the accessibility section doesn't seem like effective placement. A vendor shouldn't be saying that content is...