Accessible interfaces, built into everyday work.

Accessibility is part of everyday usability

People use business software with keyboards, touchscreens, screen magnifiers, speech input and screen readers. They also work in bright rooms, increase text size, and reduce animation. A consistent interface helps people keep their place and understand the result of an action.

Our engineering target is the Level A and AA requirements of WCAG 2.2. The standard addresses how people perceive, operate and understand a complete page or process. A component library provides useful foundations; the finished application still needs its own validation.

Keep work moving with a keyboard

Visible focus answers a simple question: where will the next action happen? Shared controls provide focus styling, and composite widgets use their own keyboard patterns. Tab moves between controls; arrow keys move within supported menus, lists, calendars and other grouped controls. A focused control should remain understandable when a popup opens.

Dialogs need an accessible title, a reachable close action and a way back to the task that opened them. Nested popups should dismiss one layer at a time. Tooltips should be reachable through focus as well as hover, allow pointer travel onto their content, and dismiss with Escape. Keep essential instructions visible outside a tooltip.

Explore dialogs and floating surfaces, tooltips and calendar keyboard behavior.

Give every action a name and every error a next step

A placeholder disappears as soon as someone types. A visible label stays useful. Connect each field to its label, associate its help and error text, and expose invalid state when validation fails. Icon-only buttons need names that describe the action, such as Remove assignee, rather than the icon’s shape.

Errors should identify the problem in text and explain how to recover. A red border alone cannot do that. Use status messages for routine results and urgent announcements sparingly; meaningful announcements matter more than announcing every keystroke.

See inputs and forms and status and feedback for more examples. Supply translated visible labels, accessible names, instructions and errors together.

Make direct manipulation optional

Dragging a small handle is difficult for many people. A keyboard shortcut helps, but a click or tap alternative also matters. TimelineTrack exposes an Edit timeline events disclosure with commands for moving an event and adjusting either endpoint. The commands update the same controlled event values as dragging.

Short events and milestones retain larger interaction affordances inside the track. Field configurator examples also expose move actions. When you hide built-in commands or add your own drag interaction, provide an equivalent single-pointer action and validate target spacing in the final layout.

Explore the timeline track and field configurators.

Design for larger text, different themes and less motion

Important information should survive a change in presentation. Calendar rows and timeline lanes can grow with text; narrow layouts should wrap content or keep genuinely two-dimensional data in a local scroll area. Test long names, translated dates and right-to-left layouts rather than relying on a short English label.

Use the gallery’s Theme, Animations and Right to left controls to explore presentation changes. Shared styles include reduced-motion and forced-colors treatments. Browser emulation is useful test evidence, but does not replace checking actual platform settings.

Use semantic text and surface colors, keep focus visible, and pair status colors with words or other recognizable cues. Custom brand colors, gradients, chart marks and disabled states need review in their real context. A palette preview alone cannot establish contrast across an application.

Explore semantic colors and palettes. Try enlarging this page’s text and navigating its examples without a mouse.

Quality means testing behavior, not just markup

We combine unit tests for control contracts with browser tests for focus, popup ownership, keyboard interaction, touch alternatives and layout. Accessibility scans exercise full component specimens and representative open, empty and invalid states across light and dark themes.

Regression checks cover pointer travel to tooltips, immediate dropdown search, nested overlay dismissal, boundary timeline handles, and enlarged calendar text. Framework checks exercise shared controls through their adapters, including framework-owned content and cleanup.

Automated scans can identify many semantic and contrast problems, but some results require human judgment. An incomplete result stays open for review. Screen-reader tasks, native zoom, custom-painted contrast and complete focus traversal remain explicit manual checks in the coverage record. Compatibility must be verified with the browser and assistive technology used by your audience.

Use the W3C WCAG quick reference to plan criterion-level checks and the ARIA Authoring Practices patterns to understand widget behavior.

Before you ship your application

1. Name the task. Check page titles, headings, landmarks, field labels and action names in the actual workflow.
2. Walk the whole journey. Use keyboard-only navigation, including error recovery, nested popups, cancellation and focus return.
3. Change the presentation. Check 200% text enlargement, 400% browser zoom, text spacing, long translations, right-to-left content and each supported theme.
4. Use assistive technology. Test complete tasks with supported screen-reader/browser pairs, including asynchronous results and empty states.
5. Review your content. Supply useful chart alternatives, accessible PDFs, clear instructions and non-color status cues. Validate authentication, time limits and consequential submissions in your own process.
6. Keep the evidence current. Recheck custom renderers, styles and adapters after changes, and turn reproducible problems into regressions.

Questions and accessibility feedback

Does using Revo UI make my application WCAG compliant?

Conformance depends on the complete pages, content and processes you deliver. Shared components reduce repeated work, while your labels, custom content, styles and integration determine the final experience. Use the coverage record and test your application’s actual tasks.

Can I use the same approach across frameworks?

Yes. The framework guides explain the shared controls and adapter entry points. Each framework still needs integration tests for its content, state updates and lifecycle.

How do I report a barrier?

Report an accessibility issue on GitHub with the affected component, browser, operating system, assistive technology if used, and steps to reproduce. Explain what you expected, what happened and whether a workaround is available. Use a small example and remove private application data.