Website accessibility review
Eventbrite: event links that announce placeholder text instead of real titles.
The Eventbrite homepage looks fine. The event titles are right there on screen. But when a screen reader user navigates by links, every event card announces the same meaningless placeholder string instead of the actual event name. I verified the problem in the live DOM to make sure it was not a one-off glitch, because this kind of problem can feel strangely invisible if you are not the one running into it.
What this case study shows
This sample is about accessible names, browsing patterns, and verifying the bug in code.
The page is not broadly unusable, which is exactly why the issue matters. It shows whether I can separate a focused but meaningful barrier from a total failure, explain how it affects real browsing behavior, and confirm the problem at the markup level.
What to notice
- Severity stays grounded even when the page still partly works
- User impact is tied to link-list navigation, not just sequential reading
- DOM verification backs up the screen reader finding
- The suggested fix is narrow, practical, and implementation-ready
What worked
The page is not entirely broken. That makes the specific failures more notable.
Browse reading
Reading through the page sequentially, event titles came through fine. The problem only shows up when navigating by links, which is how most screen reader users actually browse.
Page structure
Headings and landmarks were reasonable. A screen reader user could tell where they were on the page without much trouble.
Event detail pages
Individual event pages were more accessible than the homepage. The issue is specific to how the homepage card links are built.
Findings
Where the experience breaks down.
Event links announce placeholder text instead of event titles
Primary barrier- Issue
- Every event card link on the homepage announces an unresolved template string instead of the event title. The visible text says "Jazz in the Park" but VoiceOver reads something generic and meaningless.
- Steps
- Open the homepage. Use VoiceOver link navigation or the rotor to move through event card links. Compare what VoiceOver says with what is visible on screen.
- Observed
- Every event link reads the same placeholder string. This is not a one-off. It happens on every card across the page.
- Impact
- A screen reader user cannot tell events apart by navigating links. Browsing events becomes guesswork instead of a list you can scan.
- Suggested fix
- Either populate the
aria-labeltemplate with the actual event title, or remove thearia-labelentirely and let the visible text do the job.
Location field has a generic label
Secondary barrier- Issue
- The location search field announces a vague widget label instead of something that tells you what it does. A screen reader user has to guess that this is where you type a city or zip code.
- Suggested fix
- Give the field a label like "Search by city, state, or zip code" so the purpose is clear without needing to see the page visually.
Testing note
I did not stop at what VoiceOver said. I opened the DOM, checked the computed accessible name on the event links, and confirmed the placeholder string was baked into the markup. This is a code problem, not a rendering glitch, and it affects every event card on the page.
Why this matters
The homepage still looks polished, but the scan pattern screen reader users rely on breaks down.
Discovery gets slower
When every event link announces the same meaningless name, users lose the ability to compare and skim choices efficiently.
The defect is easy to miss visually
Sighted QA may never notice it because the visible titles look correct. That makes this a good example of manual accessibility testing adding value.
The fix should stay scoped
This does not call for a large rewrite. It calls for correcting the accessible naming logic and proving the output matches the visible UI.
Verification criteria
What a fix needs to prove.
Fixing it visually is not enough. The accessible names in the code need to match what sighted users see on screen.
Passing criteria
- Each event link announces the actual event title
- The location field has a clear, descriptive label
- A screen reader user can browse events and form controls without guessing
Need this kind of review?
I test websites, apps, and digital products with VoiceOver and keyboard navigation, then write findings your team can act on.