WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Cohn
Date: Jan 19, 2017 8:13AM

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.
>> >> >> >> >>
> > > >