Labels for interfaces.php

[jpcw]

fix #5725

[NOYB]

Using the left column item names as input for label is problematic for touch usage due to inadvertent toggling of settings as the left is commonly used for touch scrolling with the left thumb. Example is block bogons and private networks.

The inadvertent changes get saved along with intended changes and a wild goose chase for what broke the system ensues.

If for label to the right of the checkbox in these cases creates undesirable display clutter. Perhaps make it screen reader only content.

[jpcw]

@NOYB reading your comment many times and with many "eyses" we are not sure to understand it correctly.

Attach a left or a right label with the for attribute, put the focus on the check-boxe on a tap. We haven't notice a negative mobile experience, with many tries. Could you please illustrate the problem you encountered

[NOYB]

On touch devices vertical scrolling is frequently done with the left thumb along the left part of the display where the item names such as "Block private networks" are located.

When those are used and "labels" for input elements (such as checkboxes) it is very easy to inadvertently toggle the setting while scrolling with noticing. Tapping the label doesn't simple focus the checkbox. It toggles the checkbox.

The inadvertent and unnoticed changed setting is then saved along with the intended settings. Breaking the intended system behavior.

This is why I attached a separate label to the checkboxes. But I'm unsure how well that seemingly duplication works out with screen readers. Visually we can ignore some things like that much easier than a phrase repeated auditorily. That could be very annoying.

One possibility may be to prevent the name in the left column from screen reading and make the checkbox attached label to be screen reader only content. But that takes away the displayed "active label" which is beneficial for dexterity impaired.

I've not come up with a way to address both that I like.

[jpcw]

@NOYB we have tried with several users, and no one succeeded to toggle a checkbox without explicitly made a "tap" on the label.

So we suspect, you' re a very quick with your phone :)

First question : is to be "quick" a good behavior when updating a firewall ? And second question : how many times did you update a firewall with your phone along a year ?

From a point of view of semantic, and accessibility the tag <label for"id_of_control"> is the right way. the way with a second label on right, is not a good option, as you said the repetitions are not confortable for anyone.

However an option is to remove the <label for=""> and set an aria-label attribute on the control. But we miss the semantic way and it's more intrusive along existant pages, (not only adding html).

<label for="blockpriv"><?=gettext("Block private networks"); ?></label>

 <input name="blockpriv" type="checkbox" id="blockpriv" value="yes" <?=!empty($pconfig['blockpriv']) ? "checked=\"checked\"" : ""; ?> />

became

<?=gettext("Block private networks"); ?>

 <input name="blockpriv" type="checkbox" id="blockpriv"  aria-label="<?=gettext("Block private networks"); ?>" value="yes" <?=!empty($pconfig['blockpriv']) ? "checked=\"checked\"" : ""; ?> />

As you can see it's more intrusive.

We really prefer the implementation with labels, but we can make exceptions for checkboxes on commits with aria-labels if opnsense core-devs choose our way is not the right.

@AdSchellevis or other, we need your opinion here.

Thanks

[NOYB]

Smartphones are not the only touch devices and testing deliberately is unlikely to result in an inadvertent action. My purpose is to point out the potential, not squash the use. Unless a good or better alternative exists.

I would like to make a suggestion though. If the left column item names/titles are used for input labels then do this with all of them for consistency. For example even though the enable item has a label, still make the left column item name/title a label also.

[fichtner]

After internal discussion this approach through individual static PHP pages doesn't really work for us:

It's hundreds of changes and if the style doesn't match expectation we possibly change hundreds of lines again and rinse and repeat for over 100 such pages.

Instead, please improve the MVC templates which instantly translate to a large number of core and plugins pages and are easily deployed and reviewed. With this we can work on an agreeable style to go forward and maybe then start going through static pages to consolidate the UI style.

Cheers, Franco