This episode is a recording of a December 2023 WordPress Accessibility Meetup where Alex Stine, Engineer & Accessibility Consultant, and Amber Hinds, CEO of Equalize Digital, performed a live accessibility audit of the Pie Calendar WordPress Plugin and provided real-time feedback. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: Pie Calendar Plugin Accessibility Audit: Alex Stine and Amber Hinds.
WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. Learn more about WordPress Accessibility Meetup and see upcoming events.
Listen
Mentioned in This Episode
- Pie Calendar Website
- Pie Calendar WordPress Plugin
- ARIA: dialog role
- <fieldset>: The Field Set element
- NVDA 2023.3 User Guide
- Polypane
- Screen Reader Ropes Course
- NVDA Support
- Alex Stine on LinkedIn
Summarized Session Information
The session provided a comprehensive look into the accessibility and functionality of Pie Calendar, a user-friendly WordPress plugin developed by Jonathan and Elijah. Key features include adaptability to users’ operating system and color mode preferences, with an upcoming version enhancing screen reader compatibility for event dates. The plugin’s integration with the Gutenberg editor ensures that accessibility standards are met, particularly in components like checkboxes.
The session also highlighted several recommendations for improving Pie Calendar’s accessibility. Key among these is the adoption of an unordered list for the list view layout, enhancing screen reader interpretation, and ensuring navigational consistency by adding URL parameters for each view change. The audit suggested modifications in event representation, modal implementation, default view settings, and the proper use of HTML and ARIA attributes to enhance accessibility. Specific issues such as keyboard traps in time selection, the need for clear field sets and legends, and the avoidance of potentially confusing ARIA attributes like ‘aria-pressed’ were discussed.
Session Outline
- What is Pie Calendar?
- Accessibility Wins
- Recommendations for Improvement
Part 1: What is Pie Calendar?
Pie Calendar is this cool WordPress plugin that Jonathan and Elijah created. It started because Jonathan needed something special for a client and couldn’t find the right fit with existing plugins. They got creative, roped in ChatGPT for help, and ended up making this basic version that turned out pretty great.
Fast forward to early 2023, and Pie Calendar was born. It’s all about being super easy to use and sticking to what’s essential—managing events and calendars without any fuss. Jonathan and Elijah were all about keeping it simple and user-friendly. They even joke about having a ‘simplicity gun’ to keep things straight to the point. The plugin is all about doing its job well, staying out of your way, and just being elegantly simple.
Part 2: Accessibility Wins
Pie Calendar is being actively updated to provide an elegant calendar with a simple user-friendly interface.
OS and Color Mode Preferences Adaptability
Pie Calendar boasts a unique feature that enables it to adapt to a user’s operating system and color mode preferences, and can be activated through shortcode.
While Pie Calendar defaults to a light mode, which is compatible with most websites, it also offers the capability to switch between light and dark modes automatically, depending on the user’s theme or website settings.
During the audit, Amber recommended to note in their documentation the caveat that if your theme does not have dark mode styles, not to disable this feature.
Event Representation in Different Views
Currently, events in the calendar are not read as links by the screen reader, despite being styled like links due to their HTML <a> tag. However, the upcoming version of Pie Calendar will correct this by enabling clickable dates leading to a single-day view.
Future updates will make these date links functional, allowing users to click on a date to switch to a day view. This improvement aims to enhance the user experience by providing more intuitive navigation and ensuring better compatibility with screen readers.
Accessibility and Functionality of ‘Add to Calendar’ Links
The ‘Add to Calendar’ links are clearly labeled with the event’s name. This labeling is especially beneficial for users who might be dealing with multiple events, as it allows them to easily distinguish between different ‘add-to-calendar’ options.
When these links are used, the focus is appropriately returned to the correct place, enhancing the user experience for those relying on screen readers and other assistive technologies.
Gutenberg Integration
Some components, like checkboxes, are following accessibility standards, unlike custom implementations usually seen elsewhere. Pie Calendar utilizes Gutenberg components effectively for accessibility compliance.
Part 3: Accessibility Recommendations
Alex Stine and Amber Hinds provided live feedback to the WordPress plugin developers. Our goal is to offer useful feedback to developers so they can improve the accessibility of their products and, in turn, all of the websites that use them.
List View Layout and Screen Reader Interpretation
While the list view structurally resembles a table, it doesn’t function as one, making it confusing for screen reader users. It would be best to use an unordered list for better functionality and accessibility.
Managing Focus and Context in User Interface
Managing user focus is important, especially when changing contexts within Pie Calendar. If users navigate away from a specific date, like January 14th, they should return to the same spot instead of being reset to the start of the month, like January 1st, to avoid confusion and frustration.
Navigational Consistency and User Experience
There’s an opportunity to enhance user experience by adding parameters to the URL for each view change, allowing users to backtrack using the browser’s “back” button. There should be a clear way to return to previous views, especially when focusing on specific days.
Event Representation and Accessibility Concerns
The calendar does not communicate the start and end of events clearly, especially for events spanning multiple days. This could lead to confusion, and it’s suggested to list events for each day in such scenarios. The discussion also touches upon the usage of ARIA labels and the importance of clear event representation for accessibility.
Modal Implementation and Focus Constraint
The current implementation of modals does not constrain focus, making it more of an overlay than a true modal.
The team also discusses the difference between navigating with arrow keys and tab, learning that trapping focus for tab navigation doesn’t necessarily address screen reader concerns. This issue can be addressed with an ARIA: dialog role.
Accessibility Recommendations for Default Views
Based on past accessibility testing and user preferences, a list view should be the default instead of a grid view, considering it to be more user-friendly and accessible.
Screen Reader Compatibility and HTML Attribute Usage
There’s an issue regarding the use of the title attribute, which is known to cause inconsistencies in how screen readers interpret and announce information because screen readers behave differently when encountering the title attribute; for instance, NVDA might not read it when using arrow keys, but it might announce it with specific navigation commands like tab or shift-tab. T
This unpredictability is why using the title attribute for accessibility is generally discouraged. It is suggested to replace the title attribute with an aria-label for a more consistent and accessible experience.
ARIA Attributes and Screen Reader Feedback for Calendar Navigation
The calendar uses ARIA attributes, specifically aria-pressed, on certain buttons in Pie Calendar, which makes them read as toggle buttons. They should not be classified as toggle buttons and it’s suggested removing the aria-pressed attribute for clarity.
Navigating forward a month does not change the state of these buttons or prompt an announcement from the screen reader. It’s recommended a clear message like “Now displaying January of 2024,” which could be implemented using an ARIA Live Region.
Enhancing Accessibility for Event Presentation in Different Views
There’s an issue in Pie Calendar related to how events are presented in different views. With a tab index of zero, block-level elements in the calendar, like events, don’t allow the entire table to be read at once by a screen reader, leading to a suboptimal user experience.
It’s suggested that the list view should always be the default option in Pie Calendar. While users could have the option to switch to other views, such as grid view, the list view should never be disabled, as it is the most accessible.
Navigating Time Selection
While examining the time selection feature, it was noted that the screen reader does not appropriately announce the AM/PM selection, creating confusion. And there’s also a keyboard trap, where users can’t easily navigate out of the time selection popup.
It’s suggested the addition of a clear close button in the popup. Ideally, there should be a confirmation action, like a save button, to reassure users that their selections won’t be lost upon closing the popup.
Field Set and Legend Use for Clarity
There’s a lack of field sets or legends associated with checkboxes. Without these, users encountering the checkboxes, especially those using screen readers, would not receive contextual information about what the checkboxes represent or control.
Wrapping it all up
Pie Calendar is designed to simplify event and calendar management. Its development underscores a commitment to functionality and ease of use, with features like adaptability to operating system and color mode preferences. This accessibility audit has highlighted Pie Calendar’s strides in making digital spaces more inclusive, particularly with its upcoming updates enhancing screen reader compatibility and effective integration with the Gutenberg editor.
The audit also brought to light several areas for improvement in accessibility. The dedicated team behind Pie Calendar is eager to address these, demonstrating a proactive stance toward creating a universally accessible tool. Recommendations include refining the user interface for better screen reader interpretation, ensuring navigational consistency, and avoiding common pitfalls in using HTML and ARIA attributes.
By prioritizing these enhancements, Pie Calendar is setting a high standard for plugin development and paving the way for a more inclusive and accessible digital environment. Their readiness to embrace and implement these changes reflects a deep understanding of the importance of accessibility in today’s digital landscape.
Transcript
>> CHRIS HINDS: Welcome to episode 051 of the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.
This episode is a recording of a December 2023 WordPress Accessibility Meetup where Alex Stine, Engineer & Accessibility Consultant, and Amber Hinds, CEO of Equalize Digital, performed a live accessibility audit of the Pie Calendar WordPress Plugin and provided real-time feedback. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. For show notes, a full transcript, and additional information about meetups, go to AccessibilityCraft.com/051.
And now, on to the show.
>> AMBER HINDS: Today’s plugin I am very excited to announce. Let me pop them up here so everyone can see Jonathan and Elijah, the makers of Pie Calendar. Pie Calendar lets you effortlessly turn any post in your WordPress website into a calendar event.
Jonathan, Elijah, do you want to tell us a little bit about the plugin just so everyone who’s watching has some background on what it is, and how you made it?
>> JONATHAN JERNIGAN: Sure. My name is Jonathan. I’m the co-founder along with Elijah here. And this plugin came about because, of course, like most good plugins, I needed it on a client project. And we had a very specific way that it needed to be built, and all of the existing calendar plugins just simply wouldn’t work. So, of course, I had to turn to my lovely assistant ChatGPT to help me build a rudimentary version of what eventually would become Pie Calendar. And the result after spending a good amount of time on that was good enough that I thought, “This might have some legs to be a real plugin.”
So I went to Elijah in the very, very beginning of 2023, I think it might have been January 1st of 2023, and said I have this idea. And we started architecting a calendar plugin that was just super flexible. We wanted it to work in the confines of the existing WordPress features and kind of functionality that already exists, and what we came up with was Pie Calendar.
So the idea is that it just does events and a calendar really well, and not a whole lot else. We joke that we have an internal simplicity gun, and we like to shoot that simplicity gun at stuff all the time. And we’re really proud of what we’ve come up with. I think there’s already some love.
Thank you, Karen in the chat, for the heart. We appreciate it.
Elijah, if you have anything else you wanted to toss in the ring too?
ELIJAH MILLS: Yes. I think that with Pie Calendar, our goal really was just elegance, simplicity, stay out of the way, don’t be noisy, do what it needs to do, and that’s about it. And hopefully, we’ve accomplished that goal. And I appreciate Jonathan bringing me onto the project early on, and I’m happy with what we’ve achieved so far.
>> AMBER: Awesome. Well, we really appreciate that you came today to let us audit it, and that you’re open to feedback.
Alex, I know your camera’s not working, but weirdly, I need you to turn it on in order for me to get you up on screen, if you don’t mind.
OK, there we go. So everyone, Alex’s camera isn’t working today. We couldn’t figure it out, but he is here.
Hi, Alex.
>> ALEX STINE: Hello.
>> AMBER: So just a few guidelines before I hand it over to Alex. The big thing I like to emphasize is the point of this meetup is to give the taster, in this case, Alex, the room to speak and share their experiences. We’ll pause and give everybody time to ask questions. So if you can put them in the Q&A, that’s a little bit easier for me to track rather than the chat. But we want to try not to be super argumentative or whatever because it ultimately comes down to how it sounds on the screen reader and how usable it is.
Of course, number two is, for everyone who’s watching, this is not about bashing the plugins. It takes a lot of bravery to be willing to come up here and let people test your thing in public and give you public feedback. So our goal is always to make this as positive as possible, and we want everyone to applaud Jonathan and Elijah and Pie Calendar for wanting to make a more accessible product, because we think that’s awesome.
So let me stop sharing, and I will let you take over sharing, Alex.
[screen reader voice]
All right. And Alex is using NVDA screen reader, right?
>> ALEX: Yes. And this is the speed at which I mainly listen out, but I’ll be nice to everyone and slow it down.
[screen reader voice]
What did we decide on these? 40?
>> AMBER: Forty-five, I think. Maybe 40.
[screen reader voice]
>> ALEX: We’ll try 45.
[screen reader voice]
>> AMBER: Actually, let’s go 40 so that we can maybe get it on the recording actually captioned.
[screen reader voice]
>> ALEX: Forty.
>> AMBER: Do you want to try turning on the speech viewer also?
[screen reader voice]
>> ALEX: This never works out, but maybe today.
>> AMBER: Well, we’ll see. It depends on where it shows up on your screen. Sometimes it blocks too much. I think in this instance, it’s going to be OK.
>> ALEX: Miracle. OK.
>> AMBER: So I’m actually seeing something that I think we chatted about a little bit in our pre-show. And I’m probably going to edit it and have you refresh the page, but I wanted to point it out anyway.
So Pie Calendar has this really awesome feature, which I turned on on the short code, which is that it can adapt to your operating system and color mode preference. And I don’t know if you want to explain that a little bit, Jonathan or Elijah, what you’re doing. But we noticed that there’s bug with this specific theme, which is 2024, where it caused an issue, because I turned that setting on.
>> JONATHAN: Yes. So on the screen, it looks like there’s a bunch of days listed with little black dots, and there’s just a white little rectangle. But like you were saying, Amber, it’s because there’s a short code parameter for dark mode. And by default, of course, Pie Calendar is in light mode, which will work with the vast majority of websites. But if your theme or if the website you’ve built allows automatic switching between light and dark mode, Pie Calendar can do that. And so that’s what Alex’s screen here is showing. His system appears to be in dark mode, but this blank 2024 theme doesn’t have an automatic dark mode function, so it looks a little wonky at the moment.
>> AMBER: Yes. I just updated that and removed that setting from the short code. I don’t know if you want to refresh your page, Alex, and then we can see what it looks like in normal.
Now we can read text.
>> ALEX: Very interesting because I don’t go out of my way for dark mode. Everything is dark.
[laughter]
[crosstalk ]
>> AMBER: Yes. You didn’t realize that your system was in dark mode? [chuckles]
>> ALEX: I really had no idea.
>> AMBER: [chuckles] Well, for anyone who hasn’t gotten to hang out with Alex in person, generally, his monitor is turned off. [chuckles]
>> ALEX: Yes.
>> AMBER: Yes. I bet your battery lasts way longer than everyone else’s.
>> ALEX: Oh, it does, yes.
>> AMBER: So we can see it now. But I thought it was interesting. I love that you guys included that, but I do think it might be worth noting in your documentation that if your theme does not have dark mode styles, not to disable this. And I think this is a really good accessibility feature, but if a user turns it on and they don’t understand and they don’t check… I have my system in light mode, and I did not go check, so I didn’t see that problem. So it’s kind of interesting.
All right, you want to go ahead and explore the page, Alex, and let us know what you find?
[screen reader voice]
>> ALEX: So we have a “choose view” here. We’ll just explore what it comes selected with.
[screen reader voice]
Those are two unlabeled buttons.
[screen reader voice]
>> AMBER: Those buttons, I think, would change the month that you’re seeing.
[screen reader voice]
What do you think you’re hearing there, Alex?
>> ALEX: A very, very weirdly formatted table.
>> AMBER: So this list view, I gave it two days. It has our event that we’re at right now, which is a one-time event with a start and a stop time. And then it has an all-day event that spans from December 25th to December 30th. And in this particular view, it’s repeating, like, on each day. And then you’re saying, structurally, it sounds like a table?
>> ALEX: Structurally, it sounds like a table, but it’s not functioning like a table.
[screen reader voice]
I don’t know what this is. It’s like a table inside a table.
>> AMBER: Yes. So looking at the HTML, it’s coded in a table. Could this be a list instead? Like, an unordered list, Jonathan and Elijah? That’s what I think the expectation would be.
>> ELIJAH: Yes. Yes, a list would definitely be more functional. I was actually looking at this with Voiceover before we came on and realized how odd the list view is laid out. I will say that most of our testing focus when we do test with keyboard nav and screen readers is on the grid view, the normal traditional calendar view. So this one definitely flew under the radar.
>> ALEX: OK, we’ll take a look at another view.
[screen reader voice]
>> AMBER: Real quick before you select that, Alex, something else that I wanted to point out: those events, they did not read as links to Alex, but both the literal date and then the day of the week, the reason why they’re underlined, and then lose their underline if I put my mouse over them, is they have an A tag on them, even though they’re not links. And so they’re adopting the link styling that the website has. And so I think if they’re not links, you wouldn’t want to use an A tag.
>> JONATHAN: Yes, correct me if I’m wrong, Elijah. We will have corrected that in an upcoming version because there will be an individual day view. So when you click that, it will take you to the single day. Is that right? Is that what we decided?
>> ELIJAH: Right. Yes. I actually did not realize that those were actual anchors until I started working on this new feature where we needed to be able to click them and go to a day view. But they’re anchors without an href or anything currently, which is not ideal. But with the release we’re working on, those will actually function when you click them.
>> ALEX: So when you click that, what do you envision happening? Is it going to open a page, or is it just going to manipulate what’s displayed?
>> ELIJAH: It’ll just swap the view to a day view focused on the day that you clicked, just like if you changed the view using the dropdown at the top of the calendar.
>> ALEX: So you need to be very careful to manage focus in this scenario, because you’re going to change context and you’re going to have to be able to communicate to users what happened.
>> ELIJAH: Absolutely.
>> ALEX: And of course, if there is a “back” button, you need to make sure users end up where they started. Because if you’re viewing January 14th and you get dropped back at January 1st, that’s going to turn into a very frustrating situation.
>> ELIJAH: Yes.
>> ALEX: And a very common mistake, unfortunately.
>> AMBER: So you’d want to see parameters get added to the URL every time the view changes so that someone can use the “back” button to go back to the previous view that they were on. Does that sound correct?
>> ALEX: Not necessarily. I was referring to a UI back button.
>> AMBER: OK.
>> ALEX: Because if you’re going to view a day, there’s got to be a way to go back.
>> AMBER: Yes. So you just changed to the month view… And I’m sorry I started talking, so you may have stopped the screen reader, but did it tell you when you toggled the view of the calendar?
[screen reader voice]
>> ALEX: I did not think I changed it.
[screen reader voice]
I did indeed change it. That’s very interesting.
>> AMBER: And it changed a couple times?
[screen reader voice]
>> ALEX: No, it does not announce anything.
>> AMBER: OK. So [inaudible] aria-live would be what we would want on there, right?
>> ALEX: Probably not super required here because this is… I mean, if there are…
>> AMBER: In this case, you’d want a combo box?
>> ALEX: If there are more filters here, I’d be a little bit more concerned about it, but since it’s just a view selector, it’s probably fine. Easy enough to figure out for users.
>> AMBER: Yes.
[screen reader voice]
>> ALEX: So the infamous day abbreviations, these do not work well with screen readers because you just never know how it’s going to read.
>> AMBER: So do you recommend an ARIA label that is actually fully written out the day?
>> ALEX: You could try it, but ARIA labels normally don’t work in these contexts because these aren’t dynamic interactive elements.
>> AMBER: So you’d rather just see the day fully written out?
>> ALEX: Just day fully written out.
[screen reader voice]
So there’s nothing here that actually told me I was viewing previous days at the end of November, but from context, I could figure it out.
>> AMBER: So this is a table is. I’m wondering, actually, is the top row headers? Oh, it is.
[screen reader voice]
>> ALEX: It doesn’t communicate to me when the event starts and ends on here, though. That’s a problem. Like if you had “closed for Christmas on the 25th,” see it again on the 31st, but not on the 26th, 27th, 28th, 29th, or 30th.
>> AMBER: Yes. Do you have any ideas about handling that?
>> ALEX: You would probably just have to list it for the day for all those days in this type of view.
>> JONATHAN: One thing I’m curious about, if I can ask, is on the calendar on December 18th, there is an event with a start time. I’m just curious, did I possibly go over that? I was wondering…
[screen reader voice]
>> ALEX: OK, so there’s the start time.
>> JONATHAN: OK, so that is probably to do with the fact that this event we’re on now is a single day versus the other one, span multiple days. So I guess we’ll need to look into why that differs.
>> AMBER: So one way, if you need to visually leave it the way you have, you could have screen reader-only text on the other days. It’s visually hidden, but then it would still be announced to a screen reader, potentially.
I do think the abbreviations aren’t super great. It should probably say, like, 7pm instead of 7p.
>> ALEX: The other thing, too, if these events ever become clickable links, you can’t hide them like that. That would be an accessibility violation.
>> AMBER: Yes. But if the main one is still clickable, you just end up with double, then. You basically hide the one from screen readers that’s visual, right? But then you’d have a clickable visual one. It’d be better if the clickable one could fit. You could figure out how to get it to read across every day.
>> ALEX: Yes. Because what you don’t want is the rest of them to be clickable, or else when sighed users tab, they’ll lose the focus.
>> AMBER: Yes. So I’m curious about your opinion on this, Alex, because we’ve done some accessibility testing with other screen-reader users through our consulting work and we’ve always landed on the recommendation that the default view should always be a list view and not a grid view on a calendar. Do you feel the same way, or are you fine with the grid view? Because that could be interesting for them as far as what they’d recommend to their users which view should be default.
>> ALEX: I would prefer a list view to be default, definitely.
>> AMBER: Yes. So this event, that Pie Calendar event, you should be able to open it and get a modal with more information about that event.
>> ALEX: Yes, well, there’s nothing there that says I can do that. So that’s got to be converted into a button.
>> AMBER: Yes. Right now it’s a link, but the problem with it is it has a tabindex of zero on it.
>> ALEX: Yes. It’s got to be something more than that because it’s not even read as a link.
[screen reader voice]
I wonder if it’s focusable.
[screen reader voice]
These are actually focusable because of the tabindex of zero, but it’s not read as a semantic link.
>> AMBER: Yes, why is that not reading as a link? So it’s on the text. See if you can trigger the text, like, the name of the…
[screen reader voice]
>> ALEX: Yes, it seems reasonable to me. Whatever that element is, it does trigger the pop up.
[screen reader voice]
Actually…
>> AMBER: The reason why it doesn’t read is because it doesn’t have an href on it?
>> ALEX: Oh, yes.
>> AMBER: So anytime you don’t have an href, it’s not going to announce that it’s a link. But really, it should be a button because it just opens and closes the modal.
>> ALEX: Yes. The other thing here is this should actually be a modal, because it currently is not.
>> AMBER: What is it?
[screen reader voice]
>> ALEX: It doesn’t constrain focus so it’s not a modal, whatever it is. It’s an overlay.
>> ELIJAH: Can I ask a quick question about the constraint of focus?
>> ALEX: Yes.
>> ELIJAH: OK. So I noticed that when I was using Voiceover and testing, when I’m using the arrow keys to navigate, the focus moves outside of the modal without closing the modal or anything. But if you use tab, the focus should be trapped. I didn’t realize those were two separate kinds of concerns. I assumed if I had trapped the focus using tab, that it would take care of the screen reader as well. Is that a common issue?
>> ALEX: If you trap focus for tab, that’s a full-proof solution for someone with vision. So essentially, role modal or the HTML5 dialog tag, it makes the rest of the document body inert screen readers, so there’s no use of virtual mode to see outside of the modal.
>> ELIJAH: Awesome.
>> ALEX: So if your intent is to use a modal, it has to be an actual role dialog.
>> ELIJAH: Yes, perfect.
>> AMBER: I put a link in the chat to that in the MDM docs for role dialog.
>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish.
A WordPress native tool, Accessibility Checker provides reports directly on the post edit screen. Reports are comprehensive enough for an accessibility professional or developer, but easy enough for a content creator to understand.
Accessibility Checker is an ideal tool to audit existing WordPress websites find, accessibility problems during new builds, or monitor accessibility and remind content creators of accessibility best practices on an ongoing basis. Scans run on your server, so there are no per page fees or external API connections. GDPR and privacy compliant, real time accessibility scanning.
Scan unlimited posts and pages with Accessibility Checker free. Upgrade to a paid version of Accessibility Checker to scan custom post types and password protected sites, view site wide open issue reports and more.
Download Accessibility Checker free today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any paid plan.
>> AMBER: Something you did really well here is the add-to-calendar links are all labeled with the name of the event, which is good, because I’m assuming if I had multiple events, there’d be multiple of those. So I think that’s great. [inaudible].
[screen reader voice]
>> ALEX: And focus is returned, so that’s really good.
>> AMBER: Do you want to go back up to those two unlabeled toggles and change one of them?
[screen reader voice]
>> ALEX: Oh, we get the next month announced, but you must be using the title attribute on here.
>> JONATHAN: So why does it say it now, but it didn’t the first time earlier?
>> ALEX: So the mystical title rule in accessibility: never use it for this reason. The reason that we avoid using title in accessibility is because every screen reader reads it differently.
For example, if you’re just using your arrow keys with NVDA, it won’t read it. But if you use a certain focus command, such as tab, shift-tab, your button navigator command, it reads it under those circumstances. Titles, unpredictable.
>> AMBER: Yes. So in this instance, you just need to switch title to ARIA label.
[crosstalk ]
>> JONATHAN: Replace it entirely, right? Not do both?
>> ALEX: Yes. Because then you run the risk of actually getting a duplicate announcement.
>> AMBER: Yes. I’m curious about them being toggle buttons, and your thoughts on this, Alex, because they’re having, like, Aria-pressed equals false, which is what’s making them read out as toggles. And I’m not certain that I actually think these are toggle buttons.
>> ALEX: Yes, they are not. It’s just, remove that attribute and they’ll be fine.
>> AMBER: Yes. If you go forward a month?
>> ALEX: It doesn’t change the state.
>> AMBER: Yes. It also didn’t announce to you. So what would you expect to hear? We visually saw the month change to January.
>> ALEX: A message such as, “Now displaying January of 2024.” You can do that within Aria Live Region.
>> AMBER: So there’s also a week view and a time-based week view. I don’t know if you’d be interested in exploring those.
[screen reader voice]
>> ALEX: Yes, this is also very interesting because tabindex of zero and these events are block-level elements, so it won’t read this entire table all at once. I’m not actually sure how you go about presenting this properly, because if all you heard was this, [screen reader voice] it is not really a usable experience.
>> AMBER: Yes. I think the way I would handle this kind of stuff – and how we’ve advised our clients, and feel free to tell me if you think this is wrong, Alex – is that the list view should be the default. And I haven’t explored enough in your attributes if you have a way for people to turn off different views. But you should just never allow someone to turn off the list view. And then if they choose to have this view or a grid view, they could, but there’s still an alternative for a user that is the most accessible that doesn’t require somebody to try and… Because I don’t even know if, Alex, you know that there’s an event on Thursday at 10am without you having to use arrow keys to move through these. So I don’t know if you have the same thought, but that’s kind of one of the things I think about, like, providing guidance to users of your plugin is maybe not allowing them to ever turn off the list view.
>> JONATHAN: I guess I’m curious, from a kind of philosophy standpoint, how heavy handed you would be. Let’s say, Amber, if you were the owner of Pie Calendar, is that just a line that you just simply do not cross under any circumstance? And I’m just curious how you approach that.
>> AMBER: I mean, yes, [chuckles]. That’s the way I tend to look at things.
Alex, do you have thoughts about that?
I guess the way I would think about it, too, is you could also do..
If you use Gravity Forms, they have some things, some of which they had to keep for, like, legacies. Like, if they remove this setting, it would break everyone’s websites. But in the editor, they have a big warning that says using this field, like the date picker, it’s not accessible. Or turning off your field labels is a WCAG violation. So I think that’s another way you could do it, which is you could think about having more guidance in the plugin.
However, if you’re new and you don’t have a ton of users, there might be a use case for having a view like this, but just make sure that you also have the accessible version, and that people can’t say, “Oh, well, I only want the week view.”
>> JONATHAN: That make sense.
>> ALEX: Yes. So this question has actually come up a time or two in WordPress Gutenberg Development. So there’s been a couple of thoughts in the past that it’s kind of like this, “OK, if we tell users they can’t do this, they’re just going to go figure out a way to do it.” And I’ve always been of the perspective that, yes, they’re just going to go do it, but at least they can’t blame us for enabling them to make a stupid decision. Because if developers have a will, they will figure it out.
>> AMBER: Another way to think about that is, you could have a filter that allows a developer to remove the list view, but not a setting that allows the average user to do it. And then in your documentation about removing it with the filter, then you can be, like, “This is highly not recommended for this reason.” [chuckles]
>> JONATHAN: That’s great. Yes, thank you.
[screen reader voice]
>> AMBER: Peter asked: “Alex, is there any way to check if a screen reader is being used, and then deliver content dynamically based on that? So for example, default to the list view for screen readers, or the grid view for people who are not using a screen reader.”
>> ALEX: No, there is not, and probably never will be.
>> AMBER: Wait, I want to ask, how do the overlay plugins [chuckles] do that? Because I feel like I have noticed if I’m testing with a website on an overlay plugin, or a website that has an overlay and I have a screen reader on, it sometimes does different things than if I go to it without a screen reader on.
>> ALEX: My guess is that Apple might expose some type of API for it. I don’t think it exists on Windows right now. I don’t know. [chuckles]
The overlay companies do a lot of bad things that no one else should copy. And there’s a lot of things they do that I’m very unsure of how they do.
>> AMBER: Yes. I think you might be right. I feel like there is a way to tell a Voiceover is being used, kind of like you can tell what someone’s system preferences for color mode is, but I don’t know that that’d be possible with NVDA or JAWS, so I’m not sure how reliable it would be.
>> ALEX: I’ve been told that it comes down to, like, privacy issues, and that’s why there’s never been a standard created around it, which makes sense.
>> AMBER: Yes, because it could allow someone to discriminate against someone who’s blind.
>> ALEX: A lot more easier than it is today. We’ve already got plenty of ways today.
>> AMBER: Yes. Before I let you go on, one thing that I noticed, and I don’t know if this is the 2024 theme or if this is you all’s the blue color, but the white on the light blue text probably fails color contact contrast. So I would just change your default colors there and either make it a little lighter blue with black text or make it a darker blue.
Is there anything on the front-end that we missed that you want him to look at?
>> JONATHAN: There’s two other views that could be looked at.
[screen reader voice]
>> ALEX: What I’ll say is this seems to follow the same DOM structure on every view. It might change things visually, but I’m not actually seeing a whole lot of difference across these views.
>> AMBER: Yes. The biggest difference between this and the week view or the month view is that you can find the events faster.
>> ALEX: Yes.
>> AMBER: I think the way I would structure this is it should be in… If it’s called a list view, I would make it a list. And then it’s just a debate on where the list is, and if there’s a list under every day, right? If you’re in a week, each day. So it could just be one item. Or it could be, if it’s a really busy calendar, five things that happen in one day, or whether it’s higher up. But I kind of feel like you could make the actual dates, because I noticed that, like, I don’t think he can get to those dates in this view. Like, December 31st, January 1st, January 4th, I didn’t notice those being read out. But those, to me, should be like, if the title of the page is an H1 and the date span is an H2, then maybe those days are H3s, and then the names of the events are lists below it.
Alex, I don’t know if you have thoughts about that structure?
>> ALEX: Yes, that’s probably an OK structure for this.
>> AMBER: Yes.
>> ALEX: Calendars in general are very hard for accessibility. Even our friends at the big, big, big calendar companies don’t always get it right.
>> AMBER: Yes. We’re talking about outside WordPress-big calendar companies. [laughs]
>> ELIJAH: Yes, I figured.
>> AMBER: Do you hear about the color? There’s a color next to the events, and I’m curious if you hear that or not when you’re going through.
[screen reader voice]
>> ALEX: Doesn’t sound like it.
>> AMBER: OK. And it does actually has aria-hidden on it, which I think is fine. So basically, you can assign a color to different events, and then it puts a dot with what the color is.
I don’t know if you all have thoughts about where you’re going with that long term, but if there’s thought that it could provide meaning… Like, if they’re on events, they’re not on the category, so maybe it doesn’t provide meaning; but if it does, then that might need to be surfaced in some way.
>> JONATHAN: Yes, it’s not a super-popular feature request right now, but we have had a few people request the idea of global colors; in particular, ones that could kind of attach to WordPress Taxonomies. So if your post is in the category of, you know, whatever party, and party is orange, then that dot would change accordingly to match your global color. That doesn’t exist currently, but that’s something kind of in the distant future, maybe.
>> AMBER: Yes. Do you want to look at the back-end, Alex?
>> ALEX: I think we have one more view.
>> AMBER: Oh, yes, I think you’re right.
[screen reader voice]
>> ALEX: See, this is like a table in a table because it says two rows with seven columns, but we can definitely clearly understand that there’s more than two rows in this table.
>> AMBER: No, there is actually only two. The first row is the header, and then the second row is just one [inaudible]
>> ALEX: OK, so this does change a little bit depending on the view. Interesting.
[screen reader voice]
>> ALEX: So then you would have to go to the next week because this is the week view. OK, following this now.
[screen reader voice]
These are also a little tricky, because if you navigate this, [screen reader voice] the table navigation, it’ll just get read out as 10A, then it’ll start reading, because there’s no actual punctuation in here to force a screen reader to stop speaking before that. You can use, like, a colon or a comma or something to do that, because just visually splitting it onto another line doesn’t do it.
>> AMBER: OK.
>> ALEX: I think that’s probably about all the feedback that I had. I mean, nobody would be actively stopped from using this.
>> AMBER: Yes. I think the hardest things are that they wouldn’t know that they could expand to get more details.
>> ALEX: Yes. Yes.
>> AMBER: Yes. So what’s interesting and unique about this one is that it doesn’t have its own post type. You can add any post to a calendar. And basically, it just adds some settings.
I have Gutenberg, of course, turned on on this website in the right-hand column. Like, if you just went to a post to edit the post, maybe you could take a look at those and see if you see any issues with the specific settings there.
>> ALEX: So I’m looking for what exactly?
>> AMBER: Posts. And you could edit any one of the posts or you could add a new post.
[screen reader voice]
>> ALEX: So I will add a disclaimer, like I do every time we go and look at the back-end: This might be fairly hard to figure out where the accessibility issues lie because the editor is pretty terrible for accessibility.
>> AMBER: Meaning, it might not be your fault. [chuckles]
>> ALEX: It might not be your fault.
[screen reader voice]
It is getting better slowly, but the more features that go in, the further we fall behind.
>> AMBER: So all of the settings for this are in the post settings.
[screen reader voice]
>> ALEX: Yes, it doesn’t read these.
[screen reader voice]
>> AMBER: What do you mean it doesn’t read those?
>> ALEX: It doesn’t read what those values are set to. This is going to be fun to navigate.
[screen reader voice]
So to try to explain to people what type of interaction this is, it’s like an expandable accordion that traps focus into, like, a dialogue, but it’s not a semantic dialogue at the same time.
>> AMBER: How were you all building this? Were you using a core component, or was this a custom piece?
>> ELIJAH: So everything’s core. We haven’t written any custom components for Gutenberg.
>> ALEX: Oh, that’s heartbreaking.
[laughter]
>> ELIJAH: We may have screwed it up at some point along the way, but we tried to use all core stuff.
>> ALEX: I’m almost positive it wasn’t your fault. OK.
[screen reader voice]
So if we open this, [screen reader voice] we get put in this hours field. Obviously, it’s set to 7. [screen reader voice] And I was expecting that if I press the right arrow, I might get minutes, but that’s not going to happen, so we’ll try tabbing.
[screen reader voice]
Then, of course, AM, PM. It doesn’t tell you which one is selected.
>> AMBER: Yes.
[screen reader voice]
>> ALEX: Now that works, more or less.
[screen reader voice]
This also works pretty well.
>> AMBER: So the biggest issue is the AM/PM doesn’t announce which one is selected. The other ones all tell you what’s selected?
>> ALEX: The other problem is this.
[screen reader voice]
I’m going to sit here and tab around that all night, and I’m never going to find a way to get out of there.
>> AMBER: Yes. There’s a keyboard trap.
>> ALEX: It’s because developers these days have assumed that everybody knows how to press “escape.”
[screen reader voice]
Don’t ever make assumptions for your users.
>> AMBER: So there should also be a close button in that pop-up in addition so that it can be closed in that way.
>> ALEX: Preferably, there would be a button that says “save.” Or at least something in there that would make users not think closing that would lose what they just went in and did.
>> AMBER: Yes. I’ll admit, actually, when I was adding these the first time, it took me a minute to figure out that I could just pick what I wanted and then click “away” and it would go away.
>> ALEX: But this is an overall UX problem with Gutenberg, because since there’s no committing function like a “submit” button, and it all gets handled when you publish or save, it’s very unclear to people if clicking “close” or clicking “away” actually won’t lose their changes. So there’s that.
>> AMBER: Yes. The other thing that I noticed here is, visually, it does show. And I don’t know if you were to read without doing the tab key, if you would hear it. It says the start date and the end date. It does not show the time. I think blind people need that surface, too, but I also… Because then I was like, “Oh, what if I need to change the time?” Like, I wanted to see it all without having to click on those to make sure that I… What I had selected.
[screen reader voice]
>> ALEX: “Event color recurrence.”
>> AMBER: Yes, it should say “and recurrence,” but it’s an ampersand so I don’t know.
>> ALEX: Yes, it’s not going to read that.
[screen reader voice]
See, focus is not actually trapped in this panel, which just leads to more unpredictability.
[screen reader voice]
>> AMBER: I think those are like regular Gutenberg panels.
[screen reader voice]
>> ALEX: All these work with the exception of a button to close it.
[screen reader voice]
So, yes, that looks like some Gutenberg improvements, maybe.
>> AMBER: Yes. But honestly, actually, I’ve seen custom stuff like this where those toggles weren’t actually… Like, they were divs and stuff. So I applaud you all that it said it’s a checkbox and whether or not it’s checked. Even though, visually, to us, it doesn’t look like a checkbox, it functions, so I think that’s really good.
>> ALEX: Yes, it does function, which is great, because it means that at least some of our components are following accessibility standards, and that’s nice to see.
>> AMBER: Yes. I’ve seen where people build stuff in here, and it’s not that it’s Gutenberg didn’t do it, it’s that they didn’t. So I think it’s good that you guys use whatever was coming out of Gutenberg to be consistent.
Billius, who is also a screen-reader user every day, said in the chat: “It sounds pretty good to me compared to other calendars that I’ve used before.”
>> ALEX: Yes, I’ll second that.
>> JONATHAN: That’s awesome. Thank you guys.
>> AMBER: I’m not sure if this was on the front-end or the back-end, but Deneb asked: “Do the ‘previous’ and ‘next’ buttons have accessible names?”
So I think on the picker on the back-end, I did hear “next month, previous month…” Oh, front end. He clarified front end. So the answer on that was, no, those do not currently have accessible names, but we talked about that being a title attribute.
The only other thing is there’s a very minor settings page, which you could find under “settings,” if you wanted to look at that, Alex.
[screen reader voice]
>> ALEX: Have we ever finished one of these kind of early? [chuckles]
[screen reader voice]
>> AMBER: [laughs] I think one of the things that is neat about this plugin is that it is very simple, as they said before. And to some degree, I feel like if you’re building a plugin, that’s a good way to start because it makes it easier. You can get all the stuff accessible, and then just build [inaudible] foundation.
>> ALEX: Definitely. Definitely.
[screen reader voice]
Oh, I found an issue.
[laughter]
Heading level two for title. No, don’t do it. Heading level one. Follow heading order.
>> AMBER: Even in the admin.
>> ALEX: Even in the admin.
[screen reader voice]
“Don’t float” buttons is in line next to submit fields. That’s not good. Keep these block level.
>> AMBER: So you’re saying the “activate license” button, you want it to be below not next to the field?
>> ALEX: Because for people who are using the arrow key navigation, this becomes a little fun to get to.
>> AMBER: OK.
[screen reader voice]
>> ALEX: OK, so this is a problem. There’s no field set or legend on these. So if someone just came in contact with this checkbox, they would not get any information about what they are actually allowing.
>> AMBER: Are you familiar with those field sets Elijah?
>> ELIJAH: Apparently not. [chuckles] No, I am familiar with the concept, but I haven’t obviously dove into it for these settings pages.
>> AMBER: Yes. So I put a link to the MDN docs for field sets.
>> ALEX: The other thing you should do is reverse the positioning of these labels and checkboxes. It’s always recommended to have checkbox first, then label. It just makes things easier.
>> AMBER: The other thing that I might comment on: these are styled to be round, which suggests you can only select one that is going to be a radio input, but it seems like you could select multiple, right?
>> ELIJAH: Right. I noticed that as well. I don’t think that we style them. They should just be HTML checkboxes. I’ll check on my local, but [crosstalk ].
>> AMBER: It’s interesting. Actually, I just opened it and I see them as squared. But when I look at Alex’s screen, they look around. So what browser are you in, Chrome?
>> ALEX: I’m in Firefox tonight.
>> AMBER: Firefox. Check Firefox. [laughs]. Like, that’s the fun thing about some of this, right? It’s browser specific.
>> ALEX: And operating-system specific, and screen-readers specific, and yes.
>> AMBER: Yes. Firefox on Windows.
[screen reader voice]
>> ALEX: Very easy page.
>> ELIJAH: I see a problem, I believe.
>> AMBER: What’s the problem?
>> ELIJAH: That calendar link and the description above those fields did not indicate it was a link, I don’t think, [crosstalk ]
>> ALEX: It did.
>> ELIJAH: OK.
[screen reader voice]
>> ELIJAH: OK, cool.
>> AMBER: Yes, cool. Well, do you all have any other questions while we have Alex here?
>> ELIJAH: I for sure do. I know when I was working on some accessibility stuff for Oxygen, it was really helpful to have recommendations from you on themes and things that did things right. So I guess, Alex, do you have a calendar interface that works really well for you that we could take inspiration from while we’re improving all these stuff you found?
>> ALEX: OK. So I don’t work in WordPress anymore. [chuckles] I might be the wrong person to answer this.
>> AMBER: What about any calendar?
>> ELIJAH: Any calendar, right?
>> AMBER: Yes, it doesn’t have to be WordPress.
>> ALEX: Answer is still the same. [chuckles] No.
>> ELIJAH: [chuckles] OK. So are they all pretty rough?
>> ALEX: There are calendars out there that are really, really bad. I mainly interact with my calendar through Microsoft Outlook, and even that’s not accessible out of the box. There’s been a lot of screen-reader coding to deal with that.
>> ELIJAH: OK.
>> AMBER: So Billius said to try FullCalendar, all one word.
>> ELIJAH: That’s actually the library we’re using to power Pie Calendar. So a lot of the front-end stuff, anything outside of the modal, mostly is stock FullCalendar stuff with slight modifications. So for a lot of the notes that I’ve taken from tonight, we’re going to have to dig into FullCalendar’s code and make corrections there, which, hopefully, we can then open pull requests with FullCalendar and help them improve for everybody that uses that library.
>> AMBER: Yes, that would be awesome.
>> ALEX: Yes, giving back is always great.
>> AMBER: Yes. I think for me, the biggest thing, too, would be rethinking that list view to not be a table.
>> ELIJAH: Right. And then you mentioned never getting rid of the list view, right? Is that something you would envision being available concurrently with whatever other view was chosen, like, visually, side by side, or above and below each other?
>> ALEX: No.
>> AMBER: Alex, you might have thoughts about that, but I don’t think you would want to have the two visible at the same time because that just adds extra noise for people. And it’s like repeating the same information.
>> ELIJAH: Yes.
>> AMBER: One thing that you could do that is making… And, again, sometimes this is, like, provide information in your documentation, like, have an accessibility page in your documentation that’s like best practices for your users. But let’s say a university wanted to use this… And universities all have to follow Section 508 and have a lot more accessibility, so they might want to. I don’t know if you necessarily have to do this, but they might want to, above the calendar, if for some reason, they didn’t have the list view as default, have a message that’s, like, “For the most accessible view, switch to list view,” right?
I’ve seen things where we’ve been working on remediations that were mandated by the Office of Civil Rights, and the Office of Civil Rights is very much, like, if you provide messaging above the thing so someone can get it and you tell them how to get the accessible alternative, then that’s sufficient for the Office of Civil Rights, which is part of the Department of Education. Now, I think it should default to the accessible option.
>> ALEX: Yes, don’t even give me a platform to start running on that.
>> AMBER: Yes, I mean, you definitely think it should default to the accessible option, right?
>> ALEX: Yes, because, I mean, we can look at some of the biggest companies out there: “Oh, if you have problem using our website, please call this number.” Like, really? Aren’t you just admitting to the world that you are ready to be sued?
>> AMBER: Yes. I think there’s a weird line that plugin developers have to walk on that, right? Because you’re going to get a lot of requests for different things. And for us, we will sometimes think about, you know, we make decisions based on accessibility.
Someone asked us once, like, this is a really good example. With our plugin, we don’t have anything that’s visible on the front-end, and we’ve had multiple clients say that they want one of those little round accessibility icons. They’re, like, “We know we shouldn’t use an overlay.” But for some reason, they think having the little floating bug on their website communicates to their customers that they care about accessibility, and it’s going to help them. And we’ve had multiple people be, like, “We just want that to be a setting so we can turn it on, and they’ll put the thing, and then it’ll pop up a message if they click on it about accessibility.” [chuckles] Because I’m like, “Well, it’s not an overlay.” But we don’t want to do it because those floating bugs can really cause a problem for low-vision users who zoom in and then it blocks other things on the screen, and so we’ve just said no. And so I think sometimes you have to make decisions and just say, “We know this isn’t going to be good.” Or make the default, and then if you have to have a filter, then only a developer can override it. And in theory, hopefully, in your documentation, the developer has read why you don’t advise doing this.
[screen reader voice]
>> ALEX: And then if we want to get to the practical aspect there, since we have enough time to get into the practical aspect of that, for all the users out there who want that little floating, annoying icon to tell people how much they care about accessibility, mainly, the people who want that so much are the ones who don’t have good accessibility, almost every single time without fail.
>> AMBER: Yes.
>> ALEX: But don’t tell me you have good accessibility. Show me you have good accessibility.
>> AMBER: Yes. If the website just works, then you don’t really need the floating icon, right? [chuckles]
I think another thing, too, like, we were talking about color contrast, and I think there’s a lot of people who will just recolor it to match their brand. But a good practice, which is also the way it is in themes if you want to get the accessibility-ready tag, is your out-of-box colors have to pass color contrast. And you know that people might change it.
One thing I wasn’t sure about in years is, I saw that there was, like, a text color setting. I actually turned it on for one of the events, but then I didn’t see where it actually changed the text color, so I’m not sure about that. But that might be something to think about, if you want to actually allow people to change the color of the text. Or if you do, that’s a prime one for… In Gutenberg, if you choose certain color combinations, it will warn you. So I don’t know if it would be possible for you to put a warning on there, if they choose a text color that is, like, super light gray or whatever, that it’s not going to pass for contrast.
>> ELIJAH: Yes. So the text color would only apply to all-day events, I believe. So it would use the normal color as the background of the all-day event. So we should have enough insight to check the contrast, and that’s something I have a little bit of experience with, so that’s something we’ll look at for sure.
>> AMBER: Yes. Well, now I have to go look. So that would be like the all-day events on, like, the grid view.
>> ELIJAH: Yes, the ones with the solid background color.
>> AMBER: OK. So I didn’t try playing around with that on the all-day event. Yes, so that might be a good one to put a warning on.
Peter put a link in the chat for everyone, showing what the short code was, and a link over to the short code options in your documentation.
>> JONATHAN: Yes, that was really helpful, Peter. What he shared was the short code that makes the list view, the default view, upon loading. And, of course, right now, there’s not functionality in the plugin to prevent or hide the other options without, you know, CSS to manually hide it. But yes, that’s a great way to make it default to list view right now.
>> ELIJAH: But also to add to that, for anyone thinking about doing that, based on this demonstration tonight, the list views are not great. I’m almost thinking we may need to hook into FullCalendar and create our own list view with just accessibility in mind so that we can tell people that’s the one to use if you’re using this on your site.
>> AMBER: So this is an interesting question, though, because you’re making your own short code: Does the list view actually have to use full calendar at all?
I get why you would use their API to create the grid and everything, but maybe you could query and just build it out.
>> JONATHAN: We could. FullCalendar does handle a lot of the logic that comes along with calendars [crosstalk ].
>> AMBER: Oh, for like past events, future events, that kind of stuff?
>> ELIJAH: Yes.
>> JONATHAN: And, like, time zones.
>> ELIJAH: Date calculation, things like that. Time zone stuff, yes. It would be daunting to rewrite that kind of logic in this scope of a project. But I’m certain that there’s a way for us to write our own views for it. And I really am interested in digging into that now that I’ve seen how non-navigable the tables are the way they’re structured now.
>> JONATHAN: So, Alex, from my perspective, just to understand kind of where we lie on our typical grade scale score, like, if you came to a website with this calendar, is it functional? Would you get what you needed out of it? Or is it essentially as worthless as all the other calendar plugins?
>> ALEX: You would not get the ability to view the full event information. That is the only preventing factor right now that would really hinder somebody actively.
>> JONATHAN: OK, that’s good to know. That’s fixable for sure.
>> ALEX: If I was going to say, the next best out there is probably Google Calendar, and dead last is Microsoft because their calendar is just awful. I mean, terrible. It is so busy. I’m not sure people with sight could figure the thing out.
>> JONATHAN: Agreed.
>> AMBER: Yes.
>> ALEX: As long as you don’t imitate Microsoft, you should be fine.
>> AMBER: Billius says that Calendly is also good. Do you have any thoughts on Calendly, Alex?
>> ALEX: Yes, it is good. It works. It’s very, very simple.
>> AMBER: Yes. So that’s more like on the picking side, but you could explore what their month view looks like or day view or…
>> JONATHAN: Yes.
>> AMBER: I don’t know if you only have a Mac, but on BrowserStack, now you can emulate a Windows machine and use in NVDA if you don’t have a PC. And I would recommend testing with that because more screen-reader users are going to be on a Windows device than a Mac.
>> ELIJAH: I actually do have a question for Alex about in NVDA. I would love to dive into learning to use it properly. And I know that might be hard as a sighted user, but I wondered if you have any recommendations for me as a plugin developer to learn to use it properly to audit as we’re developing, but also just as a user of NVDA to learn from kind of square one.
>> ALEX: Let’s see. NVDA user docs are pretty good.
>> ELIJAH: OK.
>> ALEX: And really, I mean, I’m sure there’s probably some websites out there that’ll walk you through basic usage of it, but I was always a technical boring type who just stared at documentation and went through stuff out, so.
>> ELIJAH: [chuckles] Sure.
>> AMBER: So last February, we did an event with Carroll Center for the Blind, and one of their teachers who teaches people to use screen readers did a course for us on NVDA. I know we’ve been talking about trying to break it up and make it available to people, so maybe that’s something that we could do. And I can let you know as well as other people who are watching, if they’re interested.
>> ELIJAH: Yes, that would be super helpful, because I think screen readers are daunting just because it’s a whole different mode of consuming information. And a lot of developers are stretched thin, and of course they should learn to use it so that they can test for people that need it. But having some kind of simplified route to learning to use it properly so that we know we’re using it in a way that’s going to catch the issues that people that are using it every day will run into, that would be helpful.
>> AMBER: Yes. It looks like FJ [phonetic] said that Polypane development browser has accessibility testing as a feature. FJ uses it, and would be interested if anyone has any experiences with it.
I have not used Polypane. I don’t know if any of you all have used Polypane.
>> ELIJAH: I did briefly, but I prefer to axe DevTools. I feel like Polypane had too many bells and whistles or something. I don’t remember exactly, but I wasn’t super happy with it.
>> AMBER: Deneb shared a link on his website to screen reader ropes course for maybe learning screen readers. So that might be a useful resource as well.
>> ELIJAH: Definitely.
>> AMBER: So we don’t have any other open questions in the Q&A.
Jonathan and Elijah, do you want to let people know where they can go to learn more about Pie Calendar, or get in touch with you if they want to follow up afterwards?
>> JONATHAN: Yes. So, of course, we have our website, “PieCalender.com.” There’s a contact form on there. You’re more than welcome to fill it out, especially if you’re here, if you have any questions. And happy to do a little video demo if you have a specific question.
I think we covered a fairly comprehensive use case of how you would use it. We like to tell people you would get started using it in just a couple minutes. And I think, hopefully, seeing it this evening was enough to get started with it if you’re interested.
Also, I should mention as well, we have a really capable free version. What we saw tonight was the pro version, but the free version is available on the WordPress repo. And that one is very similar to what we saw, just minus recurring events, essentially, and a couple other bells and whistles.
>> AMBER: And, Alex, how can people follow up with you?
>> ALEX: You can follow up with me on LinkedIn. I’m just Alex Stein on LinkedIn. And I try to respond there as quick as possible.
>> AMBER: And it’s S-T-I-N-E.
>> ALEX: Yes.
>> JONATHAN: I wanted to just quickly say how much I appreciate this. It’s such a useful insight into just a totally different perspective on our plugin. Because clearly, Elijah and I have tried to do some accessibility testing, but had we done it properly, we would have seen that the event link doesn’t take you to the modal properly, and focus trapping, and those sorts of things that feel so silly to have overlooked. But without your help, Alex, we wouldn’t have uncovered that. So just wanted to say thank you very much.
>> ELIJAH: That was incredible. Thank you.
>> ALEX: No problem at all. Happy to help.
>> AMBER: Yes. Yes, we very much appreciate that you came and you’re willing to do it.
As I told you behind the scenes, we’ve been evaluating doing this to switch from our calendar, which I think is a little bit more complex than what we actually need. So I’m excited to see where you all take this, and maybe roll it out on my website in the spring.
>> ELIJAH: Certainly hope so.
>> AMBER: Yes. All right. Well, I’m going to sign off. You all are free to leave, but I don’t close Zoom until I see all the captioning go through, because it’s on a little bit of a delay. So there’s, like, a moment of silence and awkward smiling and waving.
Thank you, everyone. I hope everyone has a happy new year. And don’t forget that we will be back on January 4th, so right after the new year, for a talk on accessible copywriting with Abby Wood.
>> ELIJAH: Thanks so much.
>> ALEX: Thanks. See you.
>> ELIJAH: Bye-bye.
>> CHRIS: Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find Accessibility Craft on Apple podcasts, Google podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we helped make 1000s of WordPress websites more accessible at equalizedigital.com.