How to ask about pronouns, names and access needs on event forms

You're selling tickets to a conference. A buyer books for their team, enters their own name and pays. A week later, your badge file lists the same person for every ticket. Someone else has shared an access request, but nobody knows who's meant to reply.

These problems start with questions that look reasonable in a form. The trouble comes when the answers are used for something the attendee didn't expect, or never reach the person who can help.

Inclusive event registration forms need a clear purpose for each question. Ask attendees what name they want used, make pronoun sharing optional, explain where those details will appear, and provide a private way to discuss access arrangements. Then test what happens after someone answers. A thoughtful label can't repair a badge printed from the wrong field.

This guide focuses on those decisions for paid events. You'll find wording you can adapt, a worked conference example, and a way to check your setup before tickets go on sale.

Separate the booking name from the name people see

The first thing you want to establish is whose information you're collecting. The buyer placed the order. Each attendee has their own preferences about how they're addressed. One person paying for a group doesn't make them the right person to answer personal questions for everyone.

Keep the buyer's booking details attached to the transaction. Ask each attendee directly for the name they want on their badge, where badges are part of the event. If you don't print badges or publish attendee profiles, you may have no reason to ask for another name at all.

Our event registration form template explains the broader separation between order details and attendee questions. Here, the decision is more specific. Which name will appear in public, and has the person who'll wear it actually supplied it?

Use a label such as "Name to show on your badge" and explain the use beside it. "We'll print this name on your event badge" tells someone more than "Preferred name." The latter leaves them wondering whether you're asking about emails, invoices, tickets or introductions.

Someone may use a different name professionally, socially or in a particular setting. You don't need their reason. You need the name that works for the stated purpose. Don't ask for a previous name or an explanation of the difference as a routine part of registration.

Avoid asking for a "legal name" by habit. If a genuine identity, travel, accreditation or payment requirement applies, establish exactly which record needs it and explain that requirement separately. Don't automatically copy that name into the badge file. Check the relevant event requirements before promising that a display name can replace every other record.

There also needs to be a correction route. People mistype names, change plans and spot a problem only when they see a preview. Tell them how to request a change before printing and what to do after the printing deadline. A replacement badge at the desk should be an ordinary service request.

Let names fit the person

Don't make your form decide that a real name is invalid because it contains an accent, apostrophe, space or unfamiliar script. Test the whole process, including exports and printing. Accepting a name online doesn't help if the badge printer replaces its characters with empty boxes.

W3C's guidance on personal names around the world explains why separate first and last name assumptions can fail. Names differ in structure and order, and some people have one name. Where your process permits it, a single display name field avoids asking attendees to force their name into your team's familiar pattern.

If a supplier requires separate fields, ask how single names and different naming conventions are handled. Test those cases before launch. Don't tell customers to invent a surname or remove part of their name because nobody checked the export.

Test long names on the actual badge layout too. Your form and printer may allow different lengths. Explain any genuine display limit before submission, offer a preview where available, and arrange a sensible correction rather than silently cutting the name in half.

Ask about pronouns as an invitation

Make the pronoun question optional. Someone should be able to leave it blank and complete registration without an explanation. Don't replace a required answer with a compulsory "Prefer not to say" selection if an empty optional field would work.

Pronouns.org's guidance on asking recommends inviting people to share rather than forcing them. It also explains that what someone shares can depend on the setting. Apply that principle to your event. A person may be comfortable telling your support team something they don't want displayed to every attendee.

A straightforward question is "Pronouns you'd like us to use at this event. Optional." If people may be unfamiliar with the term, a short explanation can help. For example, "These are words such as she/her, he/him or they/them that people use when referring to you."

The explanation should help someone answer, rather than turn the form into a lesson. Use wording your audience can understand, and test it with people who weren't involved in drafting it. Don't assume everyone speaks English as their first language or uses the same terms.

A free text field can accommodate answers your dropdown hasn't anticipated. If you use preset choices, allow more than one where appropriate and provide a way to write an answer. Avoid labelling people "Other" when you could say "Use my own words."

Don't infer gender from the answer or add a gender question because you've already asked about pronouns. Those are different questions. If you have a separate, justified reason to collect demographic information, define that purpose and review it separately. A badge preference doesn't answer a sponsor's audience research question.

An empty answer also isn't a problem your door team needs to investigate. Staff can use the attendee's name and speak directly to them. Don't ask publicly why they skipped the question, select pronouns based on appearance, or turn badge collection into an identity check beyond the event's actual admission rules.

Explain display separately from use

Before collecting pronouns, decide where they could appear. A staff note, printed badge, networking directory and livestream introduction involve different audiences. "We'll use this at the event" is too vague if the answer is going into all of them.

One practical approach is an optional pronoun field followed by a separate, unticked badge display choice. The explanation might say, "Our attendee support team can see your answer. Select the choice below if you'd also like it printed on your badge." Use this only when your actual system and staff process support that separation.

If your software automatically prints every supplied answer, don't promise otherwise. Change the setup, use a supported alternative, or explain the real use before asking. A choice that the export ignores is worse than a clear, limited offer.

Treat a public attendee directory separately. Someone agreeing to a badge visible in the room hasn't necessarily agreed to an online profile accessible before or after the event. State the directory's audience and purpose, and review the appropriate permission process before publishing information there.

Where collecting pronouns creates unnecessary complexity, optional blank badge stickers can offer another route. Explain that attendees may use them if they want to. Don't require everyone to select one at the desk, and don't use stickers as an excuse to ignore information you've already agreed to print.

Publish access information before asking for requests

An attendee deciding whether to buy shouldn't have to disclose a personal need just to find out whether the venue has step free entry. Publish the access facts you know, including the route people will actually use, relevant facilities and how to contact the team.

Access is part of the decision to buy. In Loopyah's survey of 500 US event attendees in November 2025, 41% rated accessibility or convenience very important when deciding whether to attend, and another 35% rated it moderately important.

That information should cover the event as you'll run it. A venue might have a lift, but your workshop could be in a space reached through a different entrance. Check the arrangement with the venue and explain any restrictions honestly. Avoid a general "fully accessible" claim that leaves buyers guessing what it includes.

W3C's accessible events checklist recommends asking about accessibility requirements and providing information such as venue accessibility and remote participation arrangements. Use our event accessibility checklist to review the wider event. Your registration question should build on that preparation, rather than make attendees identify every barrier for you.

Describe confirmed arrangements as confirmed. If you're still checking captioning or a quiet space, say that and provide a contact route. Don't list a possibility as a service someone can rely on when buying a ticket.

Put the access information where a buyer can find it before payment. Repeat the link in relevant attendee communications so someone doesn't have to remember where they saw it. Keep the page current when the venue, timetable or arrangements change.

Ask what would help someone take part

An access question should help your team arrange something. "What would help you access and take part in this event?" is more useful than "Do you have a disability?" The first invites a practical conversation. The second collects a broad personal label without explaining what you'll do with it.

You could ask, "Would you like to discuss an access arrangement with our event team? Optional." Offer a private contact route alongside the field. Someone may want to speak to a person before deciding what to put in writing, particularly if they're unsure what's possible.

If you offer a text box, explain that a diagnosis or medical history isn't needed for the initial request. Examples might include discussing seating, communication support or the arrival route. Keep those examples tied to arrangements your team can discuss, without implying that every request is already confirmed.

Avoid an all purpose "Special requirements" field shared with catering, the venue and the badge supplier. People can't tell who'll read it or which requests it covers. Meal choices, allergy information and access arrangements may require different recipients and handling. Explain those uses where you collect them.

Be careful with checkboxes too. A list can help someone recognise an available service, but it can also suggest that selecting it books the service. Distinguish between choosing a confirmed arrangement and asking the team to discuss one. The confirmation message needs to match.

For example, "Request a conversation about seating" shouldn't generate "Your seating is confirmed." Say that the request has been received, identify who will reply and give a realistic response expectation. Then make sure somebody actually owns that reply.

If advance notice helps arrange a service, publish a planning date and explain why. Give late buyers a working contact route. Don't write a blanket refusal into a form because a print deadline or supplier preference is easier to administer than a conversation about the request.

Your obligations depend on the applicable law and circumstances. Get appropriate advice about access duties and any evidence genuinely needed for a particular arrangement. Don't make medical documentation the default requirement for every conversation about participation.

Decide who can see each answer

Before launch, follow an example answer through your systems. Who sees it in the booking account? Who receives the email notification? What appears in a download? Does a supplier get the whole file when they only need the badge names?

It's easy to write "Only our access team will see this" without checking that the order confirmation repeats the response to the buyer. That matters when an employer, friend or colleague bought the ticket. Test the actual messages and permissions before making a privacy promise.

For a badge supplier, the useful information is the approved display name and any explicitly selected display details. For a seating coordinator, it may be a particular arrangement and a way to match it to the right attendee. Neither role automatically needs the original request in full.

Use your existing approved systems for private access work. Restrict access to people who need it, and agree what information any venue or service provider needs to deliver the arrangement. Avoid copying an entire request into a general volunteer chat because the event is getting close.

Some access answers can reveal health information. The ICO's rules on special category data explain that UK GDPR processing needs an Article 6 lawful basis and an Article 9 condition where special category data is involved. An optional text box, by itself, doesn't settle those requirements.

For events subject to those rules, review your collection and handling with the person responsible for privacy. Our event privacy notice guide covers how to explain purposes, recipients and retention. Keep the form's short explanation consistent with the arrangements you've actually approved.

Set a retention decision for these details rather than leaving them in every future guest list. An upcoming event may need a fresh request, and the attendee's circumstances or preferences may have changed. Keep any records required for another justified purpose under the appropriate process, rather than promising immediate deletion of everything.

Give each attendee their own route to answer

Group booking is where otherwise careful forms often become awkward. A company administrator can choose the tickets, but may not know how a colleague wants their name displayed. They shouldn't be pushed to guess pronouns or describe another person's access needs.

Where your booking process supports it, let each attendee supply their own personal preferences after purchase. Explain which details are still needed, how to provide them and when. The buyer can receive order updates without receiving the full content of every attendee's private conversation.

If your system can't separate those communications, recognise that limitation before collecting sensitive answers. Offer a reviewed alternative contact route and explain who receives it. Don't describe an attendee link as private simply because its address looks difficult to guess.

A buyer can pass on the access information page and support contact without asking their colleagues to disclose anything to them. That is often enough to start. Make the route available to everyone so using it doesn't itself require a public announcement.

Consider substitutions too. An attendee's replacement doesn't inherit their pronouns, badge preferences or access request. Confirm which details belong to the ticket and which belong to the person. Remove or stop using the previous attendee's personal preparation details as your reviewed process requires.

Our conference group registration guide covers the booking and substitution decisions in more depth. For personal information, the practical rule is to seek the new attendee's answers rather than copy the old record into a new badge.

Work through a conference booking before launch

Imagine you're organising a paid professional conference with printed badges, a networking directory and several presentation rooms. A company buys passes for colleagues. Your team wants useful introductions and enough time to arrange access support. This is an illustrative workflow, not a description of a particular ticketing product.

At checkout, the administrator supplies the information needed for the order. The confirmation explains how attendees can provide their badge details. It also links to the event's published access information and tells them how to contact the support team directly.

An attendee called Alex receives the relevant instructions. Alex enters the name to print, leaves the optional company line blank and provides pronouns for staff use. Alex doesn't select badge display. Those choices should produce a badge with the chosen name and no pronouns or company line.

Alex also requests a conversation about an arrival arrangement. The support team receives that request through its approved private route. The company administrator's receipt shouldn't reproduce the conversation. Before you tell buyers that's how it works, test both the administrator's messages and the attendee's messages.

The access lead replies, checks the route with the venue and confirms the agreed arrangement directly with Alex. The colleague handling arrival receives the practical instruction they need. They don't need Alex's original account of why the arrangement matters.

Meanwhile, the networking directory has its own explanation and reviewed choices. Alex hasn't agreed to a public profile simply by providing a badge name. The person preparing the directory checks its approved inclusion rules instead of importing the entire badge file.

Then Alex corrects a spelling error. Your team updates the relevant display record and checks whether a badge file has already been exported. A corrected form answer won't recall an attachment already sent to the printer. Someone needs to withdraw the superseded file and verify the replacement.

Finally, another colleague takes a different attendee's place. The new attendee provides their own display details and can contact support. The team doesn't carry over a request attached to the previous person. Walk through that substitution during testing, because last minute changes are when staff tend to copy whatever is already available.

The useful part of this example is the connection between a question and its consequence. Each answer has a defined use, each public display has an explanation, and each request reaches somebody who can act. You can simplify the workflow for a smaller event while keeping those connections clear.

Use wording your team can carry out

Here's a short set of example fields for an event with printed badges and a separate access team. These are editorial examples. Adapt them to your actual event, available software and reviewed privacy arrangements before using them.

Badge name

"Name to show on your event badge. We'll print this exactly as provided, subject to the badge preview and any explained layout limits. To correct it after submission, contact our attendee support team using the details in your confirmation."

Add the actual contact details and correction process when you implement this wording. If you can't preserve the submitted name in print, fix that limitation or explain it accurately. Don't promise exact printing while allowing a supplier to shorten names without checking.

Pronouns and badge display

"Pronouns you'd like our attendee support team to use at this event. Optional. You can leave this blank."

"Print these pronouns on my event badge. Optional. Leave this unselected if you don't want them displayed."

Keep the display choice unticked. Confirm that the badge export checks the choice as well as the pronoun answer. If your team can't separate staff use and display, replace these examples with an accurate explanation of the simpler choice you can provide.

Access conversation

"Would you like to discuss an access arrangement? Optional. Tell our access team what would help you take part, or contact us privately using the access contact on this page. You don't need to provide a diagnosis in this initial request."

Follow that with the real recipients, a relevant privacy explanation and an honest response expectation. Publish the planning date where needed, explain its purpose and provide the late request route. Don't leave the attendee wondering whether submitting the form has confirmed an arrangement.

Handle changes without making people start again

Someone may want to update their display details after registration. They shouldn't have to cancel a paid ticket, book again or explain a private reason to get a different badge. Establish a supported correction route that preserves the valid booking while changing the information used for the relevant purpose.

Keep your verification proportionate to the change. A badge spelling correction and a transfer of a valuable ticket can have different consequences. Follow your approved booking security process, and avoid asking for extra identity documents simply because the requested display name differs from the buyer's name. Give support staff a clear escalation route when they genuinely cannot verify an instruction safely themselves.

Check the timing of each output. The badge printer might receive a file before the directory is prepared, while the door team downloads its list later. Record which version each recipient should use and who can replace it. Otherwise a corrected answer can still appear incorrectly in a file somebody downloaded yesterday.

If an attendee removes a pronoun answer or withdraws a badge display choice, check any pending print job and directory use. Explain what you can still change and what has already happened. Don't promise to retrieve every printed copy if badges have already been handed out, but do stop further use where your approved process requires it.

An access arrangement may change too. A new venue entrance, revised programme or unavailable service can affect someone who booked on the basis of the earlier information. Contact the affected attendee privately, explain the change and discuss the available options. Updating a general webpage doesn't complete that conversation.

Decide who has authority to resolve an issue at the event. The desk volunteer may be able to replace a badge immediately but need the access lead for a seating change. Clear responsibility saves the attendee repeating their request to several people while everyone looks for permission.

Keep translated questions equally clear

If you sell tickets in more than one language, review the form's explanations as well as its labels. A translated word for "name" doesn't tell someone whether you're requesting the billing name or the badge name. Keep the purpose visible in every language you offer.

Pronoun conventions also depend on the language and setting. Don't assume the English examples explain every language your audience uses. Ask a competent reviewer familiar with the intended audience to check whether the question makes sense and how staff should use the answer. Keep the invitation optional rather than making unfamiliar terminology another booking requirement.

The same care applies to access contact instructions. If your page offers information in a language your support team doesn't speak, explain what support is available and how requests will be handled. Don't invite a private conversation through a route nobody on the team can understand or monitor.

Review automated messages after translation. They should preserve the distinction between receiving a request and confirming an arrangement. A reassuring sentence can accidentally become a promise when the translation loses that difference. Ask the reviewer to explain what an attendee would reasonably expect after reading it.

For any version, ask someone outside your team to describe what will happen to their answers. Can they tell what appears on the badge, whether pronouns are optional and who handles an access request? Their explanation will reveal ambiguity faster than another internal discussion about whether the wording sounds inclusive.

Make the form usable before adding more questions

Inclusive wording won't help somebody who can't reach the submit button. W3C's accessible forms tutorial covers labels, grouping, instructions and feedback. Ask your supplier or web team to review the implementation as well as the copy. Friendly text doesn't establish that the form works with assistive technology.

As an organizer, you can still catch obvious problems. Move through the form using a keyboard. Check whether labels stay visible after you type. Submit it with optional fields empty, make an error deliberately, and see whether the message explains what needs fixing without clearing completed answers.

Try the form on a phone and with enlarged text. Long names, field explanations and error messages should remain readable. Check the confirmation step too. A form that accepts an access request but hides the response instructions creates another support problem.

Involve people with relevant access experience in testing where possible, and allow time to act on what they find. Don't ask one person to certify that the event works for everyone. Different people use different tools and encounter different barriers.

Brief the people handing over the badges

Your desk team needs to know which name to use and how to fix a mistake quietly. Keep the correction process simple enough to follow during a busy arrival period. Provide a way to reprint or replace a badge without asking the attendee to explain personal history to a queue.

Tell staff where access questions go when the usual lead is occupied. The general door list should support admission, while the approved access process provides the additional instructions relevant staff need. Don't make every volunteer read every private request just in case someone asks a question.

If somebody corrects a name or pronoun, acknowledge the correction, use it and continue helping them. Avoid turning the moment into a public discussion. Staff should also know how to report a wrong badge or inappropriate disclosure so the team can correct the record and address the cause.

Use your event communication plan to assign the messages, contacts and final briefings. Include who covers the support inbox when the main contact is at the venue. A printed contact name is only useful if somebody answers.

Before opening sales, complete a test booking as the buyer, then review it as the attendee, badge supplier and arrival team. Check what each person can see, what they can change and where a request goes. Launch when those results match the explanations beside your questions.