SC 2.5.8 Pointer Target Spacing - How do input labels impact spacing requirements?

[brooks-newton]

On behalf of Thomson Reuters

How do input labels impact the proposed pointer target spacing rule? For example, should a visible programmatically bound text label that appears above a text input be measured as part of the target area for the input?

[detlevhfischer]

@brooks-newton I personally think it makes sense to count a programmatically linked label as part of the target size.

The Mobile Accessibility Task Force has reconsidered the approach due to several concerns about the proposed SC Pointer Target Spacing, and currently proposes an alternative Success Criterion to replace Pointer Target Spacing:

Target Size (AA)
The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when:

• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

[alastc]

I think the question of labels & inputs is valid for any version of the SC.

Draft proposed response:

---

The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". That covers both the label and input (when associated).

Ideally those would form one large target, but technically it could be two distinct areas, one of which must meet the criteria text.

[patrickhlauke]

Possibly of note that the fact that clicking/tapping a label generally sets focus to, or activates, a form control is not defined specifically in the HTML standard (which just handwaves it to "the platform's label behavior" (see https://html.spec.whatwg.org/multipage/forms.html#the-label-element). So, in theory, there may be platforms out there that do not have this behavior. Not sure if that can then be relied upon (or maybe it can be, considering most common UAs seem to follow this as an unwritten rule/de facto behavior)

[DavidMacDonald]

Ideally those would form one large target, but technically it could be two distinct areas, one of which must meet the criteria text.

I'd add them together. It would be very rare for the label not to be adjacent to the input.

[alastc]

We didn't quite finish this in the meeting, but there were a couple of updates, new draft response:

---

The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". Therefore if they form one target and if the known user-agents do support making the label clickable, then the label can contribute to the target size.

[mraccess77]

If the checkbox and label targets were not connected and the checkbox did not have a large enough target but the label did - would that pass? That is - can any target pass or do all targets associated with an action have to pass?

[alastc]

If the action is associated with the checkbox, I think that target would have to pass. Having another target somewhere else doesn't really help.

[patrickhlauke]

if the known user-agents do support making the label clickable

just a bit concerned here about the idea of "known user-agents". and how a normative pass/fail determination relies on a non-standardised (but yes, de-facto standard) behavior of user agents.

also, this line of thinking here likely applies to interpretation/evaluation of 2.5.5 target size

[bruce-usab]

I am just noticing that definition of Target might warrant tweaking:

Current definition excerpt (emphasis added): ...region of the display that will accept a pointer action

I believe we have been using the term viewport (as opposed to display or window or content or other terms).

[patrickhlauke]

i might be misremembering, but wasn't there some discussion about viewport implying that anything that may only partially scrolled into view would then potentially fail, and that's the reason for using display (which is likely just as flawed, to be honest)

[alastc]

The group discussed this today and agreed with this response to the original issue:

---

The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". If a label and the input form one target and if user-agents support making the label clickable as a mechanism to take an action on a user interface component, then the label's area can contribute to the target size.

[patrickhlauke]

so you're making pass/fail dependent on the user agent used? hmmm...

[JAWS-test]

If a label and the input form one target ...

This usually only applies if an enclosing label is used. But not with <label for>, because there is a non-clickable area between form field and label. For checkboxes, for example, because they automatically have a margin, for input fields, as soon as there is a white space between input field and label.
Is this intended? Or should the click area not be sufficient for <label for>, even if label and target are not form one target?

[alastc]

so you're making pass/fail dependent on the user agent used?

Essentially a conformance statement thing. It seems to be a widely used default, so shouldn't be harmful/confusing.

This usually only applies if an enclosing label is used. But not with , because there is a non-clickable area between form field and label... Is this intended?

Yes, if there's a gap it is separate from the control you are trying to use. It isn't based on the method as such, but it needs to be a contiguous target.

As a response has been agreed I'll close this now. Please re-open if there is some new information.