Over the years, I’ve always striven to make My Calendar and My Tickets as accessible as I could, according to the standards of the time. The standards for what is considered accessible have changed considerably since I built this plugin in 2009, and I’ve always aimed to improve the plugin to meet those standards.

However, I did make a strategic plugin design error in the early 2010s which shackled my choices for many years. Specifically, I set up a system where people could customize the physical CSS files within the plugin which were maintained through plugin updates, and I provided the ability to customize scripting within the back-end.

This may sound insignificant, but it had long reaching consequences that took years to unravel.

The problems caused by that decision were simple: I no longer had any way of updating the core My Calendar stylesheets, no way of knowing what styles people were using, and could not change the output HTML without breaking thousands of website.

Not being able to change HTML is a major barrier to keeping up with accessibility, to put it mildly.

I began the process of compensating for this issue in version 2.3.0, with the addition of a core-managed calendar reset stylesheet, which provided a base level of styles, and finished it in 3.5.0, with the removal of core CSS editing. It’s still possible to use a fully custom stylesheet, but I no longer provide any official support for those styles.

Still broke some sites, but that was a compromise I was prepared for.

Accessibility in My Calendar 3.5.0 and beyond

Since version 3.5, the accessibility of My Calendar is in a much better place.

  • With the older stylesheets, there will be broken design characteristics. This can be resolved by disabling your custom stylesheets or by updating them, if you have the knowledge for that.
  • The default scripting has been switched from the weird fusion disclosure widget/modal to a proper modal with all of the expected behaviors for an accessible modal.
  • The navigation now has considerably improved structure and behavior.

But, most importantly, I’m far more able to freely make changes to the output and fix issues as I become aware of them.

The older scripting still exists, and will continue to exist for sometime. However, it is no longer the default, and I will be gradually pushing users to switch over time. If you are using the scripting option labeled ‘Disclosure Widget’ in the admin, I recommend you change that.

My Calendar & WCAG Compliance

I’m a firm believer that it is irresponsible to claim any kind of accessibility compliance in a plugin. I could possibly achieve that, but not while also allowing the calendar to be themed or integrated with your website in any way. But the main thing I simply can’t guarantee is color contrast: it’s largely out of my hands, although there are some tools in place in the My Calendar design settings to prevent problems.

I can affirm that, to the best of my knowledge, My Calendar has:

  • Accessibly-named controls
  • Support for alternative text for icons and images
  • Keyboard support for all behaviors, front-end and back-end
  • Appropriate screen-reader announcements where needed
  • Reasonable and logical structural semantics for events, forms, and content.

If you identify an accessibility issue in My Calendar, please don’t hesitate to raise it.

Raise a My Calendar Issue on Github