Relationships Detectable

cstrobbe's proposal in #166 would require that elements used with their native roles be nested according to the content models in their specifications, plus a fourth clause barring links, interactive elements and keyboard-focusable elements as descendants of links. He worked through seventeen code examples (numbered 1 to 16, then 19) showing where a syntax reading of 4.1.1, a validation reading, and the proposal each land — button wrapping an anchor, li inside a div inside a ul, p as a sibling of li, h2 wrapping p. JAWS-test called it exactly what was needed and asked that it also cover ARIA and PDF tags, noting that correct nesting is what lets a screen reader report that a table has 3 columns and 2 rows and that you are in column 2, row 1. JAWS-test cited EN 301 549 clause 11.5.2.9 and Section 508 502.3.7, both of which already require parent-child relationships to be programmatically determinable.

patrickhlauke would rather see 4.1.1 updated normatively in a backwards-compatible way than patch around a poorly interpreted criterion, warning of weird overlaps where one SC is a stricter special case of another. yatil proposes extending 4.1.1 to "markup languages and associated extensions as they relate to accessibility features" and dropping the well-formedness framing from the Understanding document, or alternatively removing 4.1.1 entirely per w3c/wcag#2676. scottaohara agrees: use 4.1.1 for what people think it is for, unless "elements are nested according to their specifications" does not actually mean that. patrickhlauke also argues the singling out of links is arbitrary, since buttons and other controls have the same problem.

bruce-usab says it is bad to retcon a standard and refuses scottaohara's "use 4.1.1 for what people think it's for" framing; GreggVan agrees and adds that 4.1.1 should be clarified to mean what the working group meant when it was written, not what people later want it to mean. bruce-usab separately notes the proposal arrived too late for WCAG 2.2. cstrobbe's own reply is that the intents differ: 4.1.1 is about a user agent building an unambiguous parse tree, while his proposal is about name, role, state and value being exposed unambiguously through an accessibility API, which puts it closer to 4.1.2.

detlevhfischer's #194 proposal caps the gap between a label and the element it labels at twice the smaller of the labelled element's width or height, illustrated with a 16 px-tall field passing at a 32 px gap and failing at 33 px. He later revised it to four times the smaller dimension of the label itself, to escape the problem that the original formula breaks for textarea. mraccess77 defends the need against demands for evidence, pointing out that the SC 3.3.2 Understanding document said in 2008 that labels close to their field help screen-magnifier users, that G162 already exists, and citing Nielsen Norman Group material on proximity and form white space; to the argument that proximity gaps are a common pattern he answers that "because something is a common pattern doesn't mean it's a correct pattern."

jake-abma checked with designers and reported that almost all current forms would fail and that the calculation is too prescriptive for design aesthetics, and that the measurement scheme — four times, three times, widths, heights, mixed elements — is too complicated for designers, developers and testers alike. awkawk points to the very common pattern of left-aligned labels against aligned fields, where varying label length forces varying gaps, and says disallowing a common pattern requires clear evidence. alastc notes the proposal would fail the GOV.UK Design System text input with hint text, and asks what happens when an error message is inserted. patrickhlauke finds the loophole immediately: a designer could make fields excessively tall purely to buy leeway to push the label further away, defeating the point while passing; he also asks for hard proof that larger gaps harm particular users rather than the working group making things up. detlevhfischer concedes the exception list grows until the original requirement is lost, and that focusing on label-to-control catches only a subset of the proximity problems he has seen in low-vision user testing.

In #451 GreggVan argues that if a relationship is not presented to anybody, it is unclear what the requirement is getting at, and that without scoping there are a million ways elements can be related and all of them would have to be conveyed programmatically; he proposes narrowing it to "when relationships of meaning between elements are presented visually, they are also conveyed programmatically." giacomo-petri opened the issue acknowledging the tests are incomplete and that the requirement must either gain sufficient tests or state its applicability clearly. adampage's specific gaps are error messages and help text for form controls, and tables with headers, bodies, footers, data cells and header cells — questions that arise precisely because the written tests are so narrow.