Accessibility
Certara appreciates that users have different abilities, and we strive to produce solutions that meet the needs of a diverse audience—including those with disabilities who use assistive technology to access digital content. By including and respecting diversity in our design process, we ensure that everyone can access the content they need.
We are guided by the Web Content Accessibility Guidelines (WCAG) 2.1 A/AA
Everyone benefits from accessibility
Accessibility efforts typically aim to serve users who may have an impairment affecting the following:
- Vision
- Auditory Sense
- Motor Function
- Cognitive Ability
However, web accessibility is not limited to persons with permanent disabilities. Considering the needs of users with disabilities when designing makes the experience better and more robust for all users. For example, using colors that have sufficient contrast to background content is not only an aid to users with a visual impairment but also beneficial to everyone looking at a screen in bright daylight.
Categories of accessibility
Perceivable
Information and user-interface components must be presentable to users in ways they can sense.
- Example: Do users know that there is a button on the webpage?
Operable
Users must be able to operate the interface. The interface cannot require interaction that a user cannot perform.
- Example: Can users activate the button?
Understandable
Users must be able to understand the information as well as the operation of the user interface. The content or operation cannot be beyond their understanding.
- Example: Does the button have a descriptive label? Is it clear to the user what will occur if they interact with the button?
Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of assistive technologies. As technologies advance and browser and assistive technologies evolve, the content should remain accessible.
- Example: Does the button work reliably and predictably across a broad range of devices?
More detail on these categories and on the rest of the guidelines can be found at Web Content Accessibility Guidelines (WCAG) 2.1
Accessible color
We comply with AA standard contrast ratios
Include multiple visual cues
Don’t convey information using color alone. Use multiple visual cues, such as stroke weight, patterns, shape, text, or illustrations, ensure that everyone receives the same information. This helps people who are unable to, or have difficulty with, distinguishing one color from another. This includes people who are color blind, have low vision, or are blind.
For example, these inline validation messages use both color and icons to distinguish severity:
Do
The warning message uses a bell icon and is yellow in color. The error message uses an exclamation point and is red in color.
Don‘t
Don’t rely on color as the only visual cue to distinguish severity.Use high contrast
High color contrast helps people who are partially or completely color blind see differences between certain colors. It creates a strong visual hierarchy and improves usability for everyone. Make sure that the combination of text and background color does not fall below the WCAG recommended threshold ratio of 4.5:1 for 14px text or lower and 3:1 for 18px text or larger and non-text content like icons.
Meaningful structure and hierarchy
A consistent and clear hierarchy helps people who navigate the page using links or headers. Use headings and titles to outline the page so people can see the structure and how sections relate to each other.
Be predictable with structure and use patterns and layouts familiar to people.
List by level of importance
Place items on the page in order of their level of importance so people don’t have to search for them.
Have a consistent hierarchy
Create and maintain a consistent hierarchy so that people can use alternative input methods to move through the page. Headings are in order without skipping levels.
Heading 1
Heading 2
Heading 3
Heading 4
Do
Use a consistent heading hierarchy: H1, H2, H3, H4Heading 2
Heading 1
Heading 3
Heading 4
Don‘t
Use headings out of order: H2, H1, H3, H3Meaningful text
Consistent and helpful text makes the user interface accessible to people who use a screen reader. Screen readers help people with visual impairments by reading both visible and non-visible alternative text aloud.
All text should support accessibility, whether it’s visible (UI labels, headings, buttons, forms, hyperlinks, and help text) or non-visible (alternative text for images and buttons).
Be concise and use plain English
Keep content and accessibility text concise. People using screen readers hear every UI element read aloud, so the shorter the text, the faster they can navigate the content.
Screen readers can skim more easily and skip irrelevant paragraphs if you keep sentences short and frontload paragraphs with important information.
Plain English helps people skim and digest information faster. It also makes content more accessible to those who speak English as a second, third, or fourth language.
Avoid idioms and always expand acronyms when using them for the first time.
Use consistent labels
Consistently label elements and components that have the same functionality. When people encounter these elements in different contexts, they should be able to recognize and understand the function or actions of an element. For instance, a menu item labeled Projects should open a page titled Projects. A modal with the title Import spec has a button labeled Import.
Do
Title Import spec with a button labeled Import.
Don‘t
Title Import spec with a button labeled Upload.Describe what an element does
Label elements with action verbs that indicate what happens when the element is selected.
Do
Edit preferences - When read aloud, the text indicates the action.Don‘t
Preferences - Just labeling the element doesn't make it clear what will happen when it is selected.Buttons
In buttons, describe what the action does and, if you can, reveal what will happen.
Do
Accept changesDon‘t
Yes!Hyperlinks and skip links
Link text should indicate where the link navigates to. When linking text we use “Learn about” along with a description of where we are taking the user. Link your entire message. For in-app or in-product links don’t use a period at the end of the sentence.
Linking the entire message gives users context about the link destination lowering their cognitive load.
Example: Learn about the properties tab
These links take a user who is visually impaired through hearing a screen reader repeat “Learn more” at this time while tabbing through a page. Linking the full message also helps navigation using screen readers and allows the text to stand alone.
Add skip links or anchors to help people navigate around content pages.
Keyboard navigation
Some people can’t use a mouse to navigate through applications using tools such as a keyboard, mouth wand, or eye tracking system. People should be able to navigate and use the product with a keyboard or screen reader. Make sure anything that can be seen by hovering with a mouse is also accessible to keyboard focus and screen readers.
When creating an application, check if a keyboard can be used to:
- Navigate through the page.
- Perform the same tasks as people who use a mouse.
- Locate where you are on the page.
- Tell where the keyboard focus is.
Manage focus
Keyboard focus follows the page as the eye would scan it. Focus travels top to bottom, left to right, moving from most to least important item. People can navigate applications using alternative input methods (D-pads, trackballs, keyboards, and navigation gestures), and the focus flows in a logical order.
When assessing keyboard focus:
- Be conscious of the order of elements on the page. Do they make sense from the user’s perspective?
- Indicate where the focus is.
- Avoid using input focus to select, trigger events, or display messages. People may need to navigate through all controls before making changes.
- Keep in mind where the focus moves when the element in focus disappears. People should return to wherever they were before they focused on the element.