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 manual
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.
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 Component||What Orbit offers||What you need to do|
|Badge||Screen reader support||Fill ariaLabel if there is a need for more information than you can fit in content|
|Button||Screen reader / keyboard navigation support||Read about Button’s multiple accessibility properties|
|ButtonLink||Screen reader / keyboard navigation support||Read about ButtonLink’s multiple accessibility properties|
|Card||Screen reader / keyboard navigation support||Use the dataA11ySection property when needed|
|Heading||Screen reader support||Use the dataA11ySection property when needed|
|NotificationBadge||Screen reader support||Fill 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 this article 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.
- A video on how screen readers work and sound
- A video from a screen reader user on why and how she uses it
- Funkify, a Chrome extension that simulates browsing the web with different abilities
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.
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.
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.
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.
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.
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.
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!