[Resolved] Taxonomy based filters are missing the ID attribute.

[Author]

Posts

[alyssaD]

I am trying to: correctly display taxonomy filters and manually create a label element that points to the ID for the rendered taxonomy select element. No ID is generated.

I expected to see: an ID attribute on the taxonomy select element with a value relevant to the field.

Instead, I got: a taxonomy select element without an ID attribute, which means I can't create a label to target that element.

I tracked the code down to the

wpv_render_taxonomy_control

function in the wpv-filter-embedded.php file. The code that has a problem is on line 3182 for single select and on line 3189 for multi-select elements:

echo '<select name="' . $name . '"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'">';// maybe it is $name and not $taxonomy, and maybe slug-**; we need to add the influencers here

echo '<select name="' . $name . '[]" multiple="multiple"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'" size="10">';

Note that there is no ID attribute being output. If however, you look at the radio and radios output just below (starting on line 3199) you will note that on line 3214, the ID attribute is being output:

echo '<input id="' . $name . '-"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'" name="'.$name.'" type="radio" value="0"' . $default_selected . '/>

This makes it impossible for taxonomy select elements to comply with Accessibility best practices, as you can not target the select elements with a form label.

My suggested fix would be to treat the ID's here like you do for select elements that are NOT taxonomy based (using 'wpv_control_select_' as the namespace), and this is the diff that I have based on that theory:

--- wp-views\embedded\inc\wpv-filter-embedded.php 
+++ untitled 1 
@@ -3179,14 +3179,14 @@
                 }
                 
 				if ( $type == 'select' ) {
-					echo '<select name="' . $name . '"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'">';// maybe it is $name and not $taxonomy, and maybe slug-**; we need to add the influencers here
+					echo '<select  id="wpv_control_select_' . $name . '" name="' . $name . '"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'">';// maybe it is $name and not $taxonomy, and maybe slug-**; we need to add the influencers here
 					if ( empty( $terms ) || in_array( (string) 0, $terms ) ) {
 						$default_selected = " selected='selected'";
 					}
 					// TODO we do not add counters nor any format here, as we do for custom fields. WE might need to review this.
 					echo '<option' . $default_selected . ' value="0">' . $default_label . '</option>'; // set the label for the default option
 				} else if ( $type == 'multi-select' ) {
-					echo '<select name="' . $name . '[]" multiple="multiple"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'" size="10">';
+					echo '<select id="wpv_control_select_' . $name . '" name="' . $name . '[]" multiple="multiple"'. ( !empty($style) ? ' style="' . $style . '"' : '' ) .' class="js-wpv-filter-trigger'. ( !empty($class) ? ' '. $class : '' ) .'" size="10">';
 				}
 				$temp_slug = '0';
 				if ( count( $terms ) ) {

Potential problems with this would be if the same filter was added to the same view more than once. In this case, the ID would be the same on both elements which is bad. Although it seems to me that this issue exists now with any filter, as none of the output code adds any sort of increment counter. (see the second image)

[Luo Yang]

Dear alyssa,

This should not be a bug of Views plugin, you are asking for the new features, if you agree, we can take it as a feature request.

[alyssaD]

I disagree that this is a feature request, all of your other filter output types (anything that's not a taxonomy select element) correctly output the ID attribute on their form elements.

This seems like an oversight in the code section that I highlighted. Without that ID attribute your plugin does not produce HTML markup that supports those with visual disabilities that have to use screen readers.

If you want to mark it as a feature request, that's fine, but you are ignoring a growing desire for accessible content, and in many cases, the lack of support for accessibility means that your plugin can not be used on websites that are subject to Section 508 of the American's With Disabilities act, as well as the growing support for WCAG2.0 across the globe.

[Luo Yang]

As your request, I change the topic type of this thread to "Requests", and forward it to our developers to evaluate it.

[Juan]

Hi there

Thanks for the feedback.

I am taking note of your request to add the id attribute to taxonomy filters in select mode. It sounds just right to have them, so you can add your own labels.

However, I am not entirely following about the uniqueness. Why would you add the same filter twice to the same form? I can understand that if you have the same form more than once, say because you dispaly it before and after the results, or becauseyou also have it on a widget, this might happen, but it si a rare case. We will look into it too.

I can not give you an estimate of the time this will take, as this will demand a complete review of the output for all field types, but I will try to put it with somehow a high priority 🙂

Hope it helps.

Regards.

[alyssaD]

The uniqueness issue I mentioned is not really a major problem, as your filter builder (the WYSIWYG like interface) prevents the same filter form being added to the same View.

However as you stated, if you have a view in the body of a page, and another view in a widget on that same page, both of which had a filter element for the same field, those fields would have the same ID, which does not comply with the HTML spec.

I understand that generating unique ID's like this is a massive undertaking for the code base and not something that would occur easily.

On the other hand, providing an ID for each form element that is output does not seem like a huge amount of development time. I admit the fix I provided in the first post is a limited solution and I certainly do not claim to have a complete understanding of your code base, so a long term solution is probably more complex.

Thanks for the feedback.

[Juan]

Hey there

Thanks again for the feedback.

Sure, providing an unique ID for each form element, counting on the fact that the same form can be rendered twice (post content plus widget) on the same page, is not a big deal. Mak it work for you as an end use is indeed complex. Because once we generate an unique, but dynamic (based on the repetition of forms for a page), ID for a form element, how can you, with a static HTML label added manually to the Filter editor, target each of the repetitions of the form elements? Unless that label has any dynamic element, it will target one, being lucky, but not the form element of the, say, second or third repetitions of the form in this same page...

We have the same kind of request for the other forms in the Toolset family, CRED forms, as you can have more than one form on the same page. This is certainly a complex but important projct that we will have to dedicate resources to in the near future.

Regarding the fix in the first post, I would not call it properly a fix. Messing with plugin core files is not a suitable solution in the long run. After you update to a new version, you might have to apply the same changes again, and the code might have changed a lot. In fact, we have some plans to revamp the Filter editor section regarding frontend filters, to make them extendble to other filters like post type, post author and whatnot. The methods used to display such form elements might, and will, change a lot in the not so long future. So I would probably suggest waiting until a core solution is provided.

Hope it helps.

Regards.