Why We Use Form Elements to Build Filters in Webflow

‍

‍

Here at Finsweet, we are obsessed with breaking the limitations of Webflow.

As we built Attributes, we asked ourselves, "How can we build an integration experience that is as native to Webflow as possible, while offering a complete set of additional features?"

We decided the best way to do this was by integrating with Webflow's component structures, element types, default classes, and processes so that Finsweet solutions can be as “native to Webflow” as possible. Along with feeling native, we strive to make our add-ons accessible, easy to learn, and simple to set up. Which brings us to the purpose of this article.

Many of you have asked us why we are wrapping all of our Filter UI elements inside of a Webflow form element. This article will explain why we decided to go 100% form based for CMS Filter and why it matters.

By the end of the article, you’ll understand why form elements — not div blocks, link blocks, or button elements — are the best way to build a filter system. We'll also explain why many other top tech companies do the same thing.

‍

Simple definition of a filter

The role of a filter is to collect inputs from a user and modify the content of a website dynamically based on those inputs. 

When picking the elements that create our filter user interface, we want to keep this in mind. We're collecting inputs and communicating inputs to the website.

‍

Why use form elements?

First thing to note is that using form elements for filter systems is not new or unique in any way.

If you look at filtering systems on major sites like Amazon, eBay, Walmart, Target, Zara, and others, you'll see that they use form elements for their Filter UI elements as well.

Why?

Reason 1: Passing user inputs to the website

Form elements are designed to capture and pass information 

Form elements are designed to collect information from a user and pass it to the website. Think about a standard contact form. A user types information into input fields, selects their options, and submits the data. The user is communicating through web elements and passing information to the website for a later function.

This is exactly what a filter system does. It collects user inputs and passes the data to the website in order to filter the list.

Reason 2: Accessibility

Native form controls are keyboard accessible and semantically correct

We use form elements to assure we follow the highest level of accessibility practices. Attributes CMS Filter is accessible for screen readers, keyboard navigation, and other assistive technologies by default. Our filters are accessible by default because we made the decision to use form elements.

Here is an overview of why each of the following form input elements makes a good filter trigger.

1. Checkbox input:

• A checkbox can be natively navigated and activated with the keyboard.
• Checkboxes provide notifications to screen readers when checked. 
• Screen readers understand that a checkbox means multiple options are available to the user.

2. Radio input: 

• Radio inputs can be natively navigated and activated with the keyboard.
• Natively group-navigable. When a keyboard user focuses on a radio element they can then use the arrow keys to navigate through available options while the screen reader notifies them which is selected as they cycle through the options. 

Now let’s compare some other basic web elements you might be tempted to use to build your filter system. We'll see why they are not the right solution for filter elements.

Div Block
Divs are used to hold content and manage page layouts. They are not designed or optimized for receiving inputs or passing information. Additionally, div blocks are not keyboard navigable by default and cannot be triggered with the Enter or Space keys. 

Link Blocks
Link Blocks also assist with organizing content much like a Div Block, however they offer the added feature of allowing users to assign a URL path and often serve as navigational elements on a page. Additionally, since link blocks are navigational elements, screen readers may confuse users by telling them that the element is a link away from the selection rather than a filter toggle.

Button
Button elements are designed to be used as a click trigger for a call to action or specific user driven action. This could be submitting a form, adding a product to a shopping cart, or even paying at checkout. 

‍FAQ: "I'm triggering filter actions, why not use a <button> element?"‍

Remember: The heart of a filter system is to collect information from users and use that information to alter the state of the website. Form elements are built to collect information while <button> elements are simply designed to trigger a click. Furthermore, html buttons are not native in Webflow.

Element overview
‍

As you can see, div, link block, and button do not compare to form elements for our filter use case. While you might be able to use some of these other elements to build a filter system, we do not consider it to be a best practice.

<div> and <a> do not exist for purpose of communicating information. So their accessibility rules will be different.

To make non-form elements accessible in a filter system, we would have had to add additional attributes to various elements and then integrate with accessibility javascript libraries.

Using form elements allowed us to make the filters accessible out of the box.

The rest of the article evaluates each element outlined above and compares them based on the number of steps required to:

1. Accomplish a given task.
2. The complexity of each setup.
3. The total time involved.
4. The overall learning curve for each option. 

‍‍

‍‍Steps and complexity

🏆 Winner: Checkbox / Radio

With our form elements approach, we have to add a total of 3 attributes to implement a functional filter system. We have to define our list, filters, and field identifier. Once we have added those three elements, we’re done. We're proud about how we only require 3 attributes to set up a filter system. This means the system is simple with a lower learning curve.

If we allowed divs or link blocks, we would have to add a total of 6 attributes to implement a functional filter system. The original 3 listed above PLUS type, trigger, and active.

Below we will explain why we would need to add the additional 3 attributes across the Filter UI.

+ type

Form elements give us a lot of information about your Filter UI natively. This allows us to reduce the total number of attributes we have to add to our project.

For example:

When using radio buttons you tell us that you want an “exclusive” filter type for a group of options.

When using checkboxes, you tell us that you want a “multi” filter type for a group of options.

The option of "single" or "multi" is included within the element natively. We don't have to declare it.

Without form elements you would have to define the filter rules for each category of filters. This means you would have to place fs-cmsfilter-type = multi on each category wrapper to define "multi" or "single" filtering.

+ trigger

When using radios and checkboxes in Webflow, we must follow a specific structure. The Webflow radio and checkbox components each have three required elements — a wrapper, a label, and a checkbox/radio.

Since we understand this structure, we understand better what you want to communicate and where the click trigger is. One reason we ask you to place the fs-cmsfilter-field attribute on the checkbox label is so we can identify the parent wrapper, the official click trigger.

Without the guaranteed checkbox and radio structure in Webflow, you would be required to define the trigger. This means you would have to place fs-cmsfilter-trigger on every element in your Filter UI that acts as the click trigger to start the filtering.

+ active

'Active' is built into form elements natively. We don't have to define a custom state with form elements. When a checkbox or radio is selected, we are able to it through its native state. In Attributes, we're able to use the native checked state for both elements. There is no requirement for an active class state.

If we use div, link block, or button elements, we would then be required to define an active class.

Using divs, links, and buttons makes active class a requirement. This means you would have to place fs-cmsfilter-active on the element that receives the active class.

Summary of "Steps and complexity"

Allowing divs, links, and buttons to be Filter UI elements means you would have to add these additional attributes throughout your implementation.

• fs-cmsfilter-type attribute to define the filter system rules (exclusive or multi filtering).
• fs-cmsfilter-trigger attribute to define the trigger that initiates the filter.
• fs-cmsfilter-active attribute to define an active state.

And even with these additional attributes, the filter would not necessarily be accessible! To do that you might need another three or more attributes. 

• + tabindex, role, and aria accessibility attributes must be added to divs, link blocks, and buttons. These come baked into form elements.

This not only adds extra steps and extra complexity, but it also adds to the overall learning curve. Understanding 3 attributes is more inviting than understanding 6+ attributes. This goes back to our mission of reducing the learning curve when implementing a filter system in Webflow.

‍

Total number of Attributes required:
‍

Speed of setup

🏆 Winner: Checkbox / Radio

By creating a system that only requires adding a call to a single external javascript library and adding three different attributes to the page, Finsweet’s approach is fast.

Above we explain how there are less attributes needed when building the Filter UI. The additional attributes, longer documentation, and extra steps required for divs, link blocks, and buttons slow down the implementation process.

Our prior filter systems CMS Library (which is now deprecated) used divs and link blocks. There were significantly more steps and more explanation required to implement the system.

Attributes fixes many of those setup steps by using form elements for the Filter UI.

Here is what the community is saying:

‍

‍

Check out our Live Builds inside the Resources page. We set up filters live in minutes!

‍

Being Webflow Native

🏆 Winner: Checkbox / Radio

Checkboxes and radio elements are native form elements inside of the Webflow Designer. 

This means there is a settings panel for each element and we can:

• Visually style them natively in Designer
• Style a custom "Checked" state
• Use a "Start checked" option for Checkbox
• Manage Radio groups

All of these settings can be managed natively in Webflow and integrate fully with Attributes. What is more native than using Webflow's Designer controls to customize your filter?

Divs, link blocks, and buttons do not have this benefit. There are no native Webflow settings we can take advantage of to help us build our Filter UI.

‍

The Final Verdict

🏆 Winner: Checkbox / Radio

While it is technically possible to build a filter system using divs, link blocks and buttons (trust us we've been there) we now understand it is not the correct path.

It does not align with best practices for accessibility or modern web standards.

We will say this again:

As we built Attributes, we asked ourselves, "How can we build an integration experience that is as native to Webflow as possible, while offering a complete set of additional features?" Along with feeling native, we want our add-ons to be accessible, easy to learn, and simple to set up.

We believe using form elements for the Filter UI is the best way to achieve our goal for building integrations and add-ons to Webflow.

The short recap of why we don't use div, link block, or button

• Your filtering system will not be accessible by default
• There will be a higher learning curve if you want to build it correctly
• It will be harder to set up and maintain
• It will be easier to break, which may reflect on how others perceive your work
• It will take more time to set up
• It will require additional coding and external libraries
• It won’t take advantage of native controls in the Webflow Designer

Verdict: Form elements are the clear winner 

Whether you have a simple 10 item list to sort, a medium sized blog, or an enterprise size library of data that needs to be filtered in real time, using form elements assures that we follow industry best practices.

Our goal is to be the best solution available for filtering in Webflow — and that means using form elements. 

So what do you think? Did we convince you? Did we miss something? Feel free to let us know in the comments or on social media. 

And more importantly, be sure to share what you are building with the new CMS Filter setup using Attributes by Finsweet.