E-mail List Archives
Thread: interface has a search bar that is actually a button. WHY?????
Number of posts in this thread: 5 (In chronological order)
From: Andy Andrews
Date: Tue, Oct 05 2021 3:29PM
Subject: interface has a search bar that is actually a button. WHY?????
No previous message | Next message →
Hello All,
We were using keyboard navigation to test the De Gruyter interface [https://www.degruyter.com/database/ebr/html#] and encountered a very confusing situation. After tabbing to the search bar and attempting to enter a search term, nothing appears in the field. We discovered that if you click on or hit enter in the search bar, it acts as a button and opens a pop up. In this case, screen reader users would actually have an easier time because the screen reader says it is a button. So it technically is accessible, but functionally it is not acting as expected for most users.
Would WCAG fail this and if so, what violation would it be?
Andy Andrews, MCRP
Accessibility Coordinator
IT Services & Digital Strategies, University of Washington Libraries
206.685.1625 | = EMAIL ADDRESS REMOVED =
My pronouns are he/they
Accessibility is giving equitable access to everyone along the continuum of human ability and experience. Accessibility encompasses the broader meanings of compliance and refers to how organizations make space for the characteristics that each person brings.
From: Patrick H. Lauke
Date: Tue, Oct 05 2021 3:45PM
Subject: Re: interface has a search bar that is actually a button. WHY?????
← Previous message | Next message →
On 05/10/2021 22:29, Andy Andrews wrote:
> Hello All,
>
> We were using keyboard navigation to test the De Gruyter interface [https://www.degruyter.com/database/ebr/html#] and encountered a very confusing situation. After tabbing to the search bar and attempting to enter a search term, nothing appears in the field. We discovered that if you click on or hit enter in the search bar, it acts as a button and opens a pop up. In this case, screen reader users would actually have an easier time because the screen reader says it is a button. So it technically is accessible, but functionally it is not acting as expected for most users.
>
> Would WCAG fail this and if so, what violation would it be?
I'd say that no SC is violated here. It's rubbish and confusing design,
but it's rubbish and confusing in equal measure for most users.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Steve Green
Date: Tue, Oct 05 2021 10:18PM
Subject: Re: interface has a search bar that is actually a button. WHY?????
← Previous message | Next message →
I agree with Patrick. It's a stupid, yet very common, feature that is almost always unnecessary and harms the user experience for almost everyone. Your best chance of getting it removed is to do some user testing. We find that video evidence of people complaining about their inability to find or use features is extremely powerful.
I would also ask the UI designers for the evidence that underpins their decision to implement the feature that way. Did they do any user research? Did an authoritative UX research organisation recommend it? Or did they just copy something they thought was cool on someone else's website. We know the answer, but I like to get them to admit it because so little professional UX research and testing is done these days, and everyone just copies the fads they have seen elsewhere.
Steve Green
Managing Director
Test Partners Ltd
From: Andy Andrews
Date: Wed, Oct 06 2021 10:06AM
Subject: Re: interface has a search bar that is actually a button. WHY?????
← Previous message | Next message →
Thanks Steve and Patrick.
We assumed it would not be a violation, but wanted to double check. Yesterday we discovered that it's not like that with every product they have. If you go to their home page the search bar is a search bar, same with a few of the eBooks we tested in our catalogue. So the experience varies depending on what product the user is using. Which is even more confusing for users. We are hoping the database interface in question is an anomaly and not a indicator of a vendor wide change they have in the works. We plan to give them feedback.
Thanks,
Andy
From: Sailesh Panchang
Date: Wed, Oct 06 2021 11:02AM
Subject: Re: interface has a search bar that is actually a button. WHY?????
← Previous message | No next message
Hello, I disagree.
Does the search bar look like a heading or a button? Is there any
visual cue to indicate that it can be expanded / collapsed?
If it appears simply like a heading and if one does not expect it to
be in the tab order, then it should be marked as a heading and not be
keyboard navigable/operable. You can fail it at a minimum for SC 1.3.1
because the structure conveyed by presentation is not what the markup
conveys.
Then if it appears like an operable element but an AT user cannot
figure out its expanded / collapsed state, one could fail it for SC
4.1.2 because the state is not conveyed. Typically one would expect
the "search" button to submit the search form.
If you are seeing differences in element identification and behavior
across the site, consider consistent identification SC 3.2.4 too.
Thanks,
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon,
VA 20170
Mobile: 571-344-1765
On 10/6/21, Andy Andrews < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Steve and Patrick.
>
> We assumed it would not be a violation, but wanted to double check.
> Yesterday we discovered that it's not like that with every product they
> have. If you go to their home page the search bar is a search bar, same with
> a few of the eBooks we tested in our catalogue. So the experience varies
> depending on what product the user is using. Which is even more confusing
> for users. We are hoping the database interface in question is an anomaly
> and not a indicator of a vendor wide change they have in the works. We plan
> to give them feedback.
>
> Thanks,
>
> Andy
>
>