Consider not including technique-based rules in the recommended set

[MelSumner]

I think if the validator can't determine code structure, it shouldn't throw an error with the documentation support as a WCAG technique.

For example, rule wcag/h63 throws an error if a table element's th elements don't have a scope attribute. However, upon reviewing the code, it's a correctly marked up table element, with no need for a scope attribute.

1. Technique reference page: https://www.w3.org/WAI/WCAG22/Techniques/html/H63
2. The technique explicitly states that the scope attribute is not required if it's a simple table w/headers.
3. There are other techniques listed on that page for additional ways to have valid markup

I recognize that this might be an upstream issue, but extra markup where none is required can create extra issues. Here's the WCAG guidance on techniques: https://www.w3.org/WAI/WCAG22/Techniques/about

[johanrd]

@MelSumner thanks for the issue. Good perspective to bring in, and totally agree that the burden of proof for firing positives should be very high when the transformer can't fully determine the rendered structure.

html-validate actually has an isSimpleTable check that suppresses the rule when, e.g. the number of <th> and <td> elements line up. But we have still generated false positives because our transformer for instance outputs only one <td> per {{#each}} loop. If rendered HTML could be a simple table (without us knowing at validate time), it should not fire positive – burden of proof is on us.

In general, I think the ideal situation is that html-validate's defaults are as close to 1:1 as possible (with some exceptions, no-raw-characters is already smoothed by glimmer, I think). But that requires some surgical suppression whenever the transformer can't fully determine the rendered structure.

For wcag/h63 (and some others) I have released a fix in v0.7.3 that extends a per-element suppression pattern (where e.g. wcag/h32 and wcag/h71 are already suppressed on yield-bearing <form> / <fieldset>). If there are other WCAG-technique rules still firing, please send them over.

We could consider removing some sules the default set if defaults still turn out to be too strict after suppression like the pattern in v0.7.3 (or if we can reproduce in pure HTML we should file upstream issues of course). For the non-default experience we could also consider opt-ins to a possible raw mode where the output can yell all positives (for special audits or if people prefer one-by-one disabling)?