Developer mode
Opens components on the React tab by default.
Your bookmarks


We are building Orbit to ensure all users have the most pleasant experience possible, with basic accessibility support automatically in your project by following the Web Content Accessibility Guidelines.

Why care about accessibility?

By designing for someone with a permanent disability, someone with a situational limitation can also benefit. For example, a device designed for a person who has one arm could be used just as effectively by a person with a temporary wrist injury or a new parent holding an infant.

Microsoft Inclusive Design

Consider these use cases when using a phone or our website:

  • Too much bright light – using a mobile device on a beach or on the sun
  • Very low display brightness in dark environments
  • Not perfectly calibrated glasses or just tired eyes
  • Non-quality displays in foreign countries
  • Non-stable environment, like a bus or subway where you are balancing in a crowd and need to find information quick

Quick overview of WCAG 2.1

The Web Content Accessibility Guidelines (WCAG) are a single shared standard for web content accessibility. Going through the WCAG specifications might seem, well, overwhelming. But they are the most complete source for web accessibility. And navigating them can be easier then you might think. Rather than jumping into the complete specifications, go with a quick reference guide.

The guide shows you all the rules with short descriptions and then techniques and failures for each rule. To pass each rule, implement one of the sufficient techniques and avoid the failure criteria. You can also visit each criterion, which has its own page describing it in detail, sometimes with implementation examples.

Learn more:

What we offer and what you can do

As Orbit, we try our best to have accessible components from the get go and abstract as much we can for developers. For example, we have a few components that will help you to make your websites more accessible.

However, we can’t do everything as making products accessible is a team effort. Below, you can find a list of current components where we need your help to ensure proper accessibility support.

React ComponentWhat Orbit offersWhat you need to do
BadgeScreen reader supportFill ariaLabel if there is a need for more information than you can fit in content
ButtonScreen reader / keyboard navigation supportRead about Button’s multiple accessibility properties
ButtonLinkScreen reader / keyboard navigation supportRead about ButtonLink’s multiple accessibility properties
CardScreen reader / keyboard navigation supportUse the dataA11ySection property when needed
HeadingScreen reader supportUse the dataA11ySection property when needed
NotificationBadgeScreen reader supportFill ariaLabel if there is a need for more information than you can fit in content

Screen readers (assistive technologies)

Screen readers are the core assistive technology for visually impaired or blind users. Navigating an improperly designed website with such disabilities is a very different experience, and until you try yourself you might never understand how complicated it can be to do things people take for granted. If you want to understand keyboard navigation and screen readers little more, read an article on the experience and try it out yourself. Understanding the user context is the first step to being able to develop and design for their needs.

Luckily, all major operating systems already have a screen reader included, so you can just open it, follow the basic tutorial, and go on the web. Mentioning the tutorial here is not a coincidence. Screen readers are powerful tools with a lot of interesting features. They allow users to jump to headings, find the closest buttons, and lot more. To get better idea of what screen readers can do for a user, take a look at those basic command cheat sheets for voiceOver on Mac or for Windows

Learn more:

dataA11ySection property

We introduced this property across our design system to enhance our accessibility. The Navigation component serves as quick navigation for actions that can be hidden or hard to reach from keyboard navigation. The dataA11ySection property then servers as a pointer for this navigation.


With accessibility regarding color, there are two main parts to keep in mind.

Ensure proper color contrast 

  • Minimum requirement: Level A according to WCAG
    The contrast ratio between the background and foreground should be at least 3:1 as this ratio is recommended for users with normal vision.
  • Recommended requirement: Level AA according to WCAG
    We should have a contrast ratio of at least 4.5:1 between the background and foreground. There is an exception for larger text over 24px (or 18px bold) – the contrast ratio in such cases should be at least 3:1.
    This color contrast ratio should be used for any color which is used for showing important information (icon and text).

Orbit provides an accessible palette of colors.

// Disclaimer – we know about slight contrast issues in the product color and we are working toward fixing that.

Tip: Avoid using pure black text on a pure white background as it’s difficult to read for dyslexic users. The combination of these colors causes the words to blur together.

Convey information with more than just color

A message conveyed with color alone will be completely lost for some users. For example, don’t indicate an error only with red, as the inability to distinguish red and green is the most common type of color blindness.

It’s important to convey information in multiple ways and make sure the message is clear even with CSS disabled. You can use labels or icons to convey errors and important states.


Clear typography helps ensure the content is readable and everyone can follow the flow of the text. This means making sure the text is big enough to read and the spacing around the text makes it easy to distinguish what should be read.

Font size

Having a clear base size for the text enables you to base other sizing and spacing relative to that. See the Typography section for how it works in Orbit.

Keep in mind that many users will use zoom and other technology to resize the text to fit their needs. Make sure your content works with no overlapping or need to scroll horizontally even with the text at 200% of the base size.

Line spacing

Proper spacing of lines helps readers track their progress through lines and recognize when they’ve reached the end of a paragraph. This means it’s important to think about spacing both within and between paragraphs.

Within a paragraph, you want to aim for a line height that is about 1.5 times the font size.

Spacing between paragraphs and other elements should be enough to distinguish different elements while keeping related elements connected. See the section on spacing for more on the Orbit system.

Line length

Long lines of text can be hard to follow and make readers lose their place in the text. With shorter lines, it’s easier to flow from one line to the next.

Make sure your lines do not exceed 80 characters (or 40 for Chinese, Japanese, or Korean characters as those are about twice as wide). Lines can be shorter as well, down to 50 (or 25) characters.


Justifying text to both the right and left can create uneven spacing (“rivers of white“) that makes it hard to follow the flow of the text. That’s why Orbit Text components do not offer this as an alignment option. Base the text alignment off the directionality of the language.

Bidirectionality (RTL)

Users of right-to-left (RTL) languages expect their content to start on the right side. This expectation sets the basis for all their interactions. If only the text starts on the right, it will make it harder for users to understand what to do to accomplish their goals.

Luckily, Orbit components are designed to work in both directions. This lets you mirror your layouts so the important aspects are clear to users of any language. You can see how to implement RTL language support with Orbit.

As a part of this process, important visual clues (like a forward arrow pointing to the right on a Tile) are mirrored in RTL presentation (the arrow points to the left by default).

When building mirrored layouts, it’s important to recognize that not everything should be mirrored. For example, numbers stay the same. Also, many icons, such as the magnifying glass of search, are designed to work no matter the direction of the text, so the icons default to not reversing based on RTL settings (though you can manually override this).

Focusing on making sure your designs make sense from each direction helps ensure they will be usable by everyone.


When designing across devices, window sizes, and orientations, it can be difficult to maintain a consistent look that is usable at various scales. It’s important to ensure that people can use your designs however they access them.

Media queries

With Orbit, it’s important to always design for mobile first and make sure everything works at that scale. Once that’s ready, you can scale your designs up to reach various audiences.

To get your designs to work, take advantage of Orbit media queries. This can help make sure you’re using the space available to you and not blocking out features at various scales.

Target sizes

When working in smaller sizes, such as small mobiles, designers often want to increase the real estate they have available. So they group targets (buttons and other interactions) together and make them small to make more room elsewhere.

The problem is that, as anyone who’s tried to hit the bullseye on a dartboard 🎯 knows, smaller targets are harder to hit. And when small targets are closer together, it makes it more likely that users will hit the wrong target accidentally, increasing their frustration with your design.

So especially in mobile designs, you want to make sure your targets are designed for human fingers. This means aiming for sizes that are 7–10 mm wide. (Note that this involves the target size, which can include padding and isn’t limited to only visible icons.)

This translates to different values depending on the device, but can be generalized as at least 44 by 44 CSS pixels. An example is an Orbit circled Button at normal size.

Then to make sure each target can be used separately, make sure to include enough spacing between each target. This is usually set as at least 8 CSS pixels, which you can see in the Orbit design tokens for button margins.

It’s also important to keep in mind that the edges of screens aren’t so easily accessible or may be used for swipe gestures, so you’ll want to add extra spacing for any targets near the edge.

When you size and space your targets properly, you make your designs usable for people whose hands shake, older people, people with disabilities, people with large fingers, and more.

And the great thing is that when you plan your designs like this on a mobile scale, scaling them up will help people with targeting on desktops. This ensures your design will be usable in all situations.

Things to keep in mind while developing

  • Make sure your HTML uses proper semantics and is well-structured so the application is understandable and usable with CSS disabled (or when read by screen readers).
  • Any text in ALL CAPS should be typed in its proper casing and capitalization should be achieved using CSS.
  • All non-text content (photo, icons, illustrations, and so on) need to have alternative text.
  • All major functionality should be accessible by keyboard.

Hooked on accessibility?

Here are some interesting sources you can explore!