Rediger

Del via

Accessibility guidelines for Office Add-ins

Accessible add-ins work for everyone—people who use screen readers, navigate by keyboard, rely on high contrast, or interact through touch. Building with accessibility in mind from the start improves usability for all your users and expands the market for your solutions.

The Web Content Accessibility Guidelines (WCAG) are the international standards that define what's needed for your add-in to be accessible. We recommend you become familiar with them before you start building.

Design for multiple input methods

Your add-in should support keyboard, touch, and mouse input so that every user can interact with it regardless of their device or abilities.

  • Ensure that users can complete all operations by using keyboard interactions alone. Users should be able to reach every actionable element on the page by using a combination of Tab and the arrow keys.
  • On mobile devices, your add-in should provide useful audio feedback when users operate controls by touch.
  • Preserve a logical reading and navigation order in the DOM or UI tree.
  • Ensure all interactive elements expose their name, role, and state to assistive technologies by using appropriate ARIA labels.

Make your add-in easy to use

Predictable behavior and clear feedback help all users understand what's happening in your add-in.

  • Don't rely on sound alone to alert users to important information.
  • Don't rely on color, shape, size, or visual location alone to convey meaning or instructions.
  • Don't require complex gestures (drag, multi‑touch, timed motion) without providing simpler alternatives.
  • Manage focus carefully. Don't move focus to a different element unless the user initiates the change. For guidance, see Navigation patterns for Office Add-ins.
  • Provide a way to verify, confirm, or reverse all binding actions.
  • Don't impose a time limit for user action.

Make your add-in easy to see

Clear visual design and sufficient contrast ensure that users with low vision or color blindness can read and understand your UI.

  • Avoid unexpected color changes.
  • Provide meaningful, timely descriptions for UI elements, titles, headings, inputs, and errors. Ensure that control names clearly describe the intent of the control.
  • Verify that your UI elements render correctly in all four Windows built-in contrast themes: Aquatic, Desert, Dusk, and Night sky. To test, go to Windows Settings > Accessibility > Contrast themes, choose each one, and check that all text, buttons, links, and other UI elements in your add-in are visible and have sufficient contrast.
  • Follow WCAG color contrast guidelines. Aim for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

Ensure content and media are accessible

  • Provide text alternatives for all meaningful non‑text content (for example, images, icons, SVGs, charts, and custom controls).
  • Don't put meaningful text inside images unless an equivalent text alternative is provided.
  • Provide transcripts for audio‑only content.
  • Provide synchronized captions for prerecorded or live video with audio.
  • Provide alternatives to sound as a means to alert users, such as visual cues or vibrations.
  • Provide a way for users to pause, stop, or mute audio or animation.

Test for accessibility

Regular accessibility testing helps you catch issues before they reach users and ensures your add-in continues to work with assistive technologies as standards and platforms evolve.

Integrate automated checks

Automated tools can detect many issues, but they don't evaluate how well your add-in works with assistive technologies.

  • Run Accessibility Insights as part of your build or CI pipeline to identify common accessibility issues early.
  • Use automated checks to validate:
    • Color contrast.
    • Accessible names and labels.
    • Keyboard focus order.
    • ARIA roles and attributes.
    • Target size and spacing.

Validate assistive technology support

Test your add-in with commonly used assistive technologies to confirm that users can:

  • Navigate all interactive elements using a keyboard alone.
  • Understand the purpose of controls through screen reader output.
  • Complete tasks without relying on vision, hearing, or precise pointer movements.

Verify the experience using:

Confirm that:

  • All functionality is available without using a mouse.
  • Focus indicators are visible and not obscured.
  • Dynamic updates are announced appropriately.
  • Custom UI components expose their role, state, and value.

Test interaction patterns

Evaluate user flows—not just individual controls—to ensure that:

  • Dragging or gesture-based interactions have a keyboard-accessible alternative.
  • Time-limited interactions can be paused, extended, or disabled.
  • Alerts and notifications are conveyed without relying on sound alone.
  • Authentication and input methods don't depend on memory, vision, or timed responses.

Re-test as standards evolve

Assistive technologies and international accessibility guidelines change over time. Test periodically to keep up with changes to the international accessibility guidelines. For more information, see Accessibility testing.

See also

  • Last updated on