Accessibility Tips for WP Event Manager

Events can be a great way to draw attention to your business or organization and invite user interaction. There are a lot of event plugins to choose from, but which one is best for your users who may have disabilities?

We here at Bet Hannon Business Websites used to be big fans of one of the most popular events plugins for WordPress, but unfortunately, after a recent view overhaul, we needed to make a change due to it no longer passing accessibility success criteria.

Looking at the code, it’s evident accessibility was attempted but the results just didn’t make the grade. So we went in search of a new (and accessible) events plugin for our clients.

After auditing over two dozen of the top events plugins (keeping in mind accessibility, template editability, how easy it would be for clients to manage, and relationships with complex features like custom post types), we found WP Event Manager (also available in the WordPress Plugin repo).

A brief review of WP Event Manager

WP Event Manager (WPEM) doesn’t have as many bells and whistles as you may be used to. Additionally, even some seemingly basic features (such as a grid calendar display) are not included in the base plugin and require the purchase of a WPEM add-on. The dashboard user interface could be made more user-friendly, but the clients we tested it on had no complaints after getting everything figured out.

That being said, this plugin is more accessible than any of the other plugins we audited in our search for a replacement – and seemingly by complete accident! The accessibility was apparently not intentional. However, we’ve been in touch with the developers of the plugin, and they’re interested in potentially adding more accessibility enhancements. We were particularly surprised (and relieved) when we audited the Calendar (grid) view of WPEM (as you may know calendar grids, tend to notoriously be a hot mess when it comes to accessibility in event plugins) and found it to be easily navigable with a keyboard and screen reader.

It does take a bit to get used to, and there’s a bug here and there, but it’s a great alternative if you’re concerned about your site’s accessibility and need to display events.

Making WPEM accessible

While WPEM was THE MOST accessible of the event plugins audited, it still has some things that need to be adjusted before qualifying as fully accessible. And honestly, we probably haven’t found ALL potential issues yet as the plugin is still new to us and we’ve only used a couple of the add-ons. So as we get more experienced with the plugin and have a reason to use the other add-ons, we’ll expand on this list (or subtract from it as the WPEM devs add their own accessibility enhancements).

There are, of course, a ton of different approaches to some of these issues. Another cool thing about WPEM is how well the templates are put together, making them easy to modify.

Keep in mind, these are not instructions on how to use WPEM but tips and recommended adjustments to make it more accessible. Additionally, the information provided is heavier on the code side as there are few ways to implement accessibility enhancements to this plugin without using either CSS or PHP.

The WPEM default color(s)

Unfortunately, the default color for WPEM templates is a sky blue, #00a5fa (used for links, some titles, accents, and buttons) against #ffffff (white). It has a 2.7:1 contrast ratio, which fails for graphic components, normal and large text (basically… everything).

So the first thing you’re going to want to do is swap out those colors. You can do this by overriding the plugin’s styles in CSS with your theme’s colors (while ensuring they meet minimum contrast by using a tool like WebAIM’s Contrast Checker). Obviously, if you’re working with a developer (or are a developer) and plan on styling per your theme anyway, this may not be as big of an issue for you. But, if you’re planning on using the plugin styled as it is, you’ll want to apply the color changes at the very least.

If you’re comfortable working in PHP, you can create a local copy of the single template and strip out the plugin classes that replace the theme’s default classes (for things like links and headings). This is our preference and we use a skeleton template before making custom adjustments per client, which saves time in the long run instead of force overriding colors and fonts each time. Fortunately, WPEM’s documentation on Template Overrides is pretty straightforward.

The WPEM Registeration button

Fortunately, while this is a code-based solution, it’s simply copying and pasting the provided code into your theme’s functions.php file.

Out of the box, WPEM provides “Register for Event” functionality that creates a button on the front end single event display:

This is a collapsed button. While it’s easy to modify in PHP, we are still figuring out the most accessible approach when using this toggle. However, most of our clients don’t incorporate event registration, thus making the button itself irrelevant. Unfortunately, even if you don’t add a registration link to your event, the Register button will still appear.

Now, you could always implement an if !empty PHP statement into the template, but that could be a lot of extra work. Fortunately, WPEM has also supplied support documentation to conditionally show/hide the registration button. Honestly, I wish this was a core feature and hope they add it soon.

We have a modified version of the code provided on their documentation which should be copied/pasted in functions.php:

/* WPEM SHOW/HIDE REGISTRATION BUTTON

/*
* Register meta box(es).
*/
add_action( 'add_meta_boxes', 'wpdocs_register_meta_boxes' );
function wpdocs_register_meta_boxes() {
    add_meta_box( 'registration-button-settings-meta-box', __( 'Registrations button meta box', 'wp-event-manager' ), 'wpdocs_my_display_callback', 'event_listing' ,'side');
}
 
/* Meta box display callback.
@param WP_Post $post Current post object.
*/
function wpdocs_my_display_callback( $post ) {
    // Display code/markup goes here. Don't forget to include nonces!
    $show_regi_btn = get_post_meta($post->ID,'_show_hide_registration_button',true);
    ?>
    <label for="wporg_field">Hide registrations button</label>
    <input type="checkbox" name="show_hide_registration_button" id="show_hide_registration_button" value="1" <?php if(isset($show_regi_btn) && $show_regi_btn == 1) echo 'checked="checked"'; ?> >
    <?php
 
}
 
// Save your meta box content
add_action( 'save_post', 'wpdocs_save_meta_box' );
/* Save meta box content.
@param int $post_id Post ID
*/
function wpdocs_save_meta_box( $post_id ) {
    // Save logic goes here. Don't forget to include nonce checks!
 
    $show_hide_registration_button = isset($_POST['show_hide_registration_button']) ? $_POST['show_hide_registration_button'] : '0';
 
    update_post_meta($post_id,'_show_hide_registration_button', $show_hide_registration_button);
}
 
/**
 * registration_limit_restriction
 * @param $method,$post
 * @return $method
 * @since 3.1.11
 */
function your_child_theme_registration_disable($method,$post){
    $disable_button = get_post_meta($post->ID,'_show_hide_registration_button',true);
    //disable button if settings in event meta box
    if( $disable_button == 1){
         return false;
    }else{
        return $method;
    }
}
add_filter('display_event_registration_method','your_child_theme_registration_disable',90,2);
add_filter('get_event_registration_method','your_child_theme_registration_disable',90,2);

The purpose of this snippet is to add a checkbox to events that says “Show/Hide Registration Button.” When we initially used the snippet provided in the documentation, we thought it wasn’t working because the checkbox in the event information section was checked but the Registration button still appeared on the front end. That is until we noticed the check box in the meta sidebar (under event categories).

After testing it, we realized the one in the editor itself didn’t actually work independently. The edited version of the snippet removes the superfluous checkmark while preserving the working checkbox in the meta sidebar to avoid confusion.

Event listing wrappers and their focusable elements

We feel like the WPEM templates are very attractive out of the box. However, there’s an issue with the way the developers applied interaction styling (aka, hover effect).

Here is an example from one of their demo sites:

Hovering over the events turns the background grey. Unfortunately, the :hover effect isn’t associated with the <a> tag but its parent <div> wrapper which isn’t focusable for keyboard navigation.

Of course, we want a :hover AND :focus effect applied to the link itself (the <a> tag). Whether you’re using the “box” or “list” view included, the wrappers have some padding and styling that need to be removed and reapplied to target the <a> tag to create a visible hover and focus style.

Heading heirarchy

We like the single event template WPEM provides. Unfortunately, they use <h3> headings directly after the <h1> event title:

This one is a pretty easy fix, but it does involve editing the core template file (you could use a jQuery .replaceWith() function, we just prefer fixing the source). If you’ve already created a local theme copy of the template file (discussed in the “The WPEM default color(s)” portion of this article), you just need to copy content-single-event_listing.php (found in the “template” directory of the plugin). Then you can do one of two basic fixes:

Easy heading nesting fix, option one:

On line 66, you should see:

<h3 class="wpem-heading-text"><?php the_title(); ?></h3>

We find this line to be repetitive, as it duplicates the event title (which is generally stated at the top of the page as an <h1> per most theme templates). But changing that h3 to an h2 will fix the heading hierarchy of the single template.

Easy heading nesting fix, option two:

We love using hidden screen reader text. It lets us ensure total clarity and easy navigation, even when we don’t want something visible. And it’s super easy to implement (many themes already have an established class for screen reader text, like sr-only or screen-reader). So decide on your class and add the following to your stylesheet:

.your-class {
	position:absolute !important;
	left:-10000px !important;
	top:auto !important;
	width:1px !important;
	height:1px !important;
	overflow:hidden !important;
}

Note: if your theme already has an existing screen reader text class, you can just use that one and skip creating your own. We’ve found the easiest way to find the class is to inspect the sidebar on the front end of your website and see if there is a hidden <h2> and copying its class.

Any element with this class applied to it will be tucked away and not visible on the website; however, it will remain in proper reading order and allow screen reader users to navigate your website (without negatively impacting your SEO).

Create a new line above line 66 and add:

<h2 class="your-class">Event description</h2>

Next, create a new line below line 400 (opening sidebar wrapper) and add:

<h2 class="your-class">Event details</h2>

This gives both sections (the main body of the event and the details sidebar) an h2 heading, creating proper nesting and better organization.

Conclusion

WP Event Manager isn’t perfect, but it definitely requires a lot less work than other event plugins; most of these changes you only have to do once to create a default custom directory you can use for all of your clients. And, as stated, the issues addressed in this article probably aren’t all of them. But if you’re looking into an accessible event plugin and have the ability to implement the fixes discussed in this article, WPEM could definitely be a great fit for you.

If you use WPEM and have discovered any other accessibility issues in either the core plugin or add-ons, please share them in the comments below!