suggestion: can we avoid the use of "mm" here? this otherwise starts us once again down the path of confusion around "mm" in CSS vs real-world measures. i know this is about the ratio/proportion, rather than the actual unit of measure, but if we have to settle on some unit, then "px" would seem the most natural to me.

also, i do have concerns that these sorts of very restrictive SCs will not resonate all that well with designers/developers, and would suggest targetting this at AAA

mm > px: done. Agree that it might feel quite restrictive for designers, and I therefore tried to be fairly tolerant in the proposed gap measure. It just really is an issue that I have seen reapeatedly in user testing with LV users. If taken further, it might end up riddled with exceptions as was the fate of target size, and may well end up at level AAA.

It isn't an uncommon design approach to make a set of field labels align on the left and to also make the fields aligned, and since the labels vary in length the gap between the field and the label varies as a result.

https://s7641.pcdn.co/wp-content/uploads/2018/09/form-layout-reset-button.png

I suspect that this is common enough that we will have questions about how we justify this as a sufficiently problematic practice that we are proposing an SC to address this. I'm not saying that it isn't, but an SC like this is not absolute like some others (e.g. page title, text equivalents, form label association) and as a result we need to build the case for it using clear evidence.

@awkawk like any of the SC clear evidence can only be gained through research. We have a chicken and egg issue when we have experience that shows and issue but limited formal research. I'd question whether there is clear evidence that page titles today are still as useful given that some browser's hide them from the user or cut them off and for most of us they aren't visible unless on hover with so many tabs open that we instead generally visually focus a header or heading 1 to identify the page.

I'd also mention that the understanding document for SC 3.3.2 states
"Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page." So even in 2008 we had evidence to state this.

We also have G162: Positioning labels to maximize predictability of relationships

Some possible resources
https://www.nngroup.com/articles/closeness-of-actions-and-objects-gui/
https://www.nngroup.com/articles/form-design-white-space/

The example you provided is a prime example of the issue -- because something is a common pattern doesn't mean it's a correct pattern.

@mraccess77 I agree with much of your comment, but still feel that if we are going to disallow a common pattern we need to have good evidence that it is a problem.

I suspect that the difference in presentation of the page title has changed more for low vision users than it has for screen reader users. If the experience has changed for screen reader users then we should be rethinking page titles also (perhaps in Silver).

I don't dispute the concept that proximity of information is important. This is a very clear concept and I believe that everyone can see how this impacts people. The challenge is in determining how close is close enough because that is what we need to make it testable.

I think that we should be assembling the information on the impact of zooming/magnification so we can try to have a reasonable and helpful metric. We need to understand what the goal is - is it to be able to see the full label and full input at some magnification? Is it to be able to see the full label and part of the input at some magnification? What magnification? What if the label is really long? It is a hard problem and will never work in all situations but we need to have enough information to draw a justifiable line.

just picking up on this aside about page title:

I suspect that the difference in presentation of the page title has changed more for low vision users than it has for screen reader users. If the experience has changed for screen reader users then we should be rethinking page titles also (perhaps in Silver).

just on that aspect, i'd also note that the concept of a "page title" itself makes the SC mostly non-applicable to anything other than web pages (like native apps for instance). which is not necessarily a problem, but...in general, it's best to generalise the idea rather than keep a tech-specific language. for instance, for native apps, i've tended to interpret this very widely as "there's something on the screen that gives the user a hint/idea about where they are within the app / what the purpose of the current view/screen is"

And back to main topic:

I don't dispute the concept that proximity of information is important. This is a very clear concept and I believe that everyone can see how this impacts people. The challenge is in determining how close is close enough because that is what we need to make it testable.

I think this is again one of those situations where we'd like to say "use common sense, make sure it's close enough to suggest a relationship", but due to the binary pass/fail requirement for a hard testable thing, we're going to end up with some arbitrary line in the sand which will be less and less easy to justify in absolute terms. And as an aside, note that even when it comes to guidelines like Apple's ones for iOS apps, it's usually couched in very reasonably could/should type requirements, and that Apple and co themselves often feel quite free to ignore their own guidelines, as they're not completely absolute. A luxury which we unfortunately don't have with WCAG in its current form...

Now, also looking at the prototype diagrams that Detlev provided (and a tiny note: it says "height" where it should say "width" on the horizontal), and looking for an easy loophole...what if a designer made fields excessively/unnecessarily high, just to give them sufficient leeway to then move the label further away? It would defeat the purpose/advantage for LV users, but allow authors to claim conformance...

@patrickhlauke

what if a designer made fields excessively/unnecessarily high,

Not likely to happen, IMO
I fixed the width/height typo in graphics, thanks for pointing it out.
And now realising that the formula doesn't work for textarea...

Not likely to happen, IMO

the amount of times i've seen very creative interpretations of normative SC text to find loopholes/get around restrictions/do the absolute minimum necessary to "pass" WCAG rather than actually fulfilling the spirit/reason for SCs...

I think this proposal would fail a very usable pattern where there is hint-text between the label and input. E.g. https://design-system.service.gov.uk/components/text-input/#hint-text

And what about when an error message is added?

@alastc True. Its always the same, the list of exceptions is growing to the point where the original requirement gets lost. It is just a first stab, perhaps there are better metrics - if this goes anywhere.

Its always the same, the list of exceptions is growing to the point where the original requirement gets lost.

I think, particularly once requirements move towards more layout/design type questions, that this is unavoidable, as it's trying to impose some rigid binary rules to something that often "depends" quite heavily on context/situation. Wondering if going forward, there's a chance (perhaps with Silver, or with a separate note/best practice type document separate from WCAG itself) to introduce more high level recommendations that may require a more nuanced, though admittedly subjective, assessment (though of course that will then likely result in more diverging results)

Thinking more - perhaps we could include associated information? I.e. that extra info and error messages are part of the whole, so there shouldn't be a gap greater than X, but there could be more content between labels and inputs.

I think ‘label’ could be defined to include associated info incl. generated error messages - I am going to propose a rewording. To make the metrics less dependent on the size of the element labelled (think textarea elements) it may be better to base the gap requirement on a multiple of the text size OR smaller dimension of the label (in case the label is an icon or similar). I agree with Patrick that this is a hard one and may end up being seen as too prescriptive - but recognising the importance of the issue for LV people, I would still like to iterate a bit on it.

It had been mentioned already by Patrick and Andrew in this issue, but after some checks with designers I received word that they will not meet such a SC with the calculation suggested. It means almost all current forms will fail and is too prescriptive for the design aesthetics. Proximity is on the agenda though and they do agree to take it into account. Looking forward to the next iteration @detlevhfischer ... :-)

as an initial minimum, perhaps the idea of proximity could start with the idea that an element must be present/visible (at least in part) in the viewport, even at "mobile" sized viewports (320 CSS px width / whatever the vertical CSS px height equivalent would be)

i'd also say that it would be good to have some real hard proof/rationale that shows that larger gaps can be a problem for particular users, and it's not just the WG making things up

M rephrasing would be:

Label gaps

When one element acts as a label of another element, the gap between the two is no larger than four times the width or height of the label (whichever is smaller).

I am not happy with this, I just think it might be worth iterating to see if we can arrive at something that ends up being mesurable and widely implementable. The reference to the label height (could also be an icon labelling a field) removes the problem that exisits for textareas in my initial attempt.
But the new problem is getting at a meaningful value for label height. An approximation would be text-size in px for text labels and px dimensions (smaller dimension) for icons. But this is not pretty.

Two updated images:

Alternative text: The image shows two instances of the label "Search" to the top-left of a text input. The upper half shows a PASS condition (label gap below label-height * 4) the lower half a FAIL condition (label gap greater than label-height * 4)

Alternative text: The top half of the image shows the label "First name" to the left of a text input. The label gap is below label height * 4 so it is a PASS condition. The bottom half shows a textarea and a label "Comment:" to the left of it. This is a FAIL condition (the gap between label and textarea is greater than label-height * 4).

As to evidence: I have encountered this more than once in tests with LV users, but now that I go back to actual cases, some issues were more generally about gaps (e.g. between menu item and correlated element to disclose submenu) see link above in #673 (comment) or misleading proximity inferences as in section „Spatial correlation of connected information elements“ on page https://www.incobs.de/tests-english/items/tablet-tests-with-low-vision-users-usability.html - so focussing on the label-labelled relation catches only a subset and maybe not even the most important one - I just thought here was a chance to define something in a testable way.

another note is that we also need at least exceptions for (probably all) issues mentioned by @mbgower for label in name (table labels, sometimes row AND column?, legend which may be far / further away, etc.)

@patrickhlauke

an element must be present/visible (at least in part) in the viewport, even at "mobile" sized viewports

it all depends on if you've scrolled the label visible in the viewport, may be close enough but still out of sight, also the viewport is often not a problem (on desktop) but when using zoom tools it's just too far to the right as an example... (and needs horizontal scrolling)

wouldn't any combination of "two related elements in a page" that are not sufficiently close enough cause problems for LV/zoom users? wondering if there's strong rationale for singling out labels for form controls. but then taking it ad absurdum, we'd be mandating effective whitespace/layout for everything on a page, which wouldn't fly either.

searching for a solution which might work I don't see the measurements happen in a realistic way (4 times / 3 times, widths / heights, mixed elements etc.). It's just too complicated and restrictive for designers / developers and testers.

A direction which might work though (and maybe / think that is also what Patrick meant) is a "reflow like" version where you say it must be possible to see the label + input in the viewport at 320 CSS px at the same time (easy to test). with exceptions for #673 (comment)

That leaves possible issues on desktop but a good start... ?!

@patrickhlauke mentioned:

wouldn't any combination of "two related elements in a page" that are not sufficiently close enough cause problems for LV/zoom users?

yes, we might stretch to "two related elements in a page", also don't see why this is a label/input only issues. All name/value pairs for instance deserve the same love and happiness and much more related combi's.

How about a formulation such as (in basic terms): Two related things must be close to each other unless there is a programmatic relationship...

We in terms of what 'close to each other' means, we could have a look at gestalt principles, see if there's anything there we can use.

Two related things must be close to each other unless there is a programmatic relationship

If this SC is meant to be primarily "visual", then programmatic relationship shouldn't have any bearing here. If the assumption is that for a low vision (and possibly COGA?) user there needs to be visual proximity, whether or not things are associated correctly "under the hood" makes little difference unless they use AT that exposes that relationship?

My intent (whilst writing the comment just before my train pulled in) was to leave the door open for AT to fill that gap. An SC mandating a close proximity will hit so many problems with (otherwise) usable designs that don't meet it, I don't think it would work*.

If what we are encouraging is close proximity when possible, then make that the default but have a more complex escape-hatch for when it's needed.

If it were going into Silver, we could write a method about user-agents visually providing an arrow or other indicator for the direction of the thing that's changed. And then explain that doens't exist yet.

That escape hatch would then simply shift the burden to user agents. To me, that's a cop out, and won't in the end help LV/COGA users in the real world, nullifying the actual need/usefulness of the SC altogether.

If we think the SC itself will be too difficult to define and impose on authors/designers (compared to a softer "consider doing this" guidance - which may not be part of a normative pass/fail document, but a more general "good usability suggestions" type document) that we already have to think about get-out-of-jail cards like this...that would worry me about whether or not the SC itself is solid enough.

(and essentially, the programmatic association is already a requirement under 1.3.1 and, in most cases, 4.1.2 - so having a separate SC that can be fulfilled also by just passing 1.3.1/4.1.2 seems redundant in that case)

a more general "good usability suggestions" type document) that we already have to think about get-out-of-jail cards like this...that would worry me about whether or not the SC itself is solid enough.

Conceptually, it would work quite well in the design guidance that the COGA TF are working on. Not sure if there is a similar requirement already there, but it fits that best-practice aspect.

another note is that we also need at least exceptions for (probably all) issues mentioned by @mbgower for label in name (table labels, sometimes row AND column?, legend which may be far / further away, etc.)

Out of interest @jake-abma are you referring to something like Excel where this would be an exception? Or all tables and grids?