Accessibility Issues with Search Function
We have a website that uses BeTheme and needs to meet WCAG 2.0 Accessibility Standards.
When using only TAB and ENTER keys to navigate a webpage, the search function on our website has a major problem.
We have a navigation menu in the header, with an Icon set as Icon Type: Search. Clicking on this Icon opens a search field with a semi-transparent overlay, and functions properly with a mouse and keyboard.
Using Keyboard only navigation, if a user presses TAB when the search field is focused, the TAB focus traverses through the entire page content behind the search field overlay, which is obscured and blurred by the overlay. This is a severe “Focus Trap” and is a major issue. When browser scroll is disabled, the search field can be come out permanently out of view when background elements are traversed with TAB.
The desired behavior is to only have the Search field and X Close button focusable when the search field is open. Keyboard Focus should never switch to main page content behind the blurred / semi-transparent content overlay.
A related issue is that the search field does not have an ID attribute configured. The associated labels for the search form have a for=”s” attribute. The search field has name=”s” , but not id=”s” , so these labels are registered as orphaned with website accessibility checker tools. Proper HTML structure is to have all labels linked to an input element where the label’s for attribute matches the input’s id attribute.
Relevant Betheme settings for these issues are:
Theme Options>Accessibility
--Keyboard Support is Enabled.
Theme Options>Search>Form
--Search Icon Is Hidden
Theme Options>Search>Form Design
--Browser Scroll is Disabled
--Content Overlay is Enabled
Thank you for your assistance, this is a major issue that prevents our website from complying with modern accessibility standards.
Comments
Hi,
Please always attach a link to your website so we can check it out. If the page is offline(localhost), then our help will be limited. You will have to contact us when the page is online. Also, please make sure that the page is not under maintenance before you provide us with the link.
It is always a good idea to also attach a screenshot showing your issue.
Thanks
Hi, thank you for getting back to me.
Our site using Betheme is live at https://mvdmt.gov/
When viewing the site, click the search icon. When focus is in the search field, press tab multiple times to see issue with focus traversal through background content. Blurred elements behind semi-transparent overlay should not be focusable.
For the issue of the "Orphaned Search Label", see the screenshot below of the WAVE accessibility checker tool with styling turned off.
Note that the label identified as orphaned has attribute for="s" and the associated text input elements only has attribute name="s"
Thank you for your assistance in resolving these issues. Please let me know if you have any additional questions!
Unfortunately, I cannot access your website, as I mentioned here:
https://forum.muffingroup.com/betheme/discussion/77965/accessibility-issues-with-mega-menu-tab-order#latest
Anyway, additionally, you can send us the WordPress dashboard and FTP access privately through the contact form, which is on the right side at https://themeforest.net/user/muffingroup#contact try to correct that directly on your website.
Notice!
Please attach a link to this forum discussion.
Sending incorrect or incomplete data will result in a longer response time.
Therefore, please ensure that the data you send are complete and correct.
Thanks
Hi again, similar to my other issue with Mega Menu accessibility issues, if you are able to use a VPN with location set to the US, you can see keyboard tab focus order behavior with the search function on our website.
https://mvdmt.gov/
If you are not able to diagnose this issue through use of a VPN let me know.
For reference on desired behavior of the search popup, you can reference the following standards.
Dialog (Modal) Pattern
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/Thank you again for your assistance!
We have it on our to-do list for the upcoming updates.
Best regards
Hi again, I see that your team made improvements for this issue in recent updates, thank you for passing that along!
>>Pressing TAB forward through the form now prevents focus from going behind the overlay onto the page.
There are still some issues with the search popup:
-Pressing TAB + SHIFT to move backwards through page elements still allows focus to traverse behind overlay onto page elements.
-Pressing ESC should close search window
-Focus should be kept within the popup modal, requiring users to either search, active close button or press ESC Key.
Again, these requirements are outlined by w3 accessible design patterns for your dev team.
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
>>Previously "orphaned" Labels are now linked to Search field.
However, there are now new errors with our site that has a separate Default Header and Sticky Header, each header has its own search button. There are 2 search popup forms being created, and both have a search field with id="s" and a label with for="s", meaning there is a conflict with the labels.
This introduced new errors with the WAVE accessibility checker tool:
-"Multiple form labels: A form control has more than one label associated with it."
-This may not be an issue with screen readers in practice as only one is visible, but this results in errors with accessibility checker tools for every page.
Thank you again for responding so quickly to these issues. Accessibility requirements are really tricky and complicated.
Thanks for letting us know. I passed it on to the dew team, and we will also correct this.
Best regards