Can ENTER on seach field be accepted as conforming alternative to inaccessible control (loupe icon)?

[detlevhfischer]

We are discussing a particular search field pattern and would be interested to see the take of others.

A search form field has a graphical control (loupe icon) that can only be operated with the mouse. Do you see a normative requirement that keyboard users can focus and activate the control, when "Enter" on the field also successfully submits the form? Or would you see ENTER on the field as 'conforming alternate version' on the same page?

Wouldn't it be confusing for sighted users as they might try to focus the control but against expectation foucus is on the next focusable element? They would have to navigate back to the form field trying "Enter".

[patrickhlauke]

Do you see a normative requirement that keyboard users can focus and activate the control, when "Enter" on the field also successfully submits the form?

no, as normatively

All functionality of the content is operable through a keyboard interface

and this is clearly the case ... a keyboard user (including on-screen/virtual keyboards) can trigger the search functionality.

Wouldn't it be confusing for sighted users

probably yes, the first time they encounter it. but "confusing" isn't a failure of 2.1.1

[patrickhlauke]

probably related thinking to #857 (comment) and #872

[mraccess77]

I also experience many search fields that have not corresponding buttons - but enter works to perform the search.

[detlevhfischer]

There is a mismatch between visual and programmatic - FAIL of 1.3.1, anyone? Thanks for pointing to #872, a treasure trove

[scottaohara]

there are many instances of search fields that have a visual icon that performs no action what-so-ever, though. macOS and windows both can have search fields at the top of OS folders that have search icons that perform no function, but rather serve as a visual label for the fields. Per the above comment, should these fail? Why? We can't use search icons to label a field unless they are also buttons? no.,,,

As one other example, Firefox can have a search bar added to the browser toolbar where the search icon serves as a mouse-clickable control to reveal a listbox of previous searches / allow for a search within a search engine chosen by the user. This control is not directly keyboard accessible (i.e., directly keyboard focusable), but pressing down arrow reveals the same listbox when focus is within the search field.

I do not think it makes sense to fail variations to controls so long as those variations are in-fact accessible. Otherwise, you're saying that controls can only be marked up and behave in one particular way - and that's just not realistic.

[patrickhlauke]

FAIL of 1.3.1, anyone

that seems very tenuous at best, and really feels like an "i want to fail this, what can i fail this under?"

[patrickhlauke]

Perhaps the understanding document for 2.1.1 could do with a bit more of an expansion that clarifies that "All functionality of the content is operable through a keyboard interface" does not necessarily mean "every control you can operate with a mouse must also be focusable/triggerable with the keyboard", and that it's the functionality that counts (can a keyboard user achieve the same end result). It seems implied in the note

This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

but perhaps bears repeating...

[edit: hah, forgot i already put a PR on the big pile ages ago https://github.com//pull/1642 ]

[detlevhfischer]

there are many instances of search fields that have a visual icon that performs no action what-so-ever, though. macOS and windows both can have search fields at the top of OS folders that have search icons that perform no function, but rather serve as a visual label for the fields. Per the above comment, should these fail? Why? We can't use search icons to label a field unless they are also buttons? no.,,,

@scottaohara Sure, that wasn't the point I was trying to make though. I still see a difference between non-interactive icons that just serve as visual label (fine), and mouse-operable icon controls that are not keyboard-operable (not so great). But I agree with @patrickhlauke that failing this under 1.3.1 would be a stretch.

[scottaohara]

i'm glad you agree with patrick, as i do too.

i have more to say on this particular train of thought, but i think it may send this thread off topic a bit. It seems to me though, that this thread - per the initial ask - has run its course?

[alastc]

It does, and I encourage people who open discussions (and kindly & correctly label them as discussions) to close them when satisfied.