Guides
Start typing to search…

Accessibility

Overview

Accessibility is the practice of removing barriers. Accessibility makes our products as usable to as many people as possible.

Why accessibility matters

BeyondTrust’s mission is to build a world where identities and access are protected from cyberthreats — but who are the people that make up that world? Globally, an estimated 1.3 billion people experience disability. That’s 1 in 6 people. (World Health Organization, 2022)

A disability is a condition that impairs someone’s ability to carry out their everyday tasks, like using software or the internet. Disabilities can be physical or cognitive, and they can be short-term, long-term, or even situational.
Accounting for disabilities doesn’t only benefit the minority of people. Improved usability comes with accessibility. As author and advocate Elise Roy says, “When we design for disability first, we often stumble upon solutions that are better than those when we design for the norm."

Everyone should have access to protection from cyberthreats. Making our products usable to more people isn’t only the “right” thing to do, but also is advantageous to our growth and protects us from legal action. Existing and potential customers often cite accessibility as a make-or-break selling point, and the number of companies who have been sued for violating accessibility laws increases each year.


Accessibility laws and guidelines

BeyondTrust follows both Section 508 and the Web Content Accessibility Guidelines (WCAG).

What’s the difference?

  • Section 508 is a United States federal law.
  • WCAG is a set of globally recognized guidelines.

WCAG is broken into 3 levels: A, AA, AAA. Level A is the minimum requirement and AA is what most organizations strive for. BeyondTrust follows WCAG AA.


Accessibility resources

The UX team has an accessibility scorecard and criteria available to measure our products against. These resources are informed by WCAG and Section 508.


Accessibility principles

WCAG’s 4 guiding principles of accessibility are POUR.

Perceivable
Information must be presented in ways users can see, hear, or feel.

Operable
Products should be functional no matter how they’re accessed.

Understandable
Content must be understood by all users.

Robust
Products should remain usable as technology changes.


Designing for accessibility

Content and components cannot be invisible to users — regardless of their vision.

There must be a contrast ratio of 4.5:1 between text and background color. Do not rely on color alone to communicate information to users. Certain colors cannot be combined to account for color blindness, like red and green.

Always label fields and controls and position the label nearby. Like color, don’t rely on icons alone to convey meaning.

Text must be large enough to be legible—a minimum of 14pt—and must be resizable.

Give users enough time to read content. Do not use content that could cause seizures or physical reactions.

Present content in a predictable way with a logical layout that makes information easy to locate. Most users read left to right, top to bottom, as do screen readers. Put the most critical content first and never bury need-to-know information in tooltips or help text.

Use the minimum target size (typically 24px) so that users can activate the right target.

Provide instructions and validation to help users complete tasks.


Developing for accessibility

Writing semantically correct HTML is the easiest way to meet accessibility standards. Semantic elements determine the rules for how code gets interpreted. Semantic HTML ensures that structure, meaning, and state are conveyed to assistive technologies. This includes the proper order of headings.

While properly formatted HTML will cover most accessibility needs, use Accessible Rich Internet Applications (ARIA) attributes only when they benefit users. For example, the aria-hidden attribute will hide decorative, non-essential elements from assistive technologies.

By using Kendo, we already ensure our components are accessible — they are Section 508 compliant.
Interactive elements should be functional, regardless of whether someone is using a keyboard, a mouse, a touchscreen, a joystick, or any other input mechanism. This includes the ability to tab between elements in a meaningful, logical order. Typically left to right, top to bottom. There should be no “keyboard traps” (places where you can tab onto an element but are unable to tab back out).

Videos must have captions, and images must have alt text that describes what’s happening. Alt text should be concise and contain the most important information. There is no need to include “image of” or “picture depicting.”

Maximize compatibility with current and future tools.

Each page needs a unique page title to distinguish it from other pages.


Writing for accessibility

Good writing helps users with low literacy, autism, cognitive and motor impairments, non-fluency, vision loss, stress, and more.

Content should be understood by all users. It should not be verbose or use technical jargon. Plain language is for everyone, even experts.

Our users don't have time to read lengthy, complex content. Be succinct. Present important information while using short sentences and basic syntax. Basic syntax means sentences should have only one main idea, have a subject and a verb, and any adjectives should appear before what they're describing.

Convey information without extra words and complex syntax and vocabulary.

👍

Try this

The critical detection is resolved.

❗️

Not this

The detection, which was critical in severity, has been remediated successfully.


Use the simplest, most straight forward diction.

👍

Try this

  • Help
  • About
  • Word choice
❗️

Not this

  • Assistance
  • Approximately
  • Diction

Use the active voice and first person, like you're speaking directly to users.

👍

Try this

You saved the settings.

❗️

Not this

The settings were saved.


Assuming users will understand technical terms is a common misconception that is frequently proven wrong by user feedback and research. Take the time to define terminology, explain concepts, and spell out acronyms.

Keep labels consistent across screens and products.

Choose inclusive language that doesn't exclude users with assistive technologies.

👍

Try this

Select

❗️

Not this

Click


Avoid idioms and metaphors. Don't use abbreviations or shortforms, which take more cognitive energy to decipher. This includes Latin.

👍

Try this

For example.

❗️

Not this

E.g., i.e.


Help users correct mistakes by writing clear, helpful error messages. Provide as much information as possible without compromising security. Don't blame users or apologize too much, both are frustrating. Limit humor that could delay someone trying to do their job. When writing inline errors, be specific about what field the user needs to correct.

Links should clearly and accurately describe where they will take users. Don't use “Learn More” — it confuses screen readers, especially when there are multiple links with this label. Link text does not need to contain the action, like “Open”, as screen readers already know it's a link.

Reading level detectors are a helpful starting point, but don't rely on them alone. Find the words users use through research and test content for comprehension.

Resources

Related

Referenced in this section:

Colors Guidance

Typography Guidance

Updated 8 days ago