Hello,
I tried looking at this topic, but what I found was from 2019. What is the current state of Open OnDemand meeting the new W3C 2.1AA standards set to be enacted in April 2026?
Thanks…
Great question. Version 4.1 will be released in about a month. We are targeting version 4.2 for late April and the primary focus of it will be digital accessibility compliance to meet those upcoming deadlines. We already have a student working on identifying gaps (if any) we need to address and plan to have a VPAT available as part of that release.
That’s great to hear. Thank you for the quick reply.
CJ
@alanc we are grateful to hear that the source code of Open OnDemand will be remediated for a few gaps we have been able to identify (happy to share our notes with you). Is there any link or resource describing the Open OnDemand remediation plan/timeline leading up to April?
We just had a team meeting earlier this week and have come up with this plan:
We just started doing a VPAT analysis ( VPAT - Information Technology Industry Council ) against the current release candidate for version 4.1. As part of that, we will produce an ACR for Open OnDemand 4.1 (and publicly release it as part of the 4.1 release scheduled for the next few weeks).
We anticipate that ACR identifying several areas that are out of compliance. For each of those, we will create a GitHub issue. These should then start showing up in our 4.2 Roadmap project which will be available here: Projects · ondemand · GitHub
We encourage anyone in the community (including yourself) that has identified any gaps already to post a GitHub issue here: GitHub · Where software is built and use the area/accessibility label to tag it. That will allow us to holistically look at all the issues we need to address before April.
1 Like
Thank you, Alan. We are happy to contribute!
1 Like
Yes please feel free to open issues on our github repository.
Before I discovered this thread, I began working on Title II compliance for OOD instance. So far, I’ve been overriding whatever default CSS colors ARC Toolkit complains about.
If it helps, I can share the CSS bits I’ve had to override so far.
Please do. Can you also clarify what Title II compliance means?
Just in case anybody else stumbles upon this thread, here’s some general background as I understand it:
Starting Apr 24th, 2026, many state/local governments will have to comply with new Federal ADA regulations requiring compliance with “WCAG 2.1, Level AA” for web content (everyone else has until Apr 2027). Some details of these regulations are at https://www.ada.gov/resources/2024-03-08-web-rule/#how-long-state-and-local-governments-have-to-comply-with-the-rule
Details of all of the WCAG requirements are at this website: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1&showtechniques=121¤tsidebar=%23col_customize#principle1 There are many dozens, and each one has extensive information with examples, techniques, tests, etc
One very common contractual way to demonstrate conformity is via the VPAT – Voluntary Product Accessibility Template (https://www.itic.org/policy/accessibility/vpat).
(Note I’ll continue to utilize VPAT here since most people use that term, but technically VPAT is the template, once you fill it out it becomes an ACR “Accessibility Conformance Report”)
The most helpful thing initially is the VPAT training presentation here: https://www.itic.org/dotAssetef76664f-277a-4139-b1e4-6409de8e80e0.ukn Some key tidbits:
-
There are 4 versions of the VPAT (WCAG, 508, EU, INT), depending on the sector (US, EU, Public, Private) – see slide 85.
-
A VPAT relates to a specific release of a software product. It’s not necessary to update the VPAT for every release, but is recommended for major updates to issue a new one.
-
While there are third party services that can do VPAT testing, it’s strongly recommended that the VPAT is completed by people involved in the software development
-
Likewise, while there is automated testing available, it’s strongly recommended that the VPAT be completed via manual testing (i.e. using a keyboard only, no mouse) and/or assistive technology testing (i.e. using a screen reader)
That’s just the abbreviated jargon that Georgia Tech decided to use for this exact effort. In the ada.gov site you linked to, it refers to “Title II of the Americans with Disabilities Act (ADA),” which established WGAG 2.1 Level AA as the standard.
Here is some CSS I’ve had to change so far. We target CSS elements that are flagged by ARC Tookit. The changes below all address insufficient color contrast.
In my snippet, I’m keeping things general by mentioning which colors needed to lightened and which needed to be darkened compared to the OOD’s default. You can see it’s generally making the background lighter and/or the text color darker. When both the background and text are altered, it’s possible you could meet the contrast threshold by changing only one or the other. It’s also very likely that someone with better knowledge of OOD’s CSS could accomplish this more concisely; I was just discovering the CSS elements myself with Chrome’s dev tools.
I can move this to the GitHub Issue when it’s posted.
/*
==================
Relevant globally
==================
*/
/* Monospaced code snippets */
code {
color: /*darker than default*/;
}
/*
========================================
Relevant to an app's batch_connect page
========================================
*/
/* The header in an app's page that shows things like "Home / My Interactive Sessions / Jupyter" */
.breadcrumb {
background-color: /*ligher than default*/;
a {
color: /*darker than default*/;
}
a:not([href]):not([class]) {
color: /*darker than default*/;
}
}
.breadcrumb-item + .breadcrumb-item::before {
color: /*darker than default*/;
}
/* Section headers in the "Interactive Apps" sidebar */
.list-group-item.header {
background-color: /*lighter than default*/;
color: /*darker than default*/;
}
Ronald: Thanks. Not sure what you mean by this? There isn’t one specific GitHub issue we are creating for all accessibility items. Rather individual issues for each item.