E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Rakesh P
Date: Tue, Jan 17 2017 9:41AM
Subject: Search text field with magnifier icon within the text box
No previous message | Next message →

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.

From: Birkir R. Gunnarsson
Date: Wed, Jan 18 2017 1:17PM
Subject: Re: Search text field with magnifier icon within the text box
← Previous message | Next message →

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

From: Rakesh P
Date: Thu, Jan 19 2017 1:18AM
Subject: Re: Search text field with magnifier icon within the text box
← Previous message | Next message →

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

From: Jonathan Cohn
Date: Thu, Jan 19 2017 8:13AM
Subject: Re: Search text field with magnifier icon within the text box
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Thu, Jan 19 2017 8:23AM
Subject: Re: Search text field with magnifier icon within the text box
← Previous message | Next message →

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

From: Rakesh P
Date: Thu, Jan 19 2017 6:25PM
Subject: Re: Search text field with magnifier icon within the text box
← Previous message | No next message

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