With the successful release of 4.2, you’ll find the first of many changes designed to increase the usability of our plugins for all users. While these changes aren’t dramatic, they’re an exciting introduction to the role of accessibility in our long-term development roadmap.
Focus Styles on Calendar Search Fields
The first adjustment is the addition of a focus style to the calendar search fields. Previously there was no indication when these fields had keyboard focus — the addition of focus styles makes the interactivity of the form field much clearer.
Why is this Important?
According to WebAIM, keyboard accessibility is one of the most important (and easiest) ways to make a website more accessible; it’s also part of the WCAG 2.0 guidelines. The addition of focus styles to search fields adds a visual cue that removes ambiguity and allows the user to follow along with the keyboard focus.
We’ve employed the use of tabindex and ARIA labels to make the calendar navigation more clear for screen reader users.
Bringing Focus to the Calendar Month Navigation Heading
There has always been a heading at the beginning of the calendar pagination, in both the header and footer of the calendar. We had been using a bit of CSS to hide it from view while (presumably) still making it available to screen readers. Unfortunately, this was not the case, and screen readers were not picking up the header text. To fix this, I added tabindex=0 to the heading tag. This value placed the heading within the logical navigation flow, so it can now be read by screen readers.
Since The Events Calendar has a rather large codebase with a fair amount of legacy code, alternate approaches such as changing the structure of the HTML will require a full audit to ensure we don’t cause problems elsewhere. This audit is part of the long-term roadmap mentioned above, so don’t be surprised to see more on this topic from us in the future.
Screen Reader Enhancements for Previous/Next Month Links
Screen readers already did a pretty good job of announcing the previous and next month links, but we wanted to add more context. After doing quite a bit of research, I decided to use aria-label to help define the links as part of the calendar pagination. According to the W3C:
In some contexts, elements can be given the attribute aria-label to provide an accessible name for situations when there is no visible label due to a chosen design approach or layout but the context and visual appearance of the control make its purpose clear.
The criteria for our situation makes me confident that aria-label is a good choice for several reasons:
- No visible <label> because we’re not working with a form field
- The heading that describes the navigation for screen readers is now part of the logical navigation flow, providing more context for the links to screen readers
- The visual appearance makes it clear that the links are part of the calendar month navigation
Screen Readers in Action
Since I’m a Mac user, I did screen reader testing during development in Safari using VoiceOver. I also tested with NVDA on Windows 10 using the Edge browser. Both of these screen readers are free and readily available on their respective platforms. You can see the final results below. The changes mentioned in this post are at the 35s mark.
Shorter clips of before and after for both platforms are on my YouTube Channel. Note that in the NVDA/after video, NVDA did not read our aria-label. This is a known issue and a good example of why testing is so important.
We hope you’re as excited as we are about the enhancements we’ve made so far. Our goal is to continually improve the accessibility of all of our plugins so that they are easier to use for everyone. We’re excited for what the future holds!