E-mail List Archives
Thread: Clear text within search edit field
Number of posts in this thread: 16 (In chronological order)
From: allyssa jessicon
Date: Fri, Sep 13 2024 12:23AM
Subject: Clear text within search edit field
No previous message | Next message →
Hello everyone,
Does not providing focus to a clear search button within a search edit
field fail wcag guideline? When a user type in, a clear text control (X)
appears but does not have a focus set to it.
Note: The clear button appears only when user type in something.
Thanks,
Allyssa.
From: Dean.Vasile
Date: Fri, Sep 13 2024 3:55AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
I'm not sure exactly what you are asking, but, why would a "Clear search" need to be focusable, if nothing has been entered in the field.
Dino
Dean Vasile
IAAP, CPACC
= EMAIL ADDRESS REMOVED =
617-799-1162
Dino
From: Patrick H. Lauke
Date: Fri, Sep 13 2024 4:07AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
No, since a keyboard user can still clear the field in other ways
(Ctrl+A, Delete).
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: mhysnm1964
Date: Sat, Sep 14 2024 5:11AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
This is a failure as far as I am concern. If there is a button on the screen and is not in the tab order / keyboard focus order . Then it fails focus order.
Regardless if there is other keyboard commands related to the edit field which achieves the same result. As ctrl + a is related to the 2.1.1 keyboard criteria as far as I am concern, not to the tab focus order.
Note: Being a screen reader user, I should be able to access all the visible buttons on the screen via the tab or shift + tab keys, plus using my screen reader capability.
Sean
From: Dean.Vasile
Date: Sat, Sep 14 2024 6:07AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
Sean
What you say makes sense to a point
If the button is not focusable, it is because there is no text in the edit field once there’s Text in the edit field. The button is then focusable so I do not think it is a failure in that case.
Dean Vasile
617-799-1162
> On Sep 14, 2024, at 7:11 AM, = EMAIL ADDRESS REMOVED = wrote:
>
> This is a failure as far as I am concern. If there is a button on the screen and is not in the tab order / keyboard focus order . Then it fails focus order.
>
> Regardless if there is other keyboard commands related to the edit field which achieves the same result. As ctrl + a is related to the 2.1.1 keyboard criteria as far as I am concern, not to the tab focus order.
>
> Note: Being a screen reader user, I should be able to access all the visible buttons on the screen via the tab or shift + tab keys, plus using my screen reader capability.
>
> Sean
>
From: Barry
Date: Sat, Sep 14 2024 6:34AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
As the button is a clear edit field button (a button designed to clear or reset the contents of a form input field) and it is not focusable and not marked as an interactive element, the impact on accessibility would be significant, especially for users relying on assistive technologies. Here's why:
Switch Controller Users: If the clear button cannot be focused, users navigating with a switch controller would have no way of interacting with it. They wouldn’t be able to clear the field, forcing them to either manually delete the content (which could be tedious) or abandon the form altogether.
Voice Control Users: Without the button being marked as interactive, voice control systems may not recognize it as an actionable element. Users would lose the ability to simply say “Clear,” “Reset,” or whatever command is associated with that button, forcing them to take manual steps to delete the text.
Magnification users: Magnification might make the button visually appear like it’s clickable or interactive, but without proper accessibility attributes (focusable and marked as interactive), pressing it will have no effect. This could confuse the user, especially if they expect the button to perform an action but are unable to trigger it.
Screen Reader Users: If the button is not properly labeled or focusable, screen readers would likely ignore it, making it impossible for blind or visually impaired users to even know the button exists, much less interact with it.
Cheers
Barry
From: Steve Green
Date: Sat, Sep 14 2024 7:23AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
Success Criterion 2.4.3 Focus Order states that "focusable components receive focus in an order that preserves meaning and operability." If a component does not receive focus, the success criterion does not apply. So this unfocusable button does not violate SC 2.4.3.
Nowhere does WCAG state that every interactive component must receive focus. Unfocusable components might result in a non-conformance of SC 2.1.1 Keyboard Navigation, but not if there is an alternative means of achieving the same outcome. In this case, the text can be deleted one character at a time or by selecting the whole string and deleting it.
So it appears that this button does not violate any WCAG success criteria, although it may do since we don't have all the information.
Steve Green
Managing Director
Test Partners Ltd
From: Barry
Date: Sat, Sep 14 2024 8:24AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
Even though there is an alternative method for achieving the same functionality (e.g., selecting the text in the edit field and using backspace or delete), this approach may still fail WCAG 2.1.1 (Keyboard Navigation) for the following reasons:
Efficiency and ease of use: The alternative method (manually selecting all text and pressing delete/backspace) is significantly less efficient and more cumbersome than directly interacting with a clear edit button. WCAG emphasizes that all users, including those relying on keyboard navigation, should have access to functionality that is equally efficient and operable. Requiring additional steps for keyboard users when a simple clear button is available for mouse users would not provide an equivalent experience.
Expectation of direct interaction: The button itself, being visible and interactive for mouse users, creates an expectation that it should also be available to keyboard users. Not providing keyboard access to the button is an accessibility gap. Even if another method exists, the button being non-focusable would still violate the principle of operability outlined in WCAG, as keyboard users would expect to interact with it directly.
Consistency with the standard: WCAG does not suggest that the presence of an alternative method excuses the inaccessibility of the primary method of interaction. The guideline aims for consistency across all input methods, ensuring that buttons and interactive elements are accessible through both mouse and keyboard in an intuitive and direct manner.
Thus, even with the alternative method, not making the clear button focusable and operable via keyboard would still likely fail SC 2.1.1, because the alternative is neither as direct nor as efficient as interacting with the button itself.
Cheers
Barry
From: Steve Green
Date: Sat, Sep 14 2024 8:36AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
There is always a difference of efficiency and ease of use for keyboard and mouse users. Sometimes keyboard navigation is more efficient, sometimes it isn't. WCAG always uses phrases like "content is operable", not "content is equally operable", precisely because the two means of interaction can never be equal.
WCAG absolutely does suggest that the presence of an alternative method excuses the inaccessibility of the primary method of interaction. It's called the provision of an alternative conforming version.
The things you mention are perfectly reasonable accessibility issues that we would encourage clients to address. But they are not WCAG non-conformances.
Steve
From: Birkir R. Gunnarsson
Date: Sat, Sep 14 2024 9:12AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
The mouse user needs a form of input, most likely a keyboard, to enter the
search input value.
For inputs that are predictable, e.g. first name or address, users could
use an auto-fill solution, but you are not likely to enter the same thing
every time into a search input.
In other words, mouse users are likely to have a keyboard with all the
conveniences of keyboard shortcuts for clearing an input.
So why do people add a clear icon into an input, and if they bother to do
that, why don't they make it a button?
I agree that this is a usability/best practice issue, not a flagrant WCAG
violation, I'm just trying to make sense of this pattern.
From: Patrick H. Lauke
Date: Sat, Sep 14 2024 9:22AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
On 14/09/2024 15:24, Barry via WebAIM-Forum wrote:
> Even though there is an alternative method for achieving the same functionality (e.g., selecting the text in the edit field and using backspace or delete), this approach may still fail WCAG 2.1.1 (Keyboard Navigation) for the following reasons:
None of the reasons provided are normative parts of the success
criterion, so I'm afraid not.
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Dean.Vasile
Date: Sat, Sep 14 2024 9:39AM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
I’m a little confused with all that I am hearing about this issue.
If there is a search field that has a clear content button and there’s nothing entered into the search field. I do not expect that button to be focusable.
I’ve seen many forms that have a submit form button, that are dimmed until information is entered into the form and then it is focusable, so what’s the actual situation?
Dean Vasile
617-799-1162
> On Sep 14, 2024, at 11:22 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>
>
>> On 14/09/2024 15:24, Barry via WebAIM-Forum wrote:
>> Even though there is an alternative method for achieving the same functionality (e.g., selecting the text in the edit field and using backspace or delete), this approach may still fail WCAG 2.1.1 (Keyboard Navigation) for the following reasons:
>
> None of the reasons provided are normative parts of the success criterion, so I'm afraid not.
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
> > > >
From: Joshua Hori
Date: Sat, Sep 14 2024 12:48PM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
I was also a bit confused by this. If your "clear all" button relies on data being entered into the search element, it could be failing the 2.4.7 Focus Visible and 3.2.2 On Input criteria. While many are focusing on 2.1.1 (Keyboard), it's worth noting that specific keystrokes aren’t required to activate the "clear all" button.
What stands out to me is 2.4.7 Focus Visible, especially for users with mobility impairments. They would need to press more buttons to remove accidentally pasted content, instead of being able to access the "clear all" button directly. There have been several instances where the "select all" function included the entire webpage content, not just the form field, which can be frustrating.
Regarding 3.2.1 On Focus and 3.2.2 On Input, when the search button is activated, a "clear all" button becomes available after content is entered. Although the page doesn’t change when the search receives focus, it does when input is entered. If there are clear instructions on the page indicating this, such as adding ARIA instructions to the search field or an ARIA-live region that announces “clear search field content,” it might prevent the failure of these criteria.
It can be overwhelming when keyboard shortcuts are inconsistent, and sometimes you just want to quickly tab and enter to clear content, similar to how a mouse user would perform a simple two-step process (slide and click).
Best,
Joshua
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
Date: Saturday, September 14, 2024 at 8:39 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Clear text within search edit field
I’m a little confused with all that I am hearing about this issue.
If there is a search field that has a clear content button and there’s nothing entered into the search field. I do not expect that button to be focusable.
I’ve seen many forms that have a submit form button, that are dimmed until information is entered into the form and then it is focusable, so what’s the actual situation?
Dean Vasile
617-799-1162
> On Sep 14, 2024, at 11:22 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>
>
>> On 14/09/2024 15:24, Barry via WebAIM-Forum wrote:
>> Even though there is an alternative method for achieving the same functionality (e.g., selecting the text in the edit field and using backspace or delete), this approach may still fail WCAG 2.1.1 (Keyboard Navigation) for the following reasons:
>
> None of the reasons provided are normative parts of the success criterion, so I'm afraid not.
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
> > > >
From: Steve Green
Date: Sat, Sep 14 2024 1:00PM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
The button for clearing the content is not displayed until something is entered in the text field. Then it is displayed, but does not receive focus. The original post does not say if a role or accessible name is exposed in browse mode.
Steve
From: Abi James
Date: Sat, Sep 14 2024 1:24PM
Subject: Re: Clear text within search edit field
← Previous message | Next message →
It sounds like the functionality in the original query maybe part of an input type=search element. Some browsers display an x button within the input, others don’t (see MDN example https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search#differences_between_search_and_text_types). On those browsers that display it, there is usually a keyboard function to clear the input (ESC on chromium browsers). Even on iOS there is a keyboard undo function even if the x button is not displayed. There is also an argument that x button isn’t author created content as it I generated by the browser so out of scope of WCAG.
While it is laudable to argue to think beyond WCAG (I support teams who’ve worked hard to make that clear input function fully accessible), if you argue that all interactive elements have to be in the tab key focus order, you are then risking making navigating webpages by keyboard even slower. And you’d be arguing that common keyboard patterns for complex widgets like dropdowns, autocompletes and tab panels are not compliant as they rely on non tab key controls.
In situations where (non) standard keyboard functions can’t be avoided it’s as beneficial to think about how to help improve discoverability of keyboard commands as much as the technical solution. I have been caught out by how people who are starting to have to rely on a keyboard can have limited awareness of the basic concepts of keyboard commands.
Regards
Abi James
Digital accessibility consultant & researcher
On 14 Sep 2024, at 20:00, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
CAUTION: This e-mail originated outside the University of Southampton.
The button for clearing the content is not displayed until something is entered in the text field. Then it is displayed, but does not receive focus. The original post does not say if a role or accessible name is exposed in browse mode.
Steve
From: Birkir R. Gunnarsson
Date: Sat, Sep 14 2024 1:44PM
Subject: Re: Clear text within search edit field
← Previous message | No next message
I don't see 3.2.1 or 3.2.2 applying. The appearance of content in response
to focus or input does not constitute "change of context", focus does not
move, new page doesn't load, the new content is discoverable, or decorative.
I like the idea of the escape key clearing the input.
This is super interesting, there's a lot of accessibility usability
considerations here, but I'd call it a best practice rather than an
outright fail of a WCAG success criterion.
On Sat, Sep 14, 2024 at 2:48 PM Joshua Hori < = EMAIL ADDRESS REMOVED = > wrote:
> I was also a bit confused by this. If your "clear all" button relies on
> data being entered into the search element, it could be failing the 2.4.7
> Focus Visible and 3.2.2 On Input criteria. While many are focusing on 2.1.1
> (Keyboard), it's worth noting that specific keystrokes aren’t required to
> activate the "clear all" button.
>
> What stands out to me is 2.4.7 Focus Visible, especially for users with
> mobility impairments. They would need to press more buttons to remove
> accidentally pasted content, instead of being able to access the "clear
> all" button directly. There have been several instances where the "select
> all" function included the entire webpage content, not just the form field,
> which can be frustrating.
>
> Regarding 3.2.1 On Focus and 3.2.2 On Input, when the search button is
> activated, a "clear all" button becomes available after content is entered.
> Although the page doesn’t change when the search receives focus, it does
> when input is entered. If there are clear instructions on the page
> indicating this, such as adding ARIA instructions to the search field or an
> ARIA-live region that announces “clear search field content,” it might
> prevent the failure of these criteria.
>
> It can be overwhelming when keyboard shortcuts are inconsistent, and
> sometimes you just want to quickly tab and enter to clear content, similar
> to how a mouse user would perform a simple two-step process (slide and
> click).
>
> Best,
>
> Joshua
>
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of
> = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
> Date: Saturday, September 14, 2024 at 8:39 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Clear text within search edit field
> I’m a little confused with all that I am hearing about this issue.
> If there is a search field that has a clear content button and there’s
> nothing entered into the search field. I do not expect that button to be
> focusable.
> I’ve seen many forms that have a submit form button, that are dimmed
> until information is entered into the form and then it is focusable, so
> what’s the actual situation?
> Dean Vasile
>
>
> 617-799-1162
>
> > On Sep 14, 2024, at 11:22 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >
> >
> >> On 14/09/2024 15:24, Barry via WebAIM-Forum wrote:
> >> Even though there is an alternative method for achieving the same
> functionality (e.g., selecting the text in the edit field and using
> backspace or delete), this approach may still fail WCAG 2.1.1 (Keyboard
> Navigation) for the following reasons:
> >
> > None of the reasons provided are normative parts of the success
> criterion, so I'm afraid not.
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > * https://www.splintered.co.uk/
> > * https://github.com/patrickhlauke
> > * https://flickr.com/photos/redux/
> > * https://mastodon.social/@patrick_h_lauke
> >
> > > > > > > > > > > > > > > > >
--
Work hard. Have fun. Make history.