Do Faymas Forms Say Where Your Message Goes? Only 8 of 13 Do

Eight of thirteen. We pulled every form control out of forty URLs across the four faymas domains — thirty-five unique pages, once you remove six URLs that all serve the same homepage — and counted 13 <form> elements, 45 <input>s, 15 <textarea>s, 49 <label>s and 349 <button>s. Only 8 of those 13 forms carry an action attribute that names where your typed text goes. Every one of the 8 sits on faymas-in.com, and all 8 are WordPress output: four comment forms and four search blocks. The five that don't include every contact form that exists on any of the four domains.

Updated October 29, 2026 · Prompt-text analysis

This guide analyses published prompt text. No generation tests were run.

What we counted

We fetched a fixed list of forty URLs — homepages, contact pages, legal pages, category pages and individual prompt pages — twelve each on faymas.in, faymas.net and faymas-in.com, four on faymas.com.in, which is all that domain's own navigation exposes. One Chrome user agent. Redirects followed. No JavaScript executed. 29 October 2026.

Then we deleted every <script>, <style>, comment, <noscript>, <template> and <svg> block before matching anything. Two of these sites ship markup strings inside their inline payloads. A <button> written into a JavaScript bundle is not a button a reader can press.

Six of the forty URLs are not six pages. On faymas-in.com, /about-us/, /contact-us/, /disclaimer/, /privacy-policy/ and /terms-and-conditions-2/ each answer 301 and land on the homepage, all six returning the same 70,244 bytes. We hash-compared the documents and kept one. Forty URLs, thirty-five pages. Every total below counts unique pages, not requests.

This cluster has handed us two different documents for one URL before, so we re-fetched three pages three times each with the same user agent. faymas.in/ returned 28 buttons every time. faymas.net/prompts returned 22 buttons and 1 input. A faymas-in.com post returned 8 buttons, 8 inputs and 2 forms. Nothing moved.

Twenty-six of the thirty-five pages contain no form at all. The median page carries three buttons and zero input fields.

Only 8 of 13 forms say where your text goes

Two action values exist in the whole corpus. Four forms post to https://faymas-in.com/wp-comments-post.php. Four more send a GET to https://faymas-in.com/. That is the complete list of named destinations on four domains — and both values are WordPress-generated, one from the comment template and one from the core search block.

The other five forms name nothing. Three of them are the contact forms: faymas.in/contact (three inputs plus a message box, all four required), faymas.net/contact (name, email, message) and faymas.com.in/contact-us. The fourth is faymas.in/search, which has no action, no method and no submit control of any kind. The fifth is the search box on the faymas-in.com homepage.

A form with no action is not broken by definition. The browser falls back to the page's own URL. But the fallback only carries the fields as query parameters, and three of these five forms are contact forms whose fields were plainly not built for that. We ran no JavaScript, so we cannot tell you what actually happens when you press send. We can tell you what the HTML says, and the HTML says nothing.

One domain opts out entirely. faymas-in.com has no contact form, because /contact-us/ redirects to the homepage. So across four faymas domains, three contact pages exist, three contact forms exist on them, and none of the three declares a destination.

faymas.com.in deserves its own note, because it is the one place where the destination is moved rather than missing. Its form carries method="post" but no action, and inside it sits <input type="hidden" name="action" value="kb_process_advanced_form_submit">. The handler name travels as a field. If you were auditing this site by reading action attributes, you would score it as having no destination. It has one; it just isn't where the attribute lives.

Three inputs have no name, and all three are search boxes

Forty-two of the forty-five inputs carry a name. Three do not, and the three are not random: they are the search field on faymas.in/search (placeholder "Search prompts…"), the search field on faymas.net/prompts ("Search prompts, styles, …") and the search field on the faymas-in.com homepage ("Search AI tools, prompts…").

An unnamed field cannot appear in a submitted query string. It cannot be submitted by a browser at all. All three of the faymas search boxes therefore do their work only if JavaScript reads them — which is consistent with the fact that one of them also has no submit button.

The rest of the field-level picture is ordinary: 16 of 45 inputs are marked required, 26 carry a placeholder, 2 carry an aria-label, 1 has an autocomplete attribute, and none is disabled. The two React-built contact forms also reveal how they were made: faymas.in uses stable, human ids (name, email, subject, message), while faymas.net generates them at render time — _R_b9bsnpfkniqjaivb_-form-item and two siblings sharing the same runtime token. faymas.com.in uses a third style, hashed ids like fielde2f781-7e. Three contact forms, three id conventions, one shared omission.

The only four dropdowns on any faymas site are hidden

Four <select> elements exist across thirty-five pages. All four are on faymas.net — the homepage, /ai-image-generator, /nano-banana/nano-banana-2 and /veo/veo-3-1. All four carry aria-hidden="true", tabindex="-1" and a one-pixel clip-rect style that takes them off screen.

So the count of visible dropdowns on the four faymas domains is zero. Whatever pickers these pages show you, they are built from buttons: 80 buttons across the corpus expose aria-expanded, 65 carry aria-controls, and one carries aria-haspopup. The native select survives only as a hidden helper.

The rest of the interactive vocabulary is equally absent. Zero <details>. Zero <dialog>. Zero contenteditable regions. Zero elements with role="button". On four sites that otherwise differ on almost everything, they agree on this completely.

349 buttons, and 8 of them live inside a form

The ratio is the finding. Thirty-five pages carry 349 buttons against 45 inputs — 7.8 buttons for every field you can type into, and 26.9 buttons for every form. Only 8 buttons in the entire corpus sit inside a <form>; the other 341 have nothing a browser could submit.

Split the four domains by how they are built and the split is close to a mirror. The two app-shell domains, faymas.in and faymas.net, give you 24 pages containing 3 forms, 7 inputs and 309 buttons. The two WordPress domains, faymas-in.com and faymas.com.in, give you 11 pages containing 10 forms, 38 inputs and 40 buttons. Roughly: where one pair puts a button, the other puts a field.

It shows up in the textareas too. Eight of the fifteen textareas on these sites are not inside any form: four are the prompt boxes on faymas.net tool pages, and four are copyable prompt blocks on the "multi-pose" post, which ships five textareas and uses one of them as its comment field. You type into a box that belongs to no form, and the thing next to it is a button.

Which means "does this site have a form" and "is this site interactive" are two different questions here, and the four domains answer them in opposite directions. faymas.net averages 13.5 buttons per page and has one form on twelve pages. faymas.com.in averages 2.8 buttons per page and puts a real, fielded contact form on one of its four pages.

The one thing all four get right

Not one button lacks an accessible name. Of 349 buttons, 131 carry an aria-label — 7 of those also carry a title — and the other 218 have text between their tags. Zero are aria-hidden. Four are disabled. For a corpus this size, that is a clean result, and we did not expect it.

Focus order is clean too. Thirty-two tabindex attributes exist and all thirty-two are on faymas.net: twenty-nine set to -1, three set to 0. Not one positive value anywhere, so no element on any of the four domains is jumping the queue.

Say it plainly: the accessibility basics here are fine. Buttons are named, focus is not hijacked, nothing is hidden behind an unlabelled icon. The gap sits one layer up, at submission — in the attributes that say where a message goes, and in the three fields that cannot be submitted at all.

What we did not measure

Thirty-five pages is a sample drawn from each site's own navigation, not a census; faymas.in lists far more prompt URLs than we read. We ran no JavaScript, so everything assembled in the browser after load is outside these numbers, and that caveat matters more here than in our other audits, because three of the five destination-less forms are React components whose entire submission path may live in script. We read attributes; we did not submit a single form, so we cannot tell you where any message actually ends up, and we are not going to guess. We did not measure how any search engine, screen reader or crawler weighs any of this. No traffic, ranking or revenue data was consulted. Every figure on this page comes out of the saved responses.

FAQ

How many forms do the faymas sites have?

13 forms across 35 unique pages on the four domains: 9 on faymas-in.com, 2 on faymas.in, 1 on faymas.net and 1 on faymas.com.in. Twenty-six of the 35 pages contain no form at all.

Do faymas contact forms say where the message goes?

No. All three contact forms that exist — faymas.in/contact, faymas.net/contact and faymas.com.in/contact-us — have no action attribute. faymas-in.com has no contact form at all: its /contact-us/ URL redirects to the homepage.

Why do only some faymas forms have an action attribute?

The 8 that do are all WordPress output on faymas-in.com: four comment forms posting to /wp-comments-post.php and four search blocks sending a GET to /. The five that don't are the two React contact forms, two search boxes and one Kadence form, which instead hides its handler in an input named action.

Are there any dropdown menus on the faymas sites?

Not visibly. Four select elements exist, all on faymas.net, and all four are marked aria-hidden="true" with tabindex="-1" and one-pixel clip styling. The visible pickers are built from buttons — 80 of them expose aria-expanded.

How many buttons do faymas pages carry?

349 across 35 pages, against 45 input fields — 7.8 buttons per input. Only 8 of those buttons sit inside a form. faymas.net averages 13.5 buttons per page, faymas.com.in averages 2.8.