An accessibility-first CMS, shaped for higher ed.
Inclusive CMS gives editors a clear, focused workspace and publishes fast static HTML behind the scenes. No plugin stack. No fragile templates. Just inclusive, high-performing pages out of the box.
Built like a static site. Edited like a CMS.
Most CMSes put the editor, the database, and your homepage on the same public web server. Inclusive CMS doesn't.
Static and quiet.
- Pre-built HTML, served from the edge
- Cached, fast, cheap to scale
- Nothing dynamic to probe or exploit
- No application surface where the world can see it
Behind SSO.
- Editor, database, and workflows
- Media library with AI-drafted alt text you approve or rewrite
- Approvals, scheduling, and publishing
- Visible only to your team — never to bots or scrapers
A public site that's fast and quiet. An editing surface bots and scrapers never see.
Edit fast. Publish clean. Stay accessible.
Pages are simple sections. Guidance happens as you work. Publishing emits fast, secure static HTML. No plugins, no fragile templates.
See how it works →
Everything a campus site needs, built in.
We focused on the elements that show up over and over on higher education sites and gave them proper tools, instead of leaving them to plugins.
Checked as you write
Missing image descriptions, text with low contrast, and other accessibility issues are flagged while editors are still on the page, so problems get fixed before visitors see them.
Your whole site at a glance
A clear map of every page, news post, faculty directory, and menu, organized the way universities actually work rather than bolted together from plugins.
Click, edit, autosave
Edit text right where it appears on the page. Autosave, drag and drop ordering, and pinned shortcuts. Get in, get out, get back to your students.
Easy to find, easy to read
AI drafts image descriptions and tags; an editor approves or rewrites them in one click, so photos end up searchable and genuinely useful to screen reader users. Images resize automatically for every screen size.
Old content, called out
Review reminders and automatic flags catch outdated pages before your visitors do, or before complaints land in your inbox.
Hard to break into
Your public site is plain web pages, with no live database and no plugins exposed to the internet. Almost nothing for attackers to target.
A workspace that looks as good as it feels to use.
Sitemap
A clean, structured view of the entire site. Pinned pages highlight priority content.
Page editor
Section based editing. Inline text, autosave, responsive previews, distractions out.
Media library
Fast search across thousands of files. AI suggestions for alt text and descriptions.
From sign-in to published page in three clear steps.
Find your page
Use search, pinned pages, or the site map. Even large, distributed sites stay easy to navigate.
Edit with confidence
Edit in structured sections that match real layouts. Autosave, responsive previews, accessibility guidance throughout.
QA and publish
The QA assistant flags accessibility needs and missing alt text. When everything looks right, publish clean static HTML.
“There are so many options, so I can always find exactly what I need for each bit of content added to the site."
The compliance window just got a little wider.
On April 20, 2026, the DOJ extended Title II web accessibility deadlines by one year. More room to plan, same standard to meet.
WCAG 2.1 AA is the legal floor. Inclusive CMS is built to WCAG 2.2 AA, so you clear the bar with margin and stay current as the standard evolves.
Source: DOJ Interim Final Rule, 28 CFR Part 35, effective April 20, 2026. Informational, not legal advice.
How early-stage is this, really? +
We launched with our first university partner, LSU Alexandria, during the 2025–26 academic year. We are deliberately growing one to two institutions at a time so each rollout gets the attention it deserves. If you want to be one of the next handful of campuses, we want to talk.
How does Inclusive CMS approach WCAG? +
The legal floor under ADA Title II is WCAG 2.1 Level AA. We build the platform and default sections to WCAG 2.2 AA, a slightly newer standard, so you have margin against the rule and stay aligned as guidelines evolve. The editor surfaces guidance for authors as they work: heading order, contrast, alt text, keyboard navigation. Compliance ultimately depends on the content you publish; we make it as easy as possible to get there.
When is the ADA Title II deadline for our institution? +
On April 20, 2026, the DOJ extended both deadlines by one year via Interim Final Rule. The threshold is the population of the public entity your institution belongs to (the state, or the city, parish, or county it serves), not student headcount. Public entities serving populations of 50,000 or more now have until April 26, 2027. Public entities under 50,000 and special districts have until April 26, 2028. Which reading applies to a given campus is still being argued, but for public colleges and universities it rarely changes the answer: a state-level reading puts essentially every public institution in the 50,000+ bucket, and a local reading catches most of them anyway: LSUA (Rapides Parish), LSU-Eunice (St. Landry Parish), LSU-Shreveport (Caddo Parish), San Jacinto College, Lee College, and Lone Star College all sit in parishes or counties well above 50,000. Either way, the date is April 26, 2027. The standard remains WCAG 2.1 Level AA. Migrating now still gives most teams 12+ months of runway.
How is this different from WordPress, Drupal, or Sitefinity? +
Those platforms lean on plugins, themes, or framework-heavy templates. Inclusive CMS bakes accessibility, responsive and mobile-friendly layouts, light and dark modes, structure, and security into the core, and publishes a static HTML public site that is isolated from the editor. There is no plugin stack to keep current.
What does working together actually look like? +
This is less a CMS migration and more a rebuild of your website around accessibility. We do not just port your existing pages and call them compliant. We work with you to revisit content, structure, and user flows so the site is genuinely usable: clear headings, plain-language copy, sensible navigation, and pages that hold up to keyboard and screen reader use. We have done one of these, with LSU Alexandria, who came off Sitefinity. You can judge the result yourself at lsua.edu (opens in a new tab). We are happy to talk through your stack, your content model, and what a rebuild together would look like. We are not going to pretend we have done dozens of these. We have done one, well.
Where is the public site hosted? +
The static output can be hosted anywhere: your own infrastructure, a CDN, or our managed hosting. The editor runs on a separate, isolated environment.
What about authentication for editors? +
Today we connect to Azure AD (Microsoft Entra ID), which is what our launch partner uses. The architecture is provider-agnostic, so adding other IdPs (Okta, Google Workspace, Shibboleth, or any SAML or OIDC provider) is straightforward when an institution needs it. Tell us what you use and we will scope it together.
How does pricing work? +
Two parts: a one-time setup and implementation fee, plus an annual support and maintenance subscription. Both scale with the size and complexity of your site, and we can take on full maintenance if you'd rather your team stay focused elsewhere. Reach out and we'll put real numbers against your scope.
30 minutes, your calendar.
Tell us when works and we'll confirm by email, usually within a school day. We prep the demo using a page from your current site.
You asked for .
Nothing is on the calendar yet. We'll check the time against ours and email you an invite, usually within a school day. If something changed on your end, pick a new time below.