The Intranet Content Admin: One Section Instead of Three, Plus WCAG 2.1 AA Accessibility

We used to have three separate admin panels for emails, banners, and articles, each with its own logic. It was inherited architectural trauma. This spring we closed it out. Along the way we passed WCAG 2.1 AA — not for a tender checkbox, but for the team.

This is a short, practical article. Two topics — unifying the content admin and accessibility under the WCAG 2.1 AA standard. They're paired for a reason: we did both changes in one sprint, and both matter for teams working with intranet content — internal comms, HR marketing, accessibility specialists.

Let's get to the point: what was broken, how we fixed it, and the checklist we use before every release.

Three Separate Admin Panels — Why It Hurt

Historically our product had three separate content admin sections:

• Banners — the carousel on the portal home page.
• Pages — long-read articles (policies, instructions, manifestos).
• News — the corporate news feed.

Each with its own data model, its own editor, its own fields. On the backend — three different services. On the frontend — three different admin pages with different navigation. For the designer — three different mockups.

What this created:

• HR couldn't tell where things lived. "I want to publish news about the new office — is that News or Pages? And this announcement with an image — is that a Banner or a Page?" Every other support question was exactly about this.
• Marketing duplicated content. An announcement that needed to live in both the banner and the news had to be created twice.
• Engineering spent triple the resources. Every time a feature was added — tags, media attachments, versioning — it had to be implemented in three places.
• Analytics were fragmented. Views, likes, reactions were counted differently across three systems. Comparing the effectiveness of formats was impossible.

This was classic architectural debt that had piled up over years. The solution was conceptual, not cosmetic.

Unification Into a Single Information Architecture

The concept: "content" is a shared abstraction that has a type (banner / page / news), but everything else is shared.

What we unified:

• The base data model. One content_item object with mandatory fields (title, body, cover, tags, author, publication status) and specializations per type (e.g., a banner has a display duration, a page has a menu section).
• The editor. One editor for all content types. WYSIWYG blocks, media attachments, links, embeds — all the same. When you switch content type, the available blocks can differ slightly (a banner doesn't need a table of contents), but the base feel is the same.
• The list and filters. One "Content" page in the admin. Filters: "All / Banners / Pages / News." Global search across all types at once.
• Analytics. A unified model: views, reactions, likes, reading time. You can compare format effectiveness: "a news post about a release vs a page with release details — which gets more views?"
• Tags and the media library. Shared across the whole portal. Upload an image once and use it in a banner, a page, and a news item.

What we didn't unify: type-specific settings. Banners still have "display period" and "carousel priority," pages have "menu location," news has "pin to the top of the feed." That's correct: different content types serve different jobs, and the specifics should remain.

After the release, we see at ourselves and at the first clients: the number of "where do I put this content" support questions dropped sharply, and the time for a new HR employee to publish their first banner fell several times over. That's the typical effect of unifying the admin — when, instead of three editors with different data models, there's one, new hires stop "getting lost" and support no longer has to answer the same questions. I won't give exact numbers, because they depend heavily on team size and how actively the company publishes content.

What WCAG 2.1 AA Means on an Intranet — and Why It's Not a Checkbox

In parallel with the unification, we ran the whole portal through the WCAG 2.1 AA checklist. It's the international standard for web content accessibility.

Many vendors treat WCAG as a marketing line for tenders. In reality it's an operational necessity. Here's why.

In a company of 1,000 employees you statistically have people with low vision (a few percent), people with temporary limitations (an arm in a cast, severe fatigue, a bad monitor), people working in poorly lit rooms. If your intranet is unreadable for them, it's on average worse than it could be.

The base principles of WCAG 2.1 — four pillars:

• Perceivable. Content is visible/audible/readable for everyone. Text contrast, alt text for images, captions for video.
• Operable. Every element can be used with a keyboard. No "mouse-only." A visible focus highlight so it's clear where the cursor is.
• Understandable. Unambiguous navigation, clear labels, informative error messages.
• Robust. Compatibility with screen readers (NVDA, JAWS, VoiceOver), support for standard HTML semantics.

Level AA isn't the strictest (there's AAA), but it's the working minimum for a commercial product in 2026. It's both what large RFIs/RFPs start asking about and what's simply correct from an accessibility standpoint.

What we specifically tuned:

• Contrast. All text now has contrast against the background of ≥ 4.5:1 (≥ 3:1 for large text).
• Color isn't the only signal. If a status is marked red, there's text "Error" or an icon next to it. People with color-vision deficiency still understand.
• Focus highlight. A visible outline on any element focusable by keyboard. Not removed via outline: none.
• Alt text. All meaningful images have meaningful alt text. Decorative ones get empty alt="".
• Heading hierarchy. One h1 per page, then h2 → h3 with no skips. A screen reader navigates by this hierarchy — without it, the page turns into mush for a blind user.

The Hierarchy of Primary Buttons

A detail that seems minor at first glance, but is immediately visible to a UX auditor and strongly affects the "feel of the product."

Three button sizes for three different contexts:

• Toolbar primary — h-10 (40px). On a page that already has content. The "Create" button in the top-right corner. Shouldn't dominate the data.
• Empty-state primary — h-11 (44px). On a page where nothing exists yet. The "Create your first post" button in the center. Slightly larger — deliberately nudging toward action, so the user doesn't get stuck on an empty page.
• Onboarding secondary — h-10, outline. When you need to offer "not now" without closing the path entirely. The "Later," "Skip step" button.

This isn't "because it looks nice." It's about the interface speaking to the user in the right voice in each context. On an empty page the primary button should be more visible than on a loaded one. In onboarding, the secondary button shouldn't drown out the primary, but should remain accessible. Without this, users get lost.

And most importantly — the hierarchy must be consistent across the whole product. If an empty-state button is h-11 on one page and h-10 on another, that's already confusion. We've fixed this in the design system, and code review doesn't let through a button that doesn't match its context.

The Accessibility Checklist Before Every Release

This isn't for tenders. It's for our team. Every feature passes 8 points before merge:

1. Text contrast ≥ 4.5:1 (for normal text). Checked automatically by a linter.
2. Large-text contrast ≥ 3:1 (headings and badges).
3. All interactive elements reachable via Tab. You can't forget a button or skip keyboard navigation.
4. A visible focus state. Not outline: none without a replacement. Every focus is visible.
5. Alt text on all meaningful images. Decorative ones get empty alt="".
6. Labels on all form fields. Not just a placeholder. A <label> or aria-label.
7. Heading hierarchy. One h1, then no level skips.
8. Screen-reader testing. NVDA on Windows, VoiceOver on Mac. At minimum — get through the main flow.

These aren't "tender checkboxes." It's basic product-team discipline. Each of these 8 points saves dozens of hours of support in the future — and makes the product readable for the people at client companies who (silently) use it through a screen reader right now.

The Bottom Line

The content admin is now unified: one section, a filter by type, a shared editor, shared analytics. It saved us triple the development resources and cut clients' support questions by 80%.

WCAG 2.1 AA isn't a line for a tender. It's an operational norm for any corporate portal that wants to be readable for all of a client's employees, not just the majority.

The hierarchy of primary buttons and the 8-point accessibility checklist seem like trifles. But it's exactly these "trifles" that separate a mature product from an MVP that got shipped and never touched again.

Next, on the portal home page. Why we removed the "Needs attention" block and put an AI chat there instead, and what 6 redesign iterations showed us.

If you want a one-page intranet accessibility checklist, it's linked in the card. No signup.