Doccheck is reasonably good at previewing a "chessboard" of results. It is targeted at human-generated reports, but it needs to be run manually.

The idea of being able to analyze the docs somehow in tests is relatively recent. It would be great if we were to extract bits of doccheck into automated tests, ones that run on every build. Generating test failures is more practical than the chessboard.

The problem with doccheck is that it checks the output of the documentation, and the error messages are somewhat hard to map to the source code (which is why doclint was created)

Some parts of doccheck need more human intervention and analysis to understand the reports (especially the accessibility checks).

There are three parts of doccheck that are most interesting:

1. The ability to run tidy and give failing tests if we find bad HTML in the generated documentation.
2. Link checking. I would separate this into two categories: Internal links (within the documentation, relatively easy and fast to do) and External links (a lot slower; we could aggregate all references to a link and only check it once so if a URL is bad, we know all the places where the bad URL was referenced).
3. The other tests in doccheck are for bad_chars, doctype, and accessibility.

Additionally, we can look at different link checkers to improve the one we use, or simple rely on doccheck's external link checker going forward.