E-mail List Archives
Thread: Accessibility of separate button on search suggestions flyout with Keyboard
Number of posts in this thread: 10 (In chronological order)
From: Sergey L.
Date: Sun, Mar 12 2023 8:02AM
Subject: Accessibility of separate button on search suggestions flyout with Keyboard
No previous message | Next message →
Hello Web Accessibility community,
I am writing to inquire about the accessibility of a search page with
Keyboard control support.
The search page has a search input field that provides search suggestions
when a user types in it.
The suggestions include several search options and a separate "View all
results" button.
However, the "View all results" button is not accessible from the Keyboard.
Here is live prototype: https://codepen.io/blink172/full/LYJQNrR (type:
"test" into search field)
As per the WCAG21 documentation, all functionality of the content must be
operable through a keyboard interface without requiring specific timings
for individual keystrokes, except where the underlying function requires
input that depends on the path of the user's movement and not just the
endpoints.
https://www.w3.org/WAI/WCAG21/quickref/?showtechniques!1#keyboard
I believe that any item on the page that can be clicked with the mouse
should also be accessible from the keyboard. But...
I am wondering if this is a serious violation? of WCAG21 ? If so, I would
appreciate it if you could point me to relevant resources where I can learn
more about this violation.
Or can I leave it as is?
Thank you for your time and attention.
From: glen walker
Date: Sun, Mar 12 2023 11:25AM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
> I believe that any item on the page that can be clicked with the mouse
should also be accessible from the keyboard
While that's certainly the ideal situation, that's not what 2.1.1 says. As
you quoted, "*all functionality *of the content must be operable through a
keyboard interface".
The key being "all functionality". It does not say all interactive elements
must be operable with a keyboard.
So in your case, if there was another way to view all results besides
clicking on the "view all" button and that other way supported the
keyboard, then technically the "view all" button does not have to be
keyboard accessible. I would not encourage that behavior, but it's allowed.
> I am wondering if this is a serious violation?
If there's no other (keyboard) way to view all results, then absolutely
it's serious. If there is another way, then it's not a WCAG failure but
could still be an annoyance for some users, depending on how difficult it
is to get to the other way.
All WCAG failures are going to be serious to some user, otherwise it
wouldn't be a failure.
From: Andrews, David B (DEED)
Date: Mon, Mar 13 2023 3:30PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
Please don't get so hung up on the numbers or the exact meaning of words. Can a keyboard-only user do everything on the page that a mouse user can do? This is a yes/no question!
Dave
From: glen walker
Date: Tue, Mar 14 2023 11:23AM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
> Please don't get so hung up on the numbers or the exact meaning of words
I'm not sure I understand what you mean. When we evaluate for WCAG
conformance, especially if legal issues are involved, the meaning of words
is extremely important.
If I were to review a page and report a failure of 2.1.1 because a button
was not keyboard accessible but there was another way to perform the same
functionality using the keyboard, then I would be doing a disservice to the
client and potentially make them liable to fix something that is not an
error.
> Can a keyboard-only user do everything on the page that a mouse user can
do? This is a yes/no question!
That's exactly what my previous post said.
From: Andrews, David B (DEED)
Date: Tue, Mar 14 2023 11:30AM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
I am just trying to remind people about functional acc4essibility. I see extended debates here about whether something fails by 2.x.x or 3.x.x. If disabled persons can't use the site, it doesn't matter.
For those of you who make your living at this, maybe it has to be a "compliance" issue, but for us disabled persons trying to get things to work, it doesn't look quite the same.
Dave
From: glen walker
Date: Tue, Mar 14 2023 12:16PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
I don't disagree from the usability side but you can't say that you should
ignore the wording of the guidelines. I do freelance work and it depends on
what the client wants. I always push for usability beyond WCAG but if they
insist on strict legal conformance, then I can't report failures that don't
actually fail.
The original question that started this thread was that there was a "view
all" button that was not keyboard accessible. My answer was that if that's
the only way to view all results, then it's a failure. If there's another
way to view all results, then it might not be a failure. I still stand by
that.
On Tue, Mar 14, 2023 at 11:30 AM Andrews, David B (DEED) via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> I am just trying to remind people about functional acc4essibility. I see
> extended debates here about whether something fails by 2.x.x or 3.x.x. If
> disabled persons can't use the site, it doesn't matter.
>
> For those of you who make your living at this, maybe it has to be a
> "compliance" issue, but for us disabled persons trying to get things to
> work, it doesn't look quite the same.
>
> Dave
>
>
From: Sergey L.
Date: Tue, Mar 14 2023 12:16PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
Thank you very much for your answers.
> if there was another way to view all results besides
> clicking on the "view all" button and that other way supported the
> keyboard, then technically the "view all" button does not have to be
> keyboard accessible
Yes, it is possible:
1. You need to go back to the input search field with the Tab Key or the up
Arrow Key.
2. Then, you need to press the Enter key in the input box to submit the
form. Pressing Enter Key will send the search form, and the "All Search
Results Page" will appear.
> If there is no other (keyboard) way to view all results, it is a serious
issue.
But on the other hand, it would be easier for me to select the "View all
results" button from the keyboard, and the screen reader will inform me
that this button will show all results.
Just to give you an example:
1. User enters something into the search input
2. Go through all three or four suggested options, and with the Down Arrow
Key or Tab Key will give them the ability to view all the results instead
of moving the focus back to the input field and submitting the search form.
I would like to point out that technically, making the "View all results"
button accessible should not be too difficult. However, its accessibility
will affect the usability of the website.
In my opinion, for my case, the keyboard-only user must be able to do
everything on the page that a mouse user can do because it will make it
easier to use. Am I wrong?
> Can a keyboard-only user do everything on the page that a mouse user can
do? This is a yes/no question!
My answer is: No. Keyboard-only user can't use the "View all results"
button functionality. User can do the search that will give him search
results only with moving the focus back to the input field.
Thank you.
On Tue, Mar 14, 2023 at 7:30 PM Andrews, David B (DEED) via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> I am just trying to remind people about functional acc4essibility. I see
> extended debates here about whether something fails by 2.x.x or 3.x.x. If
> disabled persons can't use the site, it doesn't matter.
>
> For those of you who make your living at this, maybe it has to be a
> "compliance" issue, but for us disabled persons trying to get things to
> work, it doesn't look quite the same.
>
> Dave
>
>
>
>
From: glen walker
Date: Tue, Mar 14 2023 12:40PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
>
> > if there was another way to view all results besides
> > clicking on the "view all" button and that other way supported the
> > keyboard, then technically the "view all" button does not have to be
> > keyboard accessible
>
> Yes, it is possible:
>
> 1. You need to go back to the input search field with the Tab Key or the up
> Arrow Key.
> 2. Then, you need to press the Enter key in the input box to submit the
> form. Pressing Enter Key will send the search form, and the "All Search
> Results Page" will appear.
>
Now it starts getting messy. Is the "functionality" available for keyboard
users? I can see arguments on both sides. Perhaps the functionality is
there but it might not be easily discoverable. If the user doesn't know
how to get the same functionality, then does the functionality really
exist? (Kind of a philosophical question.)
At that point, it seems to be a nit-pick argument one way or the other.
Personally, I would report it as a failure (if the functionality is not
easily discoverable) and let the client decide if they agree or not. In the
end, it's their decision. If they're treating WCAG as a minimal checklist
that they're trying to cover for legal reasons, then they'll probably
decide it's not a failure. I try to avoid clients like that but sometimes
it's not obvious when you sign the contract.
> I would like to point out that technically, making the "View all results"
> button accessible should not be too difficult. However, its accessibility
> will affect the usability of the website.
>
Perhaps I don't know all the details of your actual situation but I don't
see how making the "view all" button keyboard accessible as being a
detriment to the usability of the website.
From: Kevin Prince
Date: Tue, Mar 14 2023 2:31PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | Next message →
Totally - saying something is compliant doesn't mean that you can't note improvements but it remains compliant. I have worked on sites that were compliant but the UX so poor that nobody had a good experience.
Kevin
From: glen walker
Date: Tue, Mar 14 2023 3:08PM
Subject: Re: Accessibility of separate button on search suggestions flyout with Keyboard
← Previous message | No next message
> Totally - saying something is compliant doesn't mean that you can't note
improvements but it remains compliant. I have worked on sites that were
compliant but the UX so poor that nobody had a good experience.
Not quite the same but here's a fun article about getting a perfect
scanning score but be totally inaccessible.
https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/?sfw