Hello,
I'm optimizing a project built with Toolset, but I've noticed that all archive pages have these accessibility issues (according to google lighthouse)
- All focusable elements must have a unique id to ensure that they're visible to assistive technologies
- Form elements without effective labels can create frustrating experiences for screen reader users
Is there a way to resolve this? Do you plan to cover these issues in any updates?
Thanks greetings
Hi,
Thank you for contacting us and I'd be happy to assist.
To troubleshoot this, I'll need to see how these archive pages are set up in the admin area.
( technically there should be only one select search field for a specific custom field on an individual archive page, but your screenshot is showing two )
Can you please share temporary admin login details, along with the link to an example archive page?
Note: Your next reply will be private and making a complete backup copy is recommended before sharing the access details.
regards,
Waqar
If it is really necessary I think I can share access information (it is a bit delicate, I would like to think about it a little more)
But first I would ask you to pass any archive page through:
hidden link
I'm pretty sure it's an accessibility issue for everyone
For example, selecting any website from the Toolset Showcase:
https://toolset.com/showcase/ibba-canada/
hidden link
If you pass that url through the Google tool it will mark the same errors that I mention
To create two fields with the same id in the search filter, you must select the comparison value "between" that creates two labels with the same id (for example, when working with minimum and maximum)
If you prefer, we can leave it as a kind of bug report so that in future updates you can improve the accessibility of the plugin
I would appreciate an answer. If there is no simple solution I would like to leave it as a report
If you improve these accessibility details, the websites with Toolset would be more inclusive while slightly improving your clients' SEO. Everyone wins
Thank you for waiting as we had a busy forum queue over the weekend.
Based on your report, I was able to reproduce this behavior on my test website too.
In Toolset views and archives, if the search fields with the 'between' comparison are used, both inputs have the same ID.
I've shared these findings with the concerned team and will keep you updated through this ticket.
Appreciate you brought this forward.
Thank you, please consider both observations. It is also desirable that selectable elements have a label. I think that in this sense the simplest thing is to use the placeholder text as a label for the selectable field
If the placeholder text is used, the person with visibility problems will consult the upper text of the taxonomy field. So the person will read "taxonomy" first and then "all". I think it is the simplest approach, since if a web design puts the filter without a label, the placeholder text is probably going to be very descriptive, it would make sense in practically all scenarios.
The only scenario where there could be a problem is when someone designs a filter without a label and without a placeholder. But that's confusing even without disability, since the name of the first taxonomy would appear while all the elements are displayed. I think the simplest thing for everyone is for the placeholder text to be used as a label for a selectable field.
Please consider that there are 2 accessibility warnings for Google
Thanks for writing back.
Toolset search fields add the label attribute, but the 'for' attribute is linked to the 'name' attribute of the input field when it should be linked to the 'ID'.
We already have an internal ticket to make these search form markup ADA-compliant, for better accessibility. I don't have a time estimate to share at the moment, but I've added your voice to this ticket too.
I think it would be easier for the disabled person to understand name instead of ID
But I'm glad that you take it into consideration, thank you very much. Just please remember that from Google PageSpeed Insights' perspective these are two separate warnings.
