tomusborne
Navigation search bar needs accessibility improvements
Description
There are a number of accessibility problems with the search form in the navigation menu. Specifically, I am referencing this code for the open/close button:
<div class="menu-bar-items"><span class="menu-bar-item search-item active close-search">
<a aria-label="Close Search Bar" href="#"><span class="gp-icon icon-search"><svg viewBox="0 0 512 512" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" width="1em" height="1em"><path fill-rule="evenodd" clip-rule="evenodd" d="M208 48c-88.366 0-160 71.634-160 160s71.634 160 160 160 160-71.634 160-160S296.366 48 208 48zM0 208C0 93.125 93.125 0 208 0s208 93.125 208 208c0 48.741-16.765 93.566-44.843 129.024l133.826 134.018c9.366 9.379 9.355 24.575-.025 33.941-9.379 9.366-24.575 9.355-33.941-.025L337.238 370.987C301.747 399.167 256.839 416 208 416 93.125 416 0 322.875 0 208z"></path></svg><svg viewBox="0 0 512 512" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" width="1em" height="1em"><path d="M71.029 71.029c9.373-9.372 24.569-9.372 33.942 0L256 222.059l151.029-151.03c9.373-9.372 24.569-9.372 33.942 0 9.372 9.373 9.372 24.569 0 33.942L289.941 256l151.03 151.029c9.372 9.373 9.372 24.569 0 33.942-9.373 9.372-24.569 9.372-33.942 0L256 289.941l-151.029 151.03c-9.373 9.372-24.569 9.372-33.942 0-9.372-9.373-9.372-24.569 0-33.942L222.059 256 71.029 104.971c-9.372-9.373-9.372-24.569 0-33.942z"></path></svg></span></a></span></div>
and this code for the search form itself.
<form method="get" class="search-form navigation-search nav-search-active" action="https://gpsites.co/marketer/">
<input type="search" class="search-field" value="" name="s" title="Search">
</form>
The code examples here have been pulled from your Marketer demo in your Site Library.
Here are the specific problems:
1. The open and close buttons are incorrectly tagged as a link when they should actually use a <button> tag.
- Screen readers handle links slightly differently than they do buttons. All links and buttons are tab-able, but pressing the Space bar or Enter/Return triggers a button, whereas pressing the Enter/Return key only triggers a link.
- Links are used to navigate to a new page or a different page of the same page, not to trigger an interaction or open/close a modal as we're seeing with this search form.
- Ideally, this should be re-coded to have a
<button>tag, but if you're concerned that will be a breaking change, then it could be resolved by addingrole="button"to the existing<a>.
2. Input field is missing a visible label.
- Currently this field is completely unlabeled and it doesn't even have a hidden label available in the code for screen reader users.
- Missing labels on form fields is a WCAG violation. It is also important that the label is visible (and not be visually hidden but available to screen reader users), because sighted users benefit from the label too.
- The label needs to stay visible even when content has been entered in the field so that the field's purpose can be identified easily without having to delete the content in the field (I.e., placeholder text alone is not sufficient).
3. Keyboard focus is not trapped in modal dialog
- With the search open in the navigation bar, the user is able to tab outside of the search modal without first closing it. This is a failure of WCAG 2.4.3 Focus Order.
- Keeping focus within a modal presents a single task to be executed by the user (e.g., filling out a form). This keeps users moving through the task at hand, without accidentally going to another element on the page. Moving focus out of the modal unexpectedly will confuse and disorient blind, low-vision, and keyboard-only users.
- Trap focus within the modal, cycling through elements inside the modal. When the search is open, the tab key should go from the search field to the submit button to the close button and then back to the search field.
4. When closing the search bar, keyboard focus is not returned to the element that triggered it to open.
- Focusable components should receive focus in an order that preserves meaning and operability. When a modal is closed, focus should return to its triggering element. This is the logical and expected behavior. Moving focus to another element unexpectedly will confuse and disorient blind, low-vision, and keyboard-only users.
- When the modal is closed with the close button, we should see focus on the open button (with a visible focus outline) and a screen reader should announce to the user that they are on the button to open search.
- Currently when the search modal is closed there is no visible focus indicator and no auditory announcement so that blind/low vision users will know that they have successfully closed the modal.
5. Search form missing submit button.
- Currently there is no submit button on the search form, and users must use the return key to submit their search. This can be confusing for many users and may make the search difficult to use.
- There should be a correctly coded submit or search button added to the search form. Ideally this will be positioned in-line between the search field and close button that closes the modal.
- It is fine if the button visually shows only an icon (such as a right pointing arrow) as long as it is properly labeled for screen readers.
I hope this is helpful. I appreciate you resolving these accessibility problems. Please let me know if you have any questions.
References
Here are resources that might be helpful.
I have updated the issue above with a few more details for problems that were identified during user testing. Are you able to provide a timeline for this fix?
@amberhinds Thanks so much for this - really helpful! We're in the process of re-thinking our Navigation Search feature and may end up deprecating the current version of it in favor of a newly thought-out version.
I'm going to tag this as 3.3.0 so we can refer here as we build out the new feature.
Hi @tomusborne, thanks for the message and for taking my feedback into consideration. I'm happy to test the new version whenever you have it ready.
We're in the process of re-thinking our Navigation Search feature and may end up deprecating the current version of it in favor of a newly thought-out version.
@tomusborne Really needed. One question: The Gutenberg-Way?
We've added a new Navigation Search Modal feature to GP 3.3.0: https://generatepress.com/a-new-navigation-search/
Would love any feedback on its accessibility.
Hey Tom,
I can test it if you want, but do you have a zip or - even better - a link to a demo site?
Amber Hinds Creative Director & CEO Road Warrior Creative
@.*** • (512) 942-5858 <5129425858> ext. 3 *Connect With Me on LinkedIn http://bit.ly/AmberLinkedIn *• https://roadwarriorcreative.com
On Wed, Mar 22, 2023 at 11:03 AM Tom Usborne @.***> wrote:
Closed #430 https://github.com/tomusborne/generatepress/issues/430 as completed.
— Reply to this email directly, view it on GitHub https://github.com/tomusborne/generatepress/issues/430#event-8818645962, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADELJMG4J74ZQDWWPWH756LW5MPFDANCNFSM6AAAAAAQCXQK74 . You are receiving this because you were mentioned.Message ID: @.***>
@amberhinds you can test it by using the latest GeneratePress version 3.3.0. You can enable it on Customizer > Layout > Primary navigation.
Thanks, but I don't have GeneratePress. 🙂
Amber Hinds Creative Director & CEO Road Warrior Creative
@.*** • (512) 942-5858 <5129425858> ext. 3 *Connect With Me on LinkedIn http://bit.ly/AmberLinkedIn *• https://roadwarriorcreative.com
On Mon, Mar 27, 2023 at 1:09 PM Jean Paiva @.***> wrote:
@amberhinds https://github.com/amberhinds you can test it by using the latest GeneratePress version 3.3.0. You can enable it on Customizer > Layout > Primary navigation.
— Reply to this email directly, view it on GitHub https://github.com/tomusborne/generatepress/issues/430#issuecomment-1485612636, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADELJMD4BX3Z5OCKEMLVZ6TW6HJUNANCNFSM6AAAAAAQCXQK74 . You are receiving this because you were mentioned.Message ID: @.***>
