A good WordCamp talk proposal has a title that says what the session is about, a description of two to four sentences that names the problem, the audience and what people will take home, and a short bio that shows why you can teach it. The WordCamp talk proposal examples below include two real abstracts from my own sessions at WordCamp Canada and WordCamp US, five templates you can adapt for different tracks, and a table of WordCamp talk ideas. Use them as structure, not as text to copy: organizers can tell when an abstract was written for their camp and when it was pasted.
This guide is part of my complete guide to becoming a WordCamp speaker, which explains how calls for speakers work. Here I only deal with the proposal itself.
What goes into a WordCamp talk proposal?
Every camp writes its own form, but most of them ask for the same fields. Prepare these before you open the form, so you are not writing your abstract in a browser tab at midnight before the deadline:
- Title. Short and literal. If someone reads only the title on the schedule, they should know whether the talk is for them.
- Description, also called the abstract. This is what attendees read on the session page. Two to four sentences is usually enough.
- Format. Regular session, lightning talk, workshop or panel, depending on what the camp offers.
- Audience level. Beginner, intermediate or advanced, and sometimes the role: users, developers, designers, business owners.
- Takeaways. Some forms ask for them separately. Write two or three things people will be able to do afterwards.
- Bio. Third person, a few sentences, focused on why you know this topic.
- Past talks. Links to recordings or slides, if you have them. A meetup recording counts.
- Notes for organizers. A private field on some forms. Use it to explain anything the abstract cannot, like a demo that needs a stable connection.
Two real abstracts from my sessions
Both of these are published on the official WordCamp session pages. I am showing them because they are short, and short is usually what works.
The first is from WordCamp Canada 2025, for the session The Ultimate WordPress Performance Stack: Tools, Tactics & Tradeoffs:
Hosting, caching layers, CDN, image and script strategy: the full WordPress performance stack, what to use, what to skip, and what each choice costs you.
One sentence. It lists the scope in concrete nouns, so attendees know exactly which layers the talk covers. Then it makes three promises: what to use, what to skip and what each choice costs. The word “tradeoffs” in the title tells readers the session is about decisions. I wrote more about that session on the WordPress performance stack talk page.
The second is from WordCamp US 2026, for Staying Relevant as a WordPress Developer in 2026:
AI is rapidly changing the WordPress industry, automating repetitive tasks and reshaping what companies expect from developers. This session explores the skills that still create long-term value in 2026: performance, accessibility, communication, business thinking and community contribution.
This one opens with the problem the audience already feels, then names the skills the talk will cover. A developer reading the schedule can decide in five seconds whether it is for them. For WordCamp Canada 2026 I kept the same text and added one closing sentence describing it as a practical, realistic discussion about staying relevant in an AI-driven, globally competitive market. Small edits like that are how you adapt an accepted talk to a new camp.
WordCamp talk proposal examples you can adapt
These are templates I wrote for this guide. They are not sessions anyone gave. Replace the details with your own experience, because the strength of a proposal comes from the specific work behind it.
Performance track, intermediate
Title: Why your WordPress site is fast in Lighthouse and slow for real visitors
Description: Lab tools test one page load on one simulated device. Google’s Core Web Vitals report uses field data from real Chrome users over 28 days. This session shows how to read both, why they disagree, and how to find the template and the metric that real visitors are failing. Attendees leave with a short process for checking their own site in PageSpeed Insights and Search Console.
Why it works: the title states a frustration many site owners have. The description explains the cause in one sentence and ends with a concrete takeaway.
Accessibility track, beginner
Title: Five accessibility fixes you can make in the block editor today
Description: Most accessibility problems on WordPress sites come from content, not code: missing alt text, skipped heading levels, links that say “click here”, low contrast in custom colors. This session walks through each problem in the block editor and shows the fix. No coding needed. Bring a site you manage.
Why it works: the number in the title is honest because the talk covers exactly five fixes. “No coding needed” tells the organizers where to place it in the schedule.
Business track, all levels
Title: Pricing maintenance plans without racing to the bottom
Description: Freelancers and small agencies often price WordPress maintenance against the cheapest offer they can find. This talk is about the other approach: defining what a plan includes, what it excludes and how to explain the difference to clients. Based on the plans I run with my own clients, including the ones that did not work.
Why it works: it has a point of view, and the last sentence promises real experience, including failures. If you use this template, the last sentence must be true for you.
Development track, advanced
Title: Building a custom block with the Interactivity API
Description: Since WordPress 6.5, the Interactivity API gives blocks a standard way to add front-end behavior without shipping a separate framework. This workshop builds one small interactive block from scratch and covers state, actions and server rendering. Attendees should be comfortable with PHP and modern JavaScript.
Why it works: it names the WordPress version, the scope of the build and the prerequisites. Organizers can see that this is a workshop with a clear end point.
Community track, beginner
Title: Your first contribution to WordPress does not have to be code
Description: The WordPress project has teams for documentation, translation, support, training, photos and more. This session explains what each team does, how to find their meetings on make.wordpress.org, and how to pick a first task that fits a few free hours a month.
Why it works: it removes the most common objection, “I am not a developer”, in the title. The description lists real teams and ends with a small, realistic action.
WordCamp talk ideas by track
If you are stuck on the topic, start from your own work and match it to a track. These are starting points, not finished titles.
| Track | Talk ideas |
|---|---|
| Performance | Reading CrUX data for a WordPress site; what page cache, object cache and a CDN each solve; removing plugin CSS and JavaScript from templates that do not use it; image sizes and formats in WordPress |
| Development | Moving a classic theme to blocks; WP-CLI scripts you use every week; testing plugins against new WordPress releases; debugging slow database queries |
| Accessibility | Keyboard navigation checks for a theme; writing alt text that helps; accessible forms in WordPress |
| Business | Writing proposals clients understand; turning one-off projects into recurring work; when to say no to a project |
| Content and SEO | Technical SEO basics a WordPress site owner can check; migrating a site without losing search traffic; structuring a blog by topic |
| Career and community | Moving from freelancer to agency or the reverse; contributing to WordPress; staying relevant as tools change |
My own talks came from the first and last rows. Core Web Vitals in practice and the performance stack talk grew out of the questions about field data and caching that come up in my audits again and again.
Mistakes that sink a proposal
- A clever title with no subject. Puns are fine as long as the subject is also in the title.
- An abstract that describes you instead of the talk. Your credentials go in the bio.
- No audience level. Organizers need it to build a balanced schedule.
- Too much scope. If the description lists more than four or five subtopics, pick one and propose the others separately.
- A product demo. If the talk only works for people who buy your product, it is a sponsor session, not a WordCamp talk.
- Vague promises like “best practices” or “tips and tricks” without saying which ones.
- Copying the same abstract to every camp without reading what each one asks for.
How to rewrite a weak abstract
A weak abstract, written for this example:
In this talk we will explore WordPress performance and share tips and best practices for making your website faster and improving user experience.
It has no audience, no scope and no takeaway. Every performance talk could use it. Rewritten with one problem, one audience and one result:
Many WordPress sites pass Lighthouse but fail Core Web Vitals in Search Console. For site owners and junior developers, this session shows how to find which template and which metric are failing for real visitors, and the three fixes that usually come first.
The fix for a weak abstract is almost always the same: cut the generic words, name the audience, and replace “tips” with the actual thing you will show.
Before you submit, run your proposal and your bio through the WordCamp speaker bio and slides checklist. If you want to see how these abstracts turned into full sessions, my talks page lists every event, with recordings where they exist.