E-mail List Archives

Re: Search text field with magnifier icon within the text box


From: Birkir R. Gunnarsson
Date: Jan 19, 2017 8:23AM

4.1.2, the search field needs an accessible name
So if you use aria-label="search" and visually the magnifying glass is
there (but hidden from assistive technologies), that is sufficient
The fact that it is not clickable is kind of covered in the 3.2.2
case, the solution to the uatomatic submission f the search when user
navigates to a suggestion is to create a separate search button, which
could be visually identified by the magnifying glass.

On 1/19/17, Jonathan Cohn < <EMAIL REMOVED> > wrote:
> The magnifying glass is not clickable right? In which case the Magnifying
> Glass is essentially a label for the search box.
> If my above statements are true, then I think as long as there is an
> alternative labeling for the search box, there is no issue with the
> magnifying glass. BTW is the Magnifying glass a UNICODE character or a
> image?
> Best wishes,
> Jonathan Cohn
>> On Jan 19, 2017, at 3:18 AM, Rakesh P < <EMAIL REMOVED> > wrote:
>> Thanks Birkir. My biggest concern is with magnifier icon within the text
>> box itself. Screen reader user will not know that the icon exist and
>> keyboard only user can never navigate to the icon as a separate element.
>> On Thu, Jan 19, 2017 at 1:47 AM, Birkir R. Gunnarsson <
>> <EMAIL REMOVED> > wrote:
>>> My approach to filing issues with this would be:
>>> 1. File 4.1.2 - search field does not have an accessible name (this is
>>> borderline, because the placeholder text is a source of accessible
>>> name in the latest version of the accessible name calculation
>>> algorithm).
>>> 3.3.2 is sort of satisfied by the icon I guess, see technique 167
>>> http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G167
>>> I would still definitely file a best practice issue saying that there
>>> should be a text label field.
>>> actually satisfied by the magnifying glass icon in the search field.
>>> 2. File a 4.1.2 issue that the search input is not marked as an auto
>>> complete and refer to the auto complete search or combobox patterns in
>>> the ARIA Authoring Practices spec.
>>> (it is really as simple as utting aria-haspopup="true" on the ield and
>>> use html5 type="search").
>>> 3. File a 2.1.1 - keyboard accessibility issue, because you cannot
>>> just arrow down from the input field to the suggestions that are
>>> displayed.
>>> 4. File a 3.2.2 issue, because navigating to a search suggestion
>>> should not automatically submit the search.
>>> On 1/17/17, Rakesh P < <EMAIL REMOVED> > wrote:
>>>> All,
>>>> I have encountered a search text field with the following constructs.
>>>> a. A text box with a placeholder text "Search".
>>>> b. Within the text field a magnifier icon is placed and this icon is not
>>>> recognized by the screen reader.
>>>> c. As the user types in the search term the placeholder is appended
>>>> along
>>>> with the words typed in by the user.
>>>> d. As the user types in the search terms, auto suggestions are populated
>>>> but not identified by the screen reader.
>>>> e. If the user selects any suggestion the page automatically navigates
>>>> to
>>>> the search results page.
>>>> I observe the following WCAG violations in the component. Guide me if
>>>> any
>>>> of these are not required or if I need to add anything more.
>>>> a. 3.3.2 Labels and Instructions: This is specifically because the
>>>> search
>>>> placeholder is appended to the words typed in by the user. The search
>>>> placeholder should not be the part of text typed by the user. This
>>>> should
>>>> be a visual label.
>>>> b. 2.1.1 Keyboard only: The magnifier icon should not be the part of
>>>> text
>>>> field, it should be a separate keyboard navigable (tab) element.
>>>> c. 4.1.2 Name, role, value: The magnifier icon should have a role such
>>>> as
>>>> button for the user to identify it as an actionable item.
>>>> d. 1.1.1 Non-text content: Since screen reader is not recognizing it as
>>> an
>>>> item, am anticipating that magnifier image have either empty alt or no
>>> alt.
>>>> e. 1.3.2 Meaningful sequence: The auto-suggestions populated are not
>>>> read-out by the screen reading technology.
>>>> f. 3.2.2 Change on input: As soon as the the user navigates to the
>>>> search
>>>> suggestion the focus should not move to another page. User should be
>>> given
>>>> a mechanism to confirm the selection.
>>>> Sorry for a long email.
>>>> >>>> >>>> >>>> >>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> >>> >>>
>> >> >> >> >
> > > > >

Work hard. Have fun. Make history.