Selectify replaces Drupal's browser-default select lists, radio buttons and checkboxes with keyboard-accessible components, and it applies them in four distinct places on a site — field widgets, Views exposed filters, Webform elements and plain Form API selects — each configured separately.
That last part is the bit most evaluations miss. Selectify is not one switch. Knowing which of the four surfaces you are configuring is the difference between a five-minute setup and an afternoon wondering why the dropdown on your contact form looks nothing like the one on your search page.
The four surfaces, and the fifth thing
| Surface | Configured at |
|---|---|
| Entity field widgets | Manage form display, per field |
| Views exposed filters | Site-wide default, or per View |
| Webform elements | Site-wide or per Webform — needs the selectify_webform sub-module |
| Any other Form API select | Per form, with automatic form discovery |
| Radio buttons and checkboxes | Globally, at /admin/config/selectify/settings |
Radios and checkboxes are the exception: they are styled site-wide from one settings page rather than per field. Both behaviours can be switched off on any page or set of pages using path patterns, which matters more than it sounds — the shipped default already excludes admin/appearance/settings/gin, because a settings form that restyles its own controls while you configure them is a bad time.
Five select widgets, and which one to reach for
Five field widget plugins ship, verified from the #[FieldWidget] attributes in src/Plugin/Field/FieldWidget/. All five accept the same field types — list_string, list_integer, list_float and entity_reference — so the choice is about interaction, not data.
Selectify Dropdown (selectify_dropdown)
The baseline. Same open-and-pick behaviour a user already knows, with styling and clear selected-state feedback. This is the right default for exposed filters where you do not want to teach anyone anything.
Selectify Dropdown Taggable (selectify_dropdown_tags)
Selections appear as removable tags below the control. Use it when a user builds up several choices and needs to see the set without reopening the list — taxonomy terms, product attributes, group membership.
Selectify Dropdown With Search (selectify_dropdown_searchable)
Adds live filtering to the tag behaviour. This is the answer to the vocabulary with four hundred terms, where scrolling stops being a viable interaction. The search input takes focus when the menu opens, so a keyboard user starts typing immediately.
Selectify Dropdown With Checkbox (selectify_dropdown_checkbox)
Puts an explicit checkbox next to each option inside the menu. Choose it when the cost of a wrong selection is high and you want unambiguous state rather than a highlight — permissions, notification preferences, anything an auditor may read back.
Selectify Dual List (selectify_dual)
Available options on one side, selected on the other, with items moved between them and a Clear All control. It is the heaviest option and the most legible for large selected sets, because "what have I chosen" is a whole panel rather than a line of tags.
Radio buttons and checkboxes
Radios and checkboxes each get three settings, with identical options for both: a style (toggle switch, or traditional with an X and checkmark indicator), a shape (circle or square), and a size (small, medium or large — the form's own help text recommends large for touch interfaces and accessibility).
There is also an optional toggleable-radio behaviour. Standard HTML radio buttons cannot be unset once one is chosen; the only way back to "no answer" is a reload or a "none" option. Selectify's implementation tracks a wasChecked flag and lets a second click clear the selection. That is a deliberate departure from the platform, so use it on genuinely optional questions and not on a required one, where users expect a choice to stick.
Accessibility: what is actually implemented
The module states WCAG 2.1 Level AA compliance in its own info.yml and README. Rather than repeat the badge, here is what the code does, read from the fourteen JavaScript files.
The dropdowns are built on the combobox pattern: a role="combobox" container whose aria-expanded is toggled as the menu opens and closes, with aria-controls, aria-labelledby, aria-activedescendant to track the focused option, and aria-selected and aria-disabled on the options themselves. Selection changes are announced through a live region, and aria-busy covers the interval while a list is being rebuilt. Keyboard handling covers arrow keys, Enter, Space, Escape and Tab.
Two honest caveats. First, an ARIA implementation that is correct in the markup can still be wrong in a screen reader, and this pass read source rather than running NVDA or VoiceOver — test with a screen reader before you sign a compliance statement. Second, replacing a native control always trades away something the browser gave you for free. If your form is three plain selects on a public page, the native ones are already accessible and already fast; adding a JavaScript component to them is a net loss.
If accessibility is the reason you are here, the mechanics of announcing dynamic changes to assistive technology are worth understanding on their own terms — that is covered in ARIA live regions in Drupal 11.
Colour, theme integration and the admin
Seven accent colours ship — blue, coral, gold, indigo, neutral, slate and teal — each with a light and a dark variant, plus a "none" mode that leaves browser colours alone. Front end and admin are configured separately, which is why a site can use its brand colour on public forms and something quieter behind the login.
Theme-specific stylesheets ship for Gin (base, light, dark and auto), Claro and Olivero, read from selectify.libraries.yml. That matters because admin themes style form controls aggressively and a component that ignores them looks pasted on.
Everything sits behind a single permission, administer selectify settings. Where the concern is the wider admin form experience rather than the controls themselves, customising node edit forms per content type covers the layout half of the same problem.
Requirements
| Item | Value |
|---|---|
| Drupal core | ^10 || ^11 || ^12 |
| PHP | >=8.1 |
| Dependencies | Core views and field |
| jQuery | None. Libraries declare only core/drupal, core/drupalSettings and core/once |
| Sub-module | selectify_webform, for Webform surfaces |
| Maintainer | Alaa Haddad, per composer.json |
The Drupal 10 through 12 range is unusually wide for a module of this kind, and it is worth noting when you are assembling a stack that has to survive a core upgrade rather than be rebuilt for one.
When not to install it
Skip it when your forms are short and native controls already work; when you have a design system with its own form components, because you will fight it; and when nobody on the team can test with a screen reader, since a styled control you cannot verify is a risk you have taken rather than a feature you have shipped.
Install it when a select list has enough options that finding one is the problem, when multi-select is confusing your users because Ctrl-clicking is undiscoverable, or when the admin experience you hand to a client needs to look considered.
Common questions
Does it work on Webform without the sub-module?
No. Webform surfaces need selectify_webform enabled; the settings form only renders the Webform section when that module exists.
Can I use different widgets on different fields?
Yes. The five widgets are field widget plugins, so each field's setting in Manage form display is independent. There is also a site-wide default, shipped as selectify_dropdown.
Will it slow my forms down?
The JavaScript is about 2,265 lines across fourteen files with no jQuery, loaded per widget type rather than all at once. That is small, but it is not nothing, and it applies to every page carrying a styled control. Measure on your own site rather than taking a line count as a performance claim.
What happens to users with JavaScript disabled?
The underlying native select is what Drupal submits. Needs checking on your own build: confirm the no-JavaScript path submits correctly before relying on it in a regulated context.
How does it relate to the Solo theme?
The module's README records that Selectify began as a feature inside Solo and was extracted so any site could use it, whatever its theme. It has no theme dependency now.
Where to go next
The Selectify project page has the settings screenshots. Install it on a development copy, style one field, and put it in front of the person who fills that form every day — that is a better test than any feature list. For a look at the same treatment applied to the module administration screens rather than forms, see Module Matrix. If the underlying problem is a form nobody completes, that is usually a content model question before it is a widget question: Drupal development or a direct message through contact is the faster route to an answer.