Problem None of the seven text inputs in Code/HomeCustomReport, Code/HomeReleaseNotes and Code/HomeReleaseChanges has a <label>, an aria-label or a title. Their only descriptive text is a prompt placed in the input's own value attribute with class="withTip":
<input id="report-product" type="text" name="products" value="Products..." size="30" class="withTip"/>
Code/Change/ChangeSheet has the same problem in a different shape: it renders each field label as a definition-list term (; Product / : $doc.display(...)), so the label is a <dt> text node with no <label for> binding it to the generated input. Code/ContributorsSheet likewise. Consequence A screen reader announces these as unnamed edit fields, and clicking the visible label does not move focus into the field (WCAG 2.1 SC 4.1.2 Name, Role, Value — failure F68; SC 1.3.1 Info and Relationships; SC 3.3.2 Labels or Instructions). Once focus enters a withTip field, even a sighted user loses the only hint of what it is. The version field is in fact mandatory (Code/EntryVelocityMacros rejects an empty one) but nothing marks it required, so the requirement is only discoverable by submitting and failing. Related, same lines Because the prompt is the input's value and not a placeholder attribute, an untouched field submits the prompt text: products=Products... guarantees an empty report, and version=Version e.g. 8.3-milestone-1... would create a release note page named after the prompt. Moving to the placeholder attribute fixes both problems at once. I could not find withTip handling in the scripts a 17.x skin loads, so the clearing behaviour these fields rely on may no longer exist — worth confirming. Notes Code/HomeCustomReport shows the intended pattern a few lines below the inputs, where the radio labels are real <label> elements whose text goes through the translation bundle. The xform group class in ChangeSheet was also written as .xform (with a leading dot) so the standard form styling never applied; that typo is fixed in commit a14fed4. |
