New to the community? Start here

[Forminator Pro] Turn off placeholder text in Forminator

0

Hi,
It would be great if there were a feature in forminator to turn off all initial placeholder text. Some screen reader users are reporting that the placeholder text that is created when some fields are created in forminator is confusing them.

Tue, 19 Apr 2022 9:35:31
More Forminator Pro discussions
Forminator Pro
  • Adam
    • Support Gorilla

    Hi cornelius_butler

    I hope you’re well today and thank you for feature suggestion!

    Currently, you can change or remove placeholders “per field”. You can edit each of the form field separately and if there is a “placeholder” setting, you can simply remove text from “placeholder” option.

    I understand that you would prefer to be able to do this “in bulk” then, right?

    I think this could be an option in “Appearance” setting of each form but let me ask:

    – should it simply clear/remove default placeholder text from all over the form but keep those that you already customized?

    – or should it “wipe out” all of them?

    – or should it be more like “hiding/showing” set placeholder texts, regardless whether they are default ones or custom texts?

    Best regards,
    Adam

    • Adam
      • Support Gorilla

      Hi Stuart

      There wasn’t many requests for this so far besides this one so it’s not yet scheduled for implementation but we already have similar feature on a list of things that may possibly be added at some point in future.

      We’ll keep this feature request thread open to see if more Members would request it – more requests usually can speed up implementation.

      Best regards and thank you for your feedback,
      Adam

  • Tony G
    • Mr. LetsFixTheWorld

    Adam Czajczyk – I think this one should get some attention.

    Accessibility isn’t the kind of requirement/demand that bubbles up easily from a user/visitor base to owner, then designer, then plugin providers. When a concept actually does bubble up to the WPMUDEV level, I think it’s worthy of notice and consideration for all of the similar requests that were left with a head shake, an abandoned page, an un-read note to some webmaster@ address, a “thank you for your suggestion” note that was forgotten by some tier-1 support bot or responder, an “I dunno” by some web designer, or a “OK, but handicapped people don’t rank high in our demographic, so we aren’t officially spending any time on them” response by site owners and management.
    What I’m saying is, for each 1 request like this that DEV gets, we have no idea how many requests didn’t make it up the chain. No one can credibly claim numbers like 1:100 or 1:1000, but I’m always compelled to believe it’s more than most of us might think, and I wish we could get metrics on it to help with management (request approval) decisions.

    I was reading an article in Medium a couple months ago by Daniel Berryhill, who is on a quest to create more awareness of nuances like this. I read his material with an open mind, disagree with some points (like disabling buttons), but felt educated and convinced by him on this topic of placeholder text.

    There’s another similar topic on which Daniel wrote that I found compelling, avoiding floating labels.

    To keep this all on topic, I would propose consideration for some general concepts:

    1) Provide a form-specific setting to change plugin-level defaults as topics like this come up.

    2) If DEV isn’t going to do that, just add filter hooks so that we can share code to do this on our own. The hooks will receive a form ID and field ID, maybe the entire form and field settings, and fields can be tweaked to remove placeholders (or whatever) for individual forms or fields.

    3) Stop making defaults so hard to override. This placeholder situation and all other defaults were easy to see as being potentially problematic during the development of Forminator. I wouldn’t be surprised if one of us commented on this during the initial beta. DEV developers don’t know what users are going to want (I’ve commented on that many times here) and they should stop imposing their limited world view on plugins used by extremely diverse global audiences. The best solution is build in flexibility – to change or deactivate defaults in the plugin UI. The next best solution (also commented on many times here) is that when a developer there hard-codes some preference, and clearly knows that someone else might want something different, mandate that a hook be added at development time so that the data can be changed by site admins. Making us beg for years for post-production changes never looks good.

    So look, it’s been two years and we know the OP request will never get prioritized to production. There might already be a hook that can be used for this. I don’t think so or someone would have mentioned it. But for this and so many other dead requests in these forums, the lack of a solution results in a long-term marketing/revenue problem that doesn’t need to exist. But if you add/document/recommend filters in response to requests, an inexpensive soluton, then more tickets can be closed as completed and many more people can walk away happy. More importantly, we can walk away to do more important things in life than spending time here. Your goal should not be so much to provide the excellent support that you always do, but to eliminate the need for us to be here to ask for support. That starts with self-help options and that starts with hooks.

    Thanks

    • Adam
      • Support Gorilla

      Hi Tony G

      Thank you for your feedback.

      I’ve actually written quite a long response to it addressing it “point by point” but after reading it I’ve realized I’m not quite in a position to post it. I realize that my response now goes in line with what you described as a “thank you for your suggestion” note that was forgotten by some tier-1 support bot but let me assure you that I’m not a bot (none of us responding here is) and I actually really passed over your feedback to the Forminator Team to be checked by the team/product management.

      Kind regards,
      Adam

      • Tony G
        • Mr. LetsFixTheWorld

        LOL – Adam Czajczyk that was about comments and support requests sent to “webmaster” or a similar catchall on individual sites – certainly not about WPMU DEV.

        I was (ineptly?) describing the number of channels that are between the experience of a browser user / site visitor, long before a comment even gets to WPMU DEV or lands on the desk of a decision maker there. I was suggesting that if you guys get one request about Accessibility (A11Y), it’s a miracle due to the broad lack of industry interest in the topic. So when you get that one request, I think it should be considered with more weight than most others. I don’t mean that every A11Y request is valid, just that the weight of significance should be factored into the decision making.

        BTW, I’m no A11Y champion. I’m fairly ignorant on the topic. But over time I’ve realized my ignorance, and as I rethink how we do some things here I’m sharing some of my newfound understanding with others – just paying forward and back.

        I admit that over the last couple years my enthusiasm for DEV has been tempered with the process and priorities there, and this is evident in many of my responses that are laced with frustration of futility. Thanks for patience with my process, and I’m sorry if my new tone has influenced your notes.

        But I truly welcome personal insight and comments by all WPMU DEV staff, especially those of you who know code, systems, protocols, WordPress, ecosystems, and generally how things work in the technical world. To me, you guys aren’t tier-1-2-3, you are simply “the team”. I know you share challenges, and I never think that notes here haven’t made it through to decision makers.

        Almost all of my angst here comes from strong disagreement with the invisible decision makers – the people whose choices convey to me a level of inexperience, and have obvious foreseeable consequences that then compel Support to have to respond to requests that never should have been necessary. But I also understand that we’ve all done our jobs – I report stuff and leave it to DEV to decide what to do with it. If I don’t like the results I can shutup or maybe take my business elsewhere. These days I do a little of both – except for today I guess. :upside_down: