Accessible Events Calendars: A WCAG Checklist for Event Listings

Calendars are one of the hardest things on a website to make accessible: grids, pop-ups, colour-coding and small text all get in the way. But an accessible events calendar is mostly about a few habits — in how the calendar is built, and in how each event is written. This checklist follows WCAG 2.1 level AA, the standard most organisations aim for.

Part 1: The calendar itself

Keyboard

• Can you reach every control — previous/next month, view buttons, search, each event — with Tab, and activate it with Enter or Space?
• Is there always a visible focus outline, so keyboard users can see where they are (WCAG 2.4.7)?
• Can pop-ups and preview cards be reached and closed with the keyboard (WCAG 2.1.1, 2.1.2)?

Screen readers

• Do buttons have meaningful names (“Next month”, not just an arrow)?
• When the month changes, is the new month announced or at least reachable?
• Is there an alternative to the grid — a list view — that’s easier to read in order? Many people, not just screen-reader users, find lists easier than grids.

Zoom and small screens

• At 200 % zoom, does the calendar still work without text overlapping (WCAG 1.4.4)?
• At a width of 320 pixels — a small phone — does it fit without scrolling sideways (WCAG 1.4.10)?

Colour

• Is colour the only way to tell event types apart? Colour-coding is helpful, but categories should also appear in words — on the event page, in the title, or in a key (WCAG 1.4.1).
• Do text and backgrounds have enough contrast — at least 4.5:1 for normal text (WCAG 1.4.3)? Light pastel event labels are a common failure.

Part 2: Every event you publish

Titles and descriptions

• Descriptive titles: “Beginners’ Watercolour Workshop” rather than “Workshop”.
• Plain language: short sentences, the key facts first.
• Times in words where it matters: “7:00 pm to 9:00 pm, London time”.

Images

• Alt text for every featured image that carries meaning — “Children painting at long tables in the library” — or empty alt text if it’s purely decorative.
• No important information only in an image. A poster with the date in it needs the date in the text too.

Access information

Tell people what to expect, so they don’t have to ask:

• step-free access, lifts, accessible toilets and parking;
• seating, quiet spaces and how long people will be standing;
• hearing loops, captions, BSL or sign interpretation;
• who to contact with access questions.

Links

• Link text that makes sense on its own: “Book a place for the watercolour workshop”, not “click here”.
• Say when a link opens a PDF or another site.

Part 3: Test it

A 15-minute test catches most problems:

1. Keyboard only: unplug the mouse and try to find an event, open it and save it.
2. Zoom to 200 % and repeat.
3. Screen reader: NVDA (Windows, free) or VoiceOver (Mac and iPhone, built in). Listen to an event page from the top.
4. Automated check: WAVE or axe in your browser to catch contrast and missing alt text.

Where Monthly Events Calendar stands

We’d rather be specific than claim “fully accessible”. In Monthly Events Calendar:

• the list view gives a linear alternative to the month grid;
• event pages are ordinary WordPress pages with real headings and text, which work well with screen readers;
• each event’s details and Add to Calendar button are part of the page, not an image.

We’re working through the calendar views against this checklist. If you find something that doesn’t work for you, please tell us in the support forum — accessibility reports get priority.

Writing great event pages generally? See the event page checklist.

Keep reading

• How to Show Online Event Times in Every Time Zone
• How an Add to Google Calendar Link Works (and How to Make One)
• How to Choose a WordPress Events Calendar Plugin: 10 Questions to Ask