Accessibility

Wijmo controls include built-in accessibility features that help developers create applications for people who use keyboards, screen readers, and other assistive technologies.

Wijmo's main controls, including FlexGrid and Input controls, support the applicable requirements of WCAG 2.2 Level AA. Chart and OLAP controls also provide support for applicable requirements of WCAG 2.0, 2.1, and 2.2 Level AA.

Wijmo accessibility support is provided at the control level. The accessibility of a complete application also depends on its content, labels, control configuration, custom templates, CSS, and application-defined interactions. Control support alone does not guarantee that an application conforms to every WCAG requirement.

Wijmo uses standard WAI-ARIA semantics where appropriate. Use tools such as Axe DevTools and screen readers such as NVDA to test complete application workflows.

Built-in Accessibility Support

Wijmo controls can provide the following accessibility features:

• WAI-ARIA roles, accessible names, descriptions, and states.

• State information such as selected, checked, expanded, collapsed, pressed, and disabled.

• Keyboard access to supported control operations.

• Visible focus indicators for keyboard users.

• Status feedback for supported operations that change content without moving focus.

• Styles intended to support high-contrast and forced-colors environments.

Basic accessibility semantics are provided automatically in supported controls. Some workflows require an accessible name or control-specific configuration. For example, PivotGrid headers must be included in headersFocusability before users can focus those headers and operate grouped data from the keyboard.

Control-Specific Accessibility

Accessibility behavior varies by control. The following sections summarize the main control families and link to detailed topics where available.

FlexGrid

FlexGrid provides grid semantics and keyboard support for navigating, selecting, and editing cells. It also supports keyboard interaction with grouping, sorting, filtering, resizing, and other grid operations when those features are enabled.

The Accessibility Extender topic describes FlexGrid keyboard behavior and shows how to announce application-specific operations, such as completed sorting or filtering.

Input Controls

Input controls expose accessible names, values, and states and provide keyboard behavior appropriate to each control.

Provide a visible label for an input whenever possible. If a visible label is unavailable, use an appropriate HTML or ARIA labeling technique to give the control a meaningful accessible name.

For control-specific keyboard behavior, see:

• Calendar

• ListBox

• Menu

Navigation Controls

Navigation controls expose their structure, current state, and available actions through WAI-ARIA semantics and keyboard interaction.

For example, TabPanel implements the WAI-ARIA tabs pattern. Its autoSwitch property determines whether moving focus between tabs also selects the focused tab. See Accessibility in TabPanel.

Chart Controls

Wijmo Chart controls provide accessibility support for chart names, keyboard focus, screen-reader semantics, and supported chart interactions.

The available accessibility behavior depends on the chart type and its configuration. Applications should provide a meaningful chart name and an equivalent text or data representation when important information is available only through the chart.

For chart-specific configuration, keyboard behavior, supported regions, and limitations, see Chart Accessibility.

OLAP Controls

Wijmo OLAP controls provide accessibility support for PivotPanel, PivotGrid, PivotChart, and Slicer.

These controls expose field areas, grid and chart content, filter options, keyboard operations, and relevant state information to assistive technologies. Some workflows require control-specific configuration. For example, PivotGrid headers must be made focusable before users can operate grouped rows or columns from the keyboard.

For detailed OLAP configuration, keyboard workflows, and limitations, see OLAP Accessibility.

Application-Specific Accessibility

Some accessibility requirements depend on the application and cannot be provided or inferred by a control alone.

Providing an Accessible Name

When a control does not have a meaningful visible label, provide an accessible name that describes its purpose.

For example, assign an accessible name to a chart:

const chart = new wijmo.chart.FlexChart('#chart', {
    ariaLabel: 'Quarterly sales by region'
});

Use a name that identifies the purpose or content of the control. Avoid generic names such as Chart, Control, or Input.

Adding an autocomplete Attribute

The HTML autocomplete attribute identifies the expected purpose of an input and allows browsers or other user agents to provide appropriate assistance.

For example, add autocomplete="email" to the input element used by a ComboBox:

// Get the input element from the ComboBox.
const input = combobox.inputElement;

// Identify the expected input purpose.
input.setAttribute('autocomplete', 'email');

See the ComboBox Class API Reference.

Announcing Dynamic Status Messages

Status messages notify users about important changes in content. Screen readers can announce these messages when they are exposed through a live region.

Because the content and timing depend on the application workflow, the following example demonstrates one possible implementation. In this example, the screen reader announces Current value: {value} when the ComboBox text changes.

Create a status element:

<div
    id="valueAnnouncer"
    role="status"
    aria-live="polite"
    aria-atomic="true">
</div>

Hide the element visually without removing it from the accessibility tree:

#valueAnnouncer {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip-path: inset(50%);
    white-space: nowrap;
    border: 0;
}

Update the status when the ComboBox value changes:

const announcer = document.getElementById('valueAnnouncer');

combobox.textChanged.addHandler((sender) => {
    announcer.textContent = `Current value: ${sender.text}`;
});

Use live regions only for important updates. Announcing every routine change can make an application difficult to use with a screen reader.

Application Responsibilities

When using Wijmo controls in an accessible application:

• Provide meaningful visible labels and accessible names.

• Maintain a logical focus order and reading order.

• Preserve visible focus when applying custom styles.

• Manage focus after validation, filtering, navigation, dialogs, and asynchronous updates.

• Associate instructions and validation messages with the relevant controls.

• Do not use color as the only way to communicate information.

• Provide text or data alternatives for important visual information.

• Preserve accessibility semantics when customizing control templates.

• Provide keyboard alternatives for application-defined pointer and drag operations.

• Verify contrast after customizing themes, palettes, templates, or chart colors.

• Test custom CSS, dynamically generated content, and application overlays.

• Test at the zoom levels required by the application.

• Test high-contrast and forced-colors modes after customizing styles.

• Verify that focused content is not obscured by fixed or overlay content.

• Verify the target size of interactive elements when applicable.

Wijmo control support does not by itself guarantee that the complete application conforms to every WCAG requirement.

Screen Reader and Browser Behavior

Wijmo exposes control roles, names, values, relationships, and states through the browser accessibility tree. Screen-reader output can vary depending on the browser, operating system, screen reader, control configuration, and application markup.

Test complete workflows with the browsers, operating systems, and assistive technologies supported by your project. Automated tools such as Axe DevTools can identify some accessibility issues, but they do not replace keyboard or screen-reader testing.