Kentico Accessibility Checklist 2026 | WCAG 2.1 AA & EAA Compliance
Last updated: 2026-07-18
Kentico Xperience is an enterprise digital experience platform used by mid-size and large organizations to run marketing sites, portals, and e-commerce on the .NET stack. In Kentico the accessibility of the front end is a shared responsibility: developers write the Razor view templates, widgets, and page type markup, while marketers and content editors assemble pages with the page builder, upload media, and author copy. That split is where accessibility often breaks down. A developer can ship a widget with perfect semantics, but if the editor pastes headings out of order, uploads images without filling in the media library's alternative text, or chooses a low-contrast color from a design that was never verified, the delivered page still fails WCAG. Because Kentico gives teams full control over markup, there is no template lock-in forcing good patterns, so accessibility depends on the components you build and the editorial guardrails you put in place. Custom form controls, faceted search, listing widgets, and interactive components all need correct roles, labels, and keyboard support. With the European Accessibility Act and public-sector procurement rules increasingly demanding demonstrable conformance, Kentico teams need both technically accessible templates and an editor workflow that keeps content accessible over time. This checklist covers the issues that appear most often across Kentico Xperience implementations and how to resolve them in both code and the administration interface.
Common Accessibility Issues
Editors upload images to the Kentico media library and place them via image widgets or rich text without supplying alternative text. Unless the widget template outputs an alt attribute from a required field, images render with empty or missing alt, so screen reader users lose any information the image carries.
Add a required 'alternative text' field to image widgets and page type fields, and bind it to the alt attribute in the Razor template. For decorative images, provide an explicit 'decorative' toggle that outputs alt="". Train editors to complete alt text at upload time, and audit the media library for items reused across the site without descriptions.
Kentico's page builder lets editors stack widgets and rich text freely, which often results in multiple h1 elements, skipped heading levels, or headings used purely for visual size. Screen reader users rely on a logical heading outline to navigate, and a broken hierarchy makes long enterprise pages very hard to scan.
Design widgets so the developer controls heading levels through a configurable field rather than letting editors pick sizes freely, and enforce a single h1 per page (typically the page title). Provide rich text styles that map visual size to correct semantic levels, and review the heading outline of key templates with an outline tool before launch.
Forms built with Kentico's form builder can render inputs whose labels are not programmatically associated, or whose custom form components omit the label wrapper. Placeholder-only fields and unlabeled custom controls leave screen reader users unable to determine what each field requires, and validation messages are often not linked to their fields.
Ensure every form component template renders a label element with a for attribute matching the input id, and keep labels visible rather than placeholder-only. Associate validation and help text with inputs via aria-describedby and set aria-invalid on failing fields. When building custom form components, extend Kentico's form component classes so labels and error markup are generated consistently.
Interactive widgets such as carousels, tabbed content, filterable listings, and mega menus are frequently built with div and span elements plus JavaScript click handlers. These are unreachable or inoperable by keyboard and expose no roles or states, making them unusable for keyboard and screen reader users.
Build interactive widgets on native button and a elements and follow the WAI-ARIA Authoring Practices for each pattern, implementing the expected keyboard behavior, roles, and states. For faceted search and listing widgets, ensure filters are real form controls and that results updates are announced through an ARIA live region.
Enterprise Kentico sites apply a corporate design system whose colors were often chosen for brand rather than legibility. Button text, links, form placeholders, and text over hero images frequently fall below the required 4.5:1 ratio, and because the values live in shared CSS variables, the problem repeats across every page.
Audit the site's design tokens and CSS variables against WCAG contrast requirements and adjust the accessible variants centrally so the fix propagates everywhere. Provide accessible foreground/background pairings for buttons, links, and overlays, and document them so future widgets and campaigns reuse compliant colors.
Kentico sites commonly use AJAX to update listing results, load more items, submit forms, or refresh personalized content without a page reload. These DOM changes are silent to assistive technology by default, so screen reader users are not told that results have changed, that a form succeeded, or that more content has loaded.
Wrap dynamically updated regions in an element with aria-live='polite' (or 'assertive' for critical messages) and announce the outcome, for example 'Showing 24 results'. Use aria-busy during loading, and after form submission move focus to a success or error message with an appropriate role so the change is both announced and reachable.
Kentico-Specific Tips
- Bake accessibility into your Kentico widget library: make alternative text and heading-level fields required inputs on image and content widgets so editors cannot publish a page that omits them.
- Because content editors control much of the final markup, pair accessible templates with an editorial checklist in Kentico's documentation or workflow so alt text, heading order, and link text are verified before content is approved.
- Centralize colors, focus styles, and typography in shared CSS variables or design tokens; fixing contrast and visible focus once at the token level corrects every widget and page that consumes them.
- Use Kentico's workflow and approval steps as an accessibility gate: add an approval requirement or checklist item that content passes an automated scan and a quick keyboard test before it goes live.
- Preserve a visible keyboard focus indicator across custom widgets and interactive components; enterprise design systems often strip default outlines, so add a clear focus-visible style that meets contrast requirements.
Recommended Tools
axe DevTools
A browser extension that runs automated WCAG audits against rendered Kentico pages, flagging missing alt text, unlabeled form fields, contrast failures, and ARIA problems, with guided tests for issues needing human review.
HeadingsMap
A browser extension that visualizes the heading outline of a page, making it easy to spot the skipped levels and multiple h1 elements that Kentico's flexible page builder tends to produce.
NVDA Screen Reader
A free Windows screen reader for testing Kentico forms, widgets, and dynamic listings the way an assistive technology user experiences them, surfacing missing labels, silent updates, and reading-order issues.
Further Reading
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.