Keyboard and VoiceOver support in Censhare Web: WCAG 2.1 Level A-related evaluation

About WCAG 2.1 Level A: supported flows in Censhare

This page describes accessibility support for selected Censhare Web workflows. It explains what interaction types are supported and lists the flows you can use with keyboard navigation and a screen reader. The page does not claim that the complete Censhare Web conforms to WCAG 2.1 Level A.

Overview about the test scope:

Supported flows

The following user flows were tested with keyboard navigation and with VoiceOver as a screen reader:

Mapping against WCAG:

Interaction types

Censhare supports the following interaction types for the flows listed above:

• Keyboard navigation: In the listed workflows and tested environments, the tested interactive elements were reachable and operable with the keyboard (Tab, Enter, Space, and arrow keys). The content editor and other documented limitations are exceptions.

• Screen reader via VoiceOver: For the tested interactions, VoiceOver announces the supported flows, and labels, roles, and states are exposed to assistive technology. Some screen reader limitations remain, as described in the accessibility testing and status section.

Release 2026.1 scope and compliance status

The following limitations apply to the current release:

Background: about WCAG 2.1 Level A

WCAG 2.1 is an international web accessibility standard published by the World Wide Web Consortium (W3C). It defines how to make web content usable for people with disabilities. The standard is built on four principles: content must be perceivable, operable, understandable, and robust. It is organized into three conformance levels: Level A (minimum), Level AA (standard), and Level AAA (enhanced).

Level A includes 30 success criteria. Key requirements cover text alternatives for images and icons, full keyboard access, no keyboard traps, a logical focus order, descriptive page titles, and correct names and roles for all interface components. These criteria ensure that assistive technologies such as screen readers can interpret and announce content correctly.

Censhare is working toward evaluating all flows against the applicable WCAG 2.1 Level A success criteria. The flows listed in this article are the first set of interactions included in the current accessibility testing scope. Additional flows and criteria are evaluated in future releases.

WCAG 2.1 Level A: accessibility testing and status

This article describes how Censhare tested the Censhare Web for WCAG 2.1 Level A accessibility. It explains what was tested, what the testing found, and which limitations remain. Read this article to understand the evidence behind the supported flows and the current status.

About the accessibility testing

Censhare tested the eleven core user flows listed in the Supported flows section of this article. The testing focused on keyboard access and screen-reader operation for each flow. It was not, by itself, a complete evaluation of every WCAG 2.1 Level A success criterion. It also recorded a first, dated result so that later releases can be compared against it.

The first result was recorded in June 2026. Improvements followed during release 2026.1.0. This article reflects that work.

How Censhare tested accessibility

Censhare used two kinds of testing together. Each kind finds problems that the other can miss.

• Automated checks: Established accessibility tools scanned every flow. The tools look for common problems, such as images without a text alternative or controls without a clear name.

• Manual testing: A tester operated each flow with the keyboard only and then with the VoiceOver screen reader. This step helps assess whether focus moves in a sensible order and whether the screen reader announces the tested controls.

Automated tools catch only part of the picture. Manual testing with a keyboard and a screen reader is needed to confirm that a real person can complete each flow.

Tools used

• Lighthouse 13.2.0

• axe-core 4.11.4 (tags wcag2a + wcag21a)

• Playwright

• angular-eslint (yarn lint:a11y)

Rules run:

• axe-core (Level A findings): list, listitem, aria-hidden-focus, aria-input-field-name, button-name, label, aria-prohibited-attr, link-name, image-alt, scrollable-region-focusable, html-has-lang

• Lighthouse (outside Level A, reported separately): color-contrast, heading-order, landmark-one-main, tabindex

• angular-eslint (static template pass): alt-text, label-has-associated-control, elements-content, valid-aria

What the testing found

The first measurement showed accessibility problems in every flow. Most problems came from a small number of shared components. Because these components are reused across the interface, a single fix improved many flows at once.

The most common problems have been the following.

• List structure: Some lists did not expose their structure to assistive technology. This mainly affected the asset properties list.

• Missing names: Some icon buttons and inputs had no name that a screen reader could announce.

• Missing text alternatives: Some thumbnails, icons, and preview images had no text alternative.

• Keyboard reach: Some scrollable areas could not be reached with the keyboard alone.

Censhare fixed the shared components that caused most of these problems during release 2026.1.0.

Keyboard and screen reader testing

Manual testing of keyboard access and VoiceOver announcements was completed for the eleven flows. However, this does not mean that every flow meets every applicable WCAG 2.1 Level A success criterion. The testing led to a series of improvements during release 2026.1.0:

• Asset creation: The focus now stays in the filter field while you type. The date and time selectors can be operated and closed with the keyboard. The tabs in the create dialog are reachable.

• Search: The screen reader now announces the section headings, so you know which filter you are under.

• Widgets and asset lists: Widget titles and asset actions are now announced and reachable.

• Page actions: Focus stays with the page actions after you trigger one, instead of jumping away.

• Dialogs: When a dialog closes, focus returns to the control that opened it. Nested dialog tabs are part of the keyboard order.

• Zoom and toolbar controls: The zoom controls and icon-only toolbar controls now have names that a screen reader can announce.

Automated checks against WCAG 2.1 Level A criteria

Censhare has built automated accessibility checks into the Censhare Web project. In this section, the results represent automated checks against WCAG 2.1 Level A success criteria that automated tools can detect:

• A static template check uses ESLint with the angular-eslint template rules. It flags missing text alternatives, missing form labels, empty interactive elements, and invalid ARIA.

• A runtime check uses Playwright with axe-core to scan defined page states, such as sign-in, asset detail, form controls, and the main workspace.

At present, these checks run on demand. They are not enforced in the build pipeline, so they do not automatically block regressions. Continuous integration is intended to run the checks on each build.

Remaining accessibility limitations

Some accessibility gaps remain. Censhare tracks each one for a future release:

References

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C

• WCAG 2 overview — W3C WAI

• Understanding Success Criterion 2.1.1: Keyboard — W3C WAI