CHRISTOPHER SORAN: We're recording, ready to get rolling. 

MONICA OLSSON: Well, welcome to February 2026 additions to Accessibility & ctcLink Open Forum. Today we have an audience size of one, Michael. 

MICHAEL: I think we've got a few others. 

MONICA OLSSON: Oh, good. Do we? Oh, great. Oh, I see a few others joining now. Awesome. Oh, there's Cecilia and Agnes. Welcome. Great. Onward and upward, shall we? 

CHRISTOPHER SORAN: Good afternoon or morning, depending on your time zone. We're going to talk a little bit about Okta, about the listserv, and some software audit standard procedures. 

MONICA OLSSON: So I'll kick this off and then hand it over to Vicki and Josh. They'll provide them more technical conversation. but-- oh, there's Crystal. Hi, Crystal. So Okta, as a reminder, is a MFA, or Multi-factor Authentication, tool that the State Board and the colleges use as security measure when logging into ctcLink. 

It's not an Oracle product. It's managed by a different company. But we still pay attention to its accessibility and usability for people with disabilities and assistive tech users, particularly because it's used by colleges in conjunction to logging into ctcLink. 

Vicki on my team and Josh on Chris's team, and Chris and myself, we've all been in conversation with Okta product folks for many months now regularly, meeting to talk about changes to their UI and design, improvements to accessibility. 

And depending on what changes have been made or are slated to be released, Vicki and Josh will do testing internally. And then we share that with the vendor in hopes that it helps them continue to improve their products. So we did a very recent round of evaluation. And that's what Josh and Vicki are going to summarize for you guys today. Hope that was a good intro. All right, Josh. 

JOSH GIHA: Yeah, I'll go first. Hi, my name is Josh Giha. I'm a developer on Christopher's team. I'm going to go ahead and share my screen here. So since we got Okta, at first, there were a couple glaring issues that affected everybody, and then they were pretty quick to get those fixed. 

But over the past year or more, we've been awaiting changes to come to the account settings page in Okta. So when you go to your user preferences and you want to set up another authentication method, that would be under the Account Settings, Personal Information, and then you would have a couple options for setting your personal information. 

So this is one of the new pages. And overall, all the changes that came through were pretty good. We only noticed a few differences. And as you can see, there's actually a couple more findings I have earlier in the document, but that doesn't pertain to the updates that you all will be receiving. It's just internal to SBCTC. 

So the one issue is, under Personal Information, when you go to edit your details, at first, when you get to the page, it just shows the Edit Details button. And when you tab down or try to arrow down to see what information is stored, it doesn't display anything. It doesn't announce anything to the screen reader. 

When you click Edit Details, then all of these fields come into the DOM for the screen reader. And it also does this funny thing where it leaves the focus on the button that is no longer there. So the Edit Detail button disappears after you click it, and the fields come into play. But the focus remains on this empty rectangle area. 

So we've reported that to Okta. And it's not something that you would come across just doing a automatic scan. It's something that you would have to actually turn on a screen reader and keyboard-navigate through the page in order to witness that behavior. So that's been reported to Okta. 

And the other pages that they've updated the display language, security methods, and recent activities, those are all good to go. They passed testing. And yes, we're happy that they'll be going into production soon. 

CHRISTOPHER SORAN: And Josh, do you want to clarify what tools you use when you are testing? Because I know you and Vicki split up how you were approaching it. 

JOSH GIHA: Yes, yes. I used NVDA, as well as, on the Mac OS, Narrator. And on the mobile device that I was using to authenticate, I was using Android, so TalkBack for Android screen reader on the mobile device. And then on PC, I use both Firefox and Chrome using NVDA. And on the Mac OS, I use Safari and Chrome using Narrator. 

MONICA OLSSON: Thank you. 

JOSH GIHA: Do we have any other questions? If not, I'll go ahead and pass it along to Vicki. 

VICKI WALTON: Thank you. So, like Josh said, we split up the assistive technology. And I use JAWS 2026 on Chrome and Firefox, and then VoiceOver on an iOS and an iPad, and tested both the Okta, SBCTC EDU, and the ctcLink.us And the first test was SBCTC. And they're little things, but they're important. 

When I navigated the login, when you land on or, all it says is separator. So that was sent to Okta to-- it doesn't give enough information to know, well, OK, separator, what does that mean? And then while I was navigating the security methods, when using JAWS, when I activated the section, and pressing Enter, it doesn't provide any information that the page has loaded. 

So there's no feedback indicating that if you open up any of these pages, Personal Information, Display, Security, it doesn't let you know that the page loaded. So you're just sitting there. So it just goes on to security methods. And press Enter, and then it doesn't do anything. 

So then on this one where you edit your nickname, there is a pop-up, but there is no notification that anything happened. So yeah, there's no voice output letting a screen reader know that anything happened after you edited a nickname. And same with removing the nickname-- there was nothing noted verbally to let the screen reader know that anything happened. 

And that's just summary. So now on the Okta, I had the same issues with Firefox. So it wasn't really worth noting those in the report. But now we're going to go to ctcLink.us. And the first thing that was-- does not-- oh, yeah. So it's the same here that when you open up any of these selections, it doesn't let the user know that anything happened, that the page is loaded and you can move forward. And that was Josh, probably, he already talked about that. 

JOSH GIHA: If I may add, Vicki, thank you for highlighting. That was also a point that I had in my documentation that they don't let you know when it's loading or the loading is complete. So we suggested that they either announce it loading or have a tone indication for when the page is loading and when the loading is completed. 

VICKI WALTON: Yeah. Thank you. So basically, the same went with Firefox. It was pretty much the same issue. I didn't have any issues with the Okta Verify app on the iOS or the iPad using VoiceOver. So most of our reporting was on the dashboard. And I just want to note that when I first did my testing, they still had the old-- let's see-- on the ctcLink.us, still had the old-looking platform. 

And of course, I found issues with it. But then Josh and I had a meeting and went over our information. And as we were logging in looking, they had updated that dashboard. So I redid my test completely because no use reporting on something that was changed. 

So now both environments really do look the same. So it's more there's more continuity, and it's easier to navigate actually. And I'm so glad that it was updated, because that old design was still not accessible. So does anybody have any questions? 

MONICA OLSSON: For our college folks, the-- excuse me, environment and testing results that are, I think, most pertinent for you all understand, are that when we're in the ctcLink environment, because colleges are required to use Okta MFA with ctcLink login. 

What MFA product you all are using for additional applications beyond ctcLink, it varies across school. So you might be using Okta for more than ctcLink application, and you might be using another tool. Here at the State Board, we're using it for almost everything that we're logging in. 

And I think when I read the reports and listened to Josh and Vicki, I think a lot of the findings boil down to a couple of key issues, to synthesize it for you all. It's continued improvement of button labeling, so how a button is labeled in the code needs to match how it's visually labeled on a screen. Otherwise, there's a discrepancy there. 

And then when new content loads, reload, et cetera, that needs to be announced to someone who's not visually seeing the action take place on the screen, and so is relying on some sort of auditory cue or announcement that that's happening. And maybe I've forgotten the key finding, but I'm just trying to boil it down for you guys. 

So in terms of next steps, we've shared these reports already with our key contact at Okta, who-- he's not an accessibility person, but he goes back to the accessibility team and the product owners to share the reports, have discussions on our findings. At our next meeting, those guys are going to join us to talk about what-- they get to ask us clarifying questions if they want, but then they also are going to share their plan with us for remediation. 

CHRISTOPHER SORAN: Sounds good. 

JOSH GIHA: And if I can just add, yeah, so some of the findings that I actually have in the document are pertaining to a part of Okta that we have turned on the State Board side of our Okta stuff. That's not going to be turned on the ctcLink Okta. 

But if your institution is using Okta for additional things and they do plan on turning on FastPass, we have the testing findings for that as well. And you can reach out to myself via email if you're wanting to find clear details on FastPass. That's it for me. 

MONICA OLSSON: Thanks, Josh. We probably move on now, I think, Chris. 

CHRISTOPHER SORAN: That's good. 

MONICA OLSSON: So several years ago, when I first started at the State Board, I worked with Chris's predecessor to put together the ctcLink accessibility email listserv. And the idea was, anyone across the colleges who needed to be kept in the loop around ctcLink accessibility issues and remediation projects could join that listserv. 

And the idea was that the State Board would use that listserv to share upcoming announcements for the open forum. But if folks wanted to have off-forum discussion, question, et cetera, that we could use that as a conversation space. And largely, it's been inactive basically the entire time it's been in existence, except for us using it as a way to announce the upcoming open forums. But we're also sharing that across many system listservs that you all are already an active participant in. So 

In my opinion, the ctcLink accessibility email list serve is not really serving a useful function. And I don't think we've had any new members join that email listserv in a while. So I am proposing that we just remove it because it's not serving any sort of function, and that you all are still going to receive announcements about our open forums across various listservs that you participate in. 

We also continue to publish our slide deck, our recording, updated VPAT information, et cetera on the State Board website. So that information has been and continues to be available through our website. And there's multiple ways to get in touch around ctcLink accessibility, whether it's the web form for emailing our teams directly. 

So I just wanted to share that. I know it's a small group today, but if there's anyone who has any major issues with us from taking that listserv away, go ahead and say that now. Or you could email me, I suppose, too. But if there are any major objections, I think we're going to move forward and eliminate this email listserv. Seeing some thumbs up. Cool. 

VICKI WALTON: Monica, this is Vicki. I'm wondering if we should wait till there's more people or send a notice out on the listserv, saying that this is what we plan to do. 

MONICA OLSSON: Yeah, I can do that. And then if anyone on the email listserv is like, wait, no, this is a bad idea, they can say that. 

VICKI WALTON: Yeah. 

MONICA OLSSON: But it's a largely defunct email list. 

VICKI WALTON: Extra emails for me. 

MONICA OLSSON: Yeah. We can probably move on to the next item. So we had a college member write in a question that's a broader accessibility question than just ctcLink accessibility conformance. But we did want to provide some response in conversation during today's meeting. 

And the question is, what is the best way to complete a software audit? Do you need to do manual testing, or will a VPAT review be enough? Do we have a standard format or form for remediation plans? So I've pulled together some responses on slide 6 here, which I'm going to go through now. 

And I will also mention some previous training and resources over the last few years that have been made available to the colleges by State Board. We've had a couple of trainings with guest speakers from the University of Washington about how to read, review a VPAT. And I can send-- resend those materials to the accessibility coordinator list if you're already on that email list. And if you're not and you want those materials, just let me know, and I can send them to you. 

WebAIM, which is a nationally recognized web accessibility organization, has provided several trainings to the accessibility coordinators and another group, a couple other groups about accessibility procurement best practices and process. So again, those materials I'm happy to share with folks at colleges so that you can take that information and use it in a way that makes sense for your internal processes and what's possible. 

So with that, I also want to recognize that across our system, IT purchasing is a largely decentralized decision-making process. So the State Board is managing purchase of a system-level tool, so something that is going to be either made available and optional for all colleges to use or is mandatory for all colleges to use. 

We've done a lot of work, Vicki and I and others at the State Board, to improve our own internal process around how we review and audit for accessibility from the beginning of whatever tool it is we're looking at to purchase for the system, including contract assurances. Vicki's been largely helpful in performing manual testing and testing using automated tools. And Josh has done that with ctcLink application and other things as well. 

The State Board, we currently just do not have the infrastructure or staffing really to test or audit various tools or applications that colleges are purchasing for their own use that are outside system level or cooperative purchasing agreements. 

So those are a couple of things I wanted to acknowledge. In a minute or two, I'd like to invite Vicki and Josh to share a little bit about their own testing workflows. But the other thing I want to say is that accessibility testing and evaluation is going to and has to look different at each college because purchasing is so decentralized and staffing and bandwidth to do this work just looks different in all of our colleges. 

And in our trainings and conversations around VPAT review and procurement accessibility best practices, there's been significant conversation that sometimes manual testing is not possible for all purchases. So some risk assessment conversation may need to take place where you reserve a manual audit for your highest touchpoint or most public applications. 

And that really doing a thorough investigation of the vendor's VPAT, maybe asking them to provide you not only their accessibility statement in VPAT, but with an accessibility-focused product demo, et cetera, is going to be key to reviewing something for accessibility before you decide to use it if you don't have the staffing or bandwidth to actually go in and do manual testing. 

JOSH GIHA: And if I may add to that point, especially in the parts of the VPATs where they say "supports with exceptions," those would be particular items to highlight and pay attention, too. You might want to do manual testing on those areas. 

That's usually when-- if we do get VPAT, usually I'm much later in the process, and it's like, we already have this product. Now go fix it. But if I am fortunate enough to look at a VPAT, I always pay attention to the our supports with exceptions and then see why they're saying that specifically, and what is the exception for it? 

MONICA OLSSON: Yeah, that's a great comment. And I'm glad of some folks from CATO are here because I also wanted to share that CATO, which is the Committee for Accessible Technology Oversight, they're working on, and it's looking so good. They're working on basically sort of a guiding or best practices document for accessible IT purchasing or procurement. 

And that's going to be a resource that's published for all colleges to use with the understanding that it might be referenced and used differently across the colleges. In March, we have some folks from Portland State University presenting to CATO about their current process. 

And they have actually a rubric and grading tool developed when they do VPAT review and conversation with vendors, so like a scoring rubric that helps them determine level of risk, and then that level of risk helps them determine, do we move forward with this purchase? Yes or no? 

If we're moving forward and we know it's pretty risky, what are the additional measures we need to make sure in place, whether it's contract assurances from the vendor saying that they know they're responsible for accessibility, or whether it's making sure your college is ready to create an alternative access plan for those who have to use the tool, but may not be able to use its full functionality, if the decision is to move forward with the purchase? 

So my hope is that after we have that conversation and presentation with Portland State, that we're going to be able to take their scoring rubric and include that in our guide, because that'll be a really, I think, nice tool for college accessibility IT coordinators and accessibility teams to use. Agnes, you're on the call. Is there anything you want to add from the CATO side? 

AGNES FIGUEROA: I would only state that after the March training or meeting with Portland, as CATO, we'll go back to fine-tune and tweak based on what we learn from Portland folks. And then we'll be able to publish through the system the recommendations or guidelines that we're working on. 

MONICA OLSSON: I think one of the trickiest issues that we're all sitting in the same boat struggling to find a solution for, State Board included, and certainly our colleges, is there are many different tools that may be in use for particularly like education technologies or things that are put into Canvas through LTI by faculty for students to engage with as part of their classroom experience, that sidestep the procurement process because they are free or there's no contract required. 

So when that happens, a lot of things are sneaking through the back door, so to speak, because there's no formal request and review process initiated ever. And I wish I had an answer to that. And in all of my conversations with other colleges and universities, bigger and smaller than our system, everyone is kind of trying to figure that out. 

So I don't have a perfect solution to present to you all, except that I think part of the training that faculty probably need to be receiving at their colleges or conversations they need to be having with their accessibility IT coordinators and their disability offices is that when they're selecting these tools, even if there's no exchange of money, thinking about, can someone who is blind or relying on assistive technology use this or not is still required. 

So perhaps there needs to be a process for faculty to initiate a request for help at looking at something. The final thing I'll say, and then we can open it up to conversation or question, is probably a year ago at this point, I pulled some reports from Canvas with the help of some college folks that looked at all the different edtech tools that are embedded, or LTI-- 

"Embedded" is not the right word-- but brought into Canvas by faculty for students to engage with and across all of our colleges. And the State Board is largely not involved in these decisions. We're not selecting these tools or supporting them in any way. And there's over 2,000 different tools across our system. 

So thinking about how to address that, it's a question of bandwidth and resources for the State Board as well. So we whittled it down to the top 10 big player vendors that were in that report, so McGraw-Hill, Cengage, Pearson. And from there, we then went in further and were like, from those big vendors, what products are the most commonly used in this massive Excel spreadsheet? And from there, we whittled it down even further. 

And right now, where this project stands is the State Board has entered into a contract agreement with Deque. And Deque is going to be performing some accessibility audit, specifically right now on McGraw-Hill, some McGraw-Hill products, so McGraw-Hill Connect and the ALEKS math platform. 

Further testing is TBD on budget, et cetera. But we took that information from Canvas support and drilled it down. And I don't know if folks are aware that there's over 2,000 different tools being used across our 34 colleges. And it's largely been decentralized. So State Board is trying to help gather information for some key products from that report. But being able to do that for 2,000 items is not within our capacity right now. I hope this helps a little bit. 

VICKI WALTON: I just wanted to say-- this is Vicki, that in that procurement guide there, we tried to construct it where, OK, if you have somebody that can do manual testing, you can follow this avenue. But we also included if you don't have somebody that can do accessibility testing, how to look at the VPAT. 

And I just want to say that VPATs are not always correct. Sometimes the accessibility person isn't the one that's creating the VPAT. So there are some key features to look for on the VPAT. And then there's nothing that says that you can't reach out to the vendor and have them talk more about their VPAT, especially like Josh said, with exceptions, and have a demo, have them do an accessibility demo so you can see firsthand what the product looks like. And if they can't do that, then that's a sure sign that they're either hiding something or their platform is not accessible. 

MONICA OLSSON: We did that with Docusign several years ago because the State Board was needing to look at an e-signature solution. And we said, OK, we want you to jump on the Zoom call with us and using your keyboard only that-- we weren't asking them to necessarily turn on a screen reader-- but using your keyboard only, can you upload a form at Docusign and pretend you're someone who needs to read this form and sign it and send, because that's what you do with Docusign? 

Can you do that using your keyboard? And talk us through what you're doing as you're doing it. And they did it. They rose to the challenge. It wasn't perfect, but it was very revealing. And to put the vendor in the hot seat, I think is the best advice I have right now that it's not sustainable for colleges to put themselves in a testing service for vendors, where you you're doing all of this testing for free for these companies that are selling us products. 

So we do need to cross our t's and dot our i's and do review and investigation. But finding ways in that process to ask critical questions of the vendor, put them in a demonstration hot seat, ask for them to put things in writing, that's part of your assurance as well. 

AUDIENCE: Hey, Monica, one of-- where I get really stuck, too, is in our student services side, there are several financial aid portals that are being used that's under Department of Education. They're not a top priority for us right now, but there are some that-- over 100 of our students are using. 

So that one I would like to focus on a little bit more. But it is really difficult, almost impossible, to even get information from Department of Education. So I was wondering, has State Board, since these are portals that we have to use, has there been any testing done, or can we just cross this off of our list? 

MONICA OLSSON: That's a good question. I'm not familiar with the portals that you're referring to financially. It's not my world. So the web pages that students are logging into and using are developed by Department of Education? Is that what you're saying? 

AUDIENCE: Yeah. So I can see about a 15 at tech our financial aid office is using. Some are very specific for veteran students. Some is for all financial aid student recipients. So it's not largely like thousands of users. But when we have over 100 users, I put that a little bit more of a priority to see, but it's not really an option to not use these third-party sites either. 

MONICA OLSSON: Yeah, especially since they're coming from the government. 

AUDIENCE: Yeah. 

MONICA OLSSON: Well, I'll say, I hope that because their application is developed by a federal government that they would be designing those accessibly because they are also writing the regulations for web and mobile accessibility. I know that we can't rest our laurels on that. 

I don't think the State Board has done any sort of our own audit of those pages. However, I can give you contact information for the Digital Accessibility team lead, sorry. So a woman named Mary Lou Mobley leads the digital accessibility team for Office for Civil Rights with the Department of Education. So she might have information about those products. 

She's not in financial aid. It's that'd be a different area of Department of Education. But her team is the digital accessibility team. So we could pass this question to her if you'd like. I would just need a list of the portals or applications from you, how many students it's impacting, and what your specific questions are. But I can share that with this woman if you think that would be helpful. 

AUDIENCE: Yeah, that would be great. I will send you an email of that information. 

MONICA OLSSON: Yeah. And Mary Lou is awesome. She's an attorney. Yeah, if she can give us more information, she will. 

JOSH GIHA: Padma, I'm sorry to put you on the spot, but I just wanted to give you an opportunity as well to add any commentary. Padma's the other developer on our team that does a lot of accessibility work. 

PADMA: I don't have any comment, Josh. Thanks. 

CHRISTOPHER SORAN: Sounds good. 

MONICA OLSSON: I think we probably could move-- yep. 

CHRISTOPHER SORAN: Just waiting on some bug fixes to come our way, future updates. Cool, we'll put information once we get rolling on those. And thanks for submitting some meeting topics and continue to do so. We'll get those on the agenda. So this is-- we've got our web page. And we'll be meeting here same time next month. 

MONICA OLSSON: Yep, March 10. And then hopefully at that meeting we'll have some updates from the Okta team about their remediation plan. And I think there was another college submission for topic request. So we'll add that to the March 10 meeting as well. 

And then, if you all want the materials that I mentioned, the training materials, how to read a VPAT, the procurement training materials, reach out to me, and I'll make sure we get those to you. And then Crystal, follow up with me directly about the financial aid web applications. And we will ask the Digital Accessibility team at Department of Ed for feedback. Thanks, everybody. 

CHRISTOPHER SORAN: Appreciate your time. 

VICKI WALTON: Thank you. 

PADMA: Thank you. 

MONICA OLSSON: Bye-bye.