WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Rakesh P
Date: Jan 19, 2017 6:25PM

I am now clear Birkir, Thanks.

Jonathan,

I currently do not have access to the code. I am suspecting it as an image
with empty alt text.


On Thu, Jan 19, 2017 at 8:53 PM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

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