Pie Calendar Plugin Accessibility Audit: Alex Stine and Amber Hinds

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup. We are going to be doing a live audit of the Pie Calendar plugin, which is super fun, and we’ll talk more about what that is here shortly. 

I have a few announcements. If you haven’t previously been before, we have a Facebook group that you can join to connect with other people between meetups. You can find that if you go to Facebook and you just search “WordPress Accessibility,” or the URL is “Facebook.com/groups/WordPress.accessibility.” 

Everyone always asks, “Is this being recorded?” The answer is, yes, it is being recorded. You can find all of our upcoming meetups and recordings of past Meetups in one place if you go to “EqualizeDigital.com/meetup.” That will redirect you to a much longer URL and you’ll be able to find it. It takes us about two weeks to get corrected captions and a full transcript. It might be a little bit delayed this time of year because we are going to be off for a holiday break next week, but we will get it up as quickly as we can. 

If you want to get notified when the recording is available, please feel free to join our email list. You can do that at “EqualizeDigital.com/focus-state,” and that will give you upcoming event announcements, news; and then when we publish the recordings, we always include links to those as well. 

We are releasing the audio; Alex inspired us to do that. So if you prefer to listen to the recordings instead of going to YouTube and watching them, you can find the recordings from meetup events on our podcast, “AccessibilityCraft.com.”

Finally, it is the end of the year, and we are starting to look at what 2024 looks like. We have some speaker slots available, and we are also looking for additional sponsors to help us cover the cost of the meetup. The WordPress Foundation unfortunately told us that they can’t cover the cost of live captions. So they said, “Go out and find sponsors.” So if you would be interested in sponsoring a meetup, or if you’d be interested in speaking in 2024, please reach out to us. You can email “Meetup@EqualizeDigital.com,” and that will go to myself and Paola. 

So who am I? If you haven’t been before, I’m Amber Hinds, the CEO of Equalize Digital and the lead organizer of the meetup. We’re a certified B Corporation that specializes in WordPress accessibility. And we have a free WordPress plugin that you can find on the “WordPress.org” repo called Accessibility Checker, which helps you audit your websites for accessibility problems. 

I have one sponsor that I want to thank tonight. And also, I have to give a shout out because Texas Closed Captioning, not only are they donating their services to us tonight, they’ve been doing that for a few of our meetups, which we very much appreciate. But they have been the captioner who has been captioning all of our events since the beginning of the meetup a couple of years ago. They have done a phenomenal job. 

I have been on many other events with live captioners. And I have to tell you, I have never seen anyone match the accuracy or the speed. And I’m very impressed when they caption code and developer speak and all that kind of stuff. So we really appreciate Texas Closed Captioning. They’re a woman-owned small business that is based near me in Austin. And in addition to doing real-time captioning, they do Remote CART Services and some transcription for post events as well. 

I highly recommend learning about them. You can learn about them if you go to “TexasCaption.com.” 

The next events that you want to be aware of: right after New Year’s, on Thursday, January 4th at 10am US Central Time, Abby Wood is going to be talking about “Writing Accessible Copy.” So if you are a copywriter and you want to make sure that your copy works for everyone, this is definitely a meetup to attend. 

Then on Monday, January 15th, the same time slot, at 7pm US Central Time, I’m going to be doing a presentation about “Building a Low-code Accessible WooCommerce Website.” I am going to build one before then. I agreed that I would do it because we didn’t have a speaker, and now I’m sitting here being like, “Hmm, I actually have to do this.” But I’m going to have a case study. It’s going to be available. I’m going to set stuff up on Printful, because everyone always asks if they can get my Make-WordPress-accessible t-shirt. So literally, that’s what we’re going to sell, and we’re going to give money back to WordPress Accessibility Day to help fund the event next year. But I am going to try and do it without coding anything, or only maybe doing minimal CSS. And we’ll report back on how you can make an accessible WooCommerce, or not. We’ll all find out on January 15th if it can be done without code or whether it needs a lot of code. So that’s what that meetup will be about. 

Then on Thursday, February 1st, we are excited to have Mikaela Letterman coming back to talk about, “Do More With Less Aria.” She was scheduled earlier this year, but had an emergency come up in her family and had to reschedule, so we’re excited to have this talk come back. So please tune in for that at the beginning of February.

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. 

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.