MESCIUS states that Wijmo 2026 v1 and v2 support the applicable WCAG 2.2 AA requirements referenced in its accessibility materials and release communications. That is a vendor statement about product support, not a claim that every application built with the grid is automatically accessible, and not a certification of conformance for any specific implementation.
For UI engineering teams, the most useful approach is a small, repeatable regression check in your own app. Use real page structure, dummy order data, and the same build, browser, and assistive technology setup your users actually encounter. A single successful pass is evidence that one path worked in that moment; it is not accessibility certification.
Start with a simple keyboard task
Begin at a focusable filter or similar control before the grid. Move into the grid with the keyboard, then identify one target column and attempt to widen it using the configured or documented key combination if your implementation supports that behavior. The release notes describe keyboard resizing and dragging features, but the vendor does not say that every configuration enables them in the same way.
For example, use an Order Status column with dummy rows. Before starting, write down the expected sequence: focus moves from the filter into the grid, the documented resize action widens Order Status, and the next page control remains reachable by keyboard. If focus disappears or moves to an unexpected control, record where it happened. After resizing, confirm neighboring data remains readable.
When the task is done, continue keyboard navigation out of the grid until you reach the next page control or adjacent interactive element. That exit path matters because accessibility problems often appear not only inside a widget, but at the boundary between the widget and the surrounding page.
Separate visual focus checks from screen reader checks
A screen reader review should be treated as a separate validation step, using a known browser and assistive technology combination that your team supports. Record the browser version, screen reader version, operating system, and any relevant app state before you test. If your interface includes a custom toolbar, modal dialog, or another focus-trapping component, verify that focus returns to the expected place after the interaction ends.
This distinction matters because a grid can appear keyboard-operable while still announcing poorly, or announce well while leaving focus in the wrong place after a dialog closes. The accessibility documentation emphasizes using supported tools and patterns, but it does not remove the need to verify your own implementation details.
What to compare in a regression check
- Observed versus expected keyboard path from the filter into the grid and back out again
- Whether the target column changes width using the documented interaction supported by your configuration
- Whether focus remains visible and usable throughout the interaction
- Whether neighboring data stays legible after the resize
- Whether screen reader labels and announcements match the control and state being tested
- Whether focus returns to the right element after any custom toolbar or dialog interaction
If your recorded outcome matches the expected behavior, you have a useful regression signal for that scenario. If it does not, capture the exact control, browser, assistive technology, and version details so the issue can be reproduced and triaged efficiently.
Primary sources
MESCIUS press release: Wijmo achieves WCAG 2.2 AA compliance in 2026 v1 and v2 releases
Wijmo accessibility documentation
