Accessibility

Making your Medallia applications usable by as many people as possible

Accessible products enable users with disabilities to interact with Medallia products and features with the same degree of success as users without disabilities. Accessibility considers users with various types of disabilities. For example, accessible products improve layout and visibility, and permit assistive technology to read and answer forms for customers who have blindness, low vision, and limited movement.

Follow these best practices to ensure maintenance of product accessibility when customizing Medallia Experience Cloud.

WCAG guidelines and other resources

Medallia strives to ensure that its products and functionality meet industry-standard Web Content Accessibility Guidelines (WCAG), which provide standards for making web content more accessible to people with disabilities. For more information about WGAG, including conformance criteria, see the Web Content Accessibility Guidelines Overview on the World Wide Web Consortium website.

Medallia offers several accessible product templates, and continues to work on expanding the range of accessible product templates. Experience Cloud offers web-based survey templates, which are viewed by your customers. Experience Cloud also offers core front-line reporting modules within next generation reporting, which are viewed your employees. Section 508 accessibility requirements are consistent with, and covered by, WCAG standards.

These Medallia products and features are currently accessible by WCAG 2.1 AA standards:

  • Digital Feedback SDK.

  • Digital Feedback web-based survey templates.

  • Medallia Experience Cloud survey templates.

  • Experience Cloud report module templates (within Medallia Alchemy Experience Reporting).

  • Medallia Mobile.

  • Medallia Voices.

Any changes you make to a template have the potential to violate one or more accessibility standards or regulations. This includes, but is not limited to, such things as adding HTML or other markup, adding or changing CSS font or color styling, and adding images. If you customize templates to reflect your company's branding and content guidelines, you might need to make design choices to maintain accessibility. For example, custom colors must have sufficient color contrast, images require alternative text, and any custom HTML or styling must be accessible.

For detailed information about common accessibility regulations and standards, see:

General best practices

Use these best practices when implementing aspects of Experience Cloud:

  • For general guidance about customizing reports, see CSS styling.

  • Provide sufficient contrast between elements. For detailed guidance, see the W3C page about Contrast.

  • Do not rely on color solely to convey important information.

  • Be mindful about color choices to ensure compatibility with accessibility guidelines.

  • All interactive elements (such as buttons) in templates include a focus indicator (such as a border around a button on hover). If you change the color of an interactive element, be sure that the focus indicator is still visible.

  • Computers often have accessibility settings to change the display for low-vision users. The settings can increase the contrast, invert the colors, and make everything gray scale. Use high-contrast to see if a survey is readable, especially for images.

  • Large text is that which is greater than 18pt normal or 14pt bold. It is best to have a ratio of 4.5:1. For more information, see What’s ‘large text’ in WCAG 2.0 parlance.

  • Always test your changes for adherence to accessibility guidelines. For more information, see Accessibility validation tools.

CSS styling

Cascading style sheet (CSS) styles define how to render the content on the user's device, such as a visual browser, screen reader, or visual browser. On a web page or form, CSS styling is performed with stylesheets or embedded in-line with the style attribute. For Experience Cloud surveys, stylesheets are hosted on the Survey engine, and are generated by the Base CSS and Theme CSS properties on Survey designs.

Restriction: Do not use in-line styles because they can easily violate accessibility guidelines. Instead, include all CSS definitions in the Theme CSS stylesheet.

When defining CSS:

  • Required:

    • Ensure documents are readable without style sheets. Use add-on developer tools for your browser to disable the styles.

    • Ensure the reading order of content and elements are correct when viewed without style sheets.

    • Provide text equivalents for icon fonts. For example, when showing an alert or warning symbol as a font, also include text that describes the condition. For more information, see Icon fonts and user-defined style sheets.

    • Ensure containing elements allow text resize.

    • Ensure screen reader specific content is rendered off-screen rather than hidden or not displayed. For example, using position elements to render the content outside the browser window. This usually does not add scroll bars to the window.

    • For decorative images (ones that do not provide content), use background images.

  • Avoid:

    • Using ::before and ::after, pseudo classes for non-decorative content because it is not recognized by screen readers.

    • Background images behind text, which can cause contrast issues.

    • Size declarations on any portion of the box model (see the note below for more on CSS) because they all contribute to the overall size of the element.

  • Do not use:

    • In-line styles (style= attribute).

    • Title (title=) attributes for textual content. Using screen reader, all the titles will be spoken so redundant title should be removed (from the link, not the image). As a rule of thumb, do not use title attributes on links or form elements or table cells or other elements because that can lead to screen-reader users hearing those announcements twice.

    • CSS to render content or provide functionality because screen readers ignore CSS.

    • Absolute units (such as in, cm, mm, pt, and pc) because these are intended for print media. Instead, use relative units (such as ems, percentages, or larger), or do not use units and let the agent use the default units. This lets the user to zoom and enlarge the content and provide proper wrapping and formatting.

See W3C School's CSS Introduction for an in depth discussion of CSS.

Tip: Another class of browsers called speech-browsers or aural-browsers can read CSS specific to speech. Unlike a screen-reader, which ignores CSS, these browsers can use different voices, change pitch or volume, and spell words, all based on the HTML and its associated styles. For information about using these styles, see the W3C CSS Speech Module.

Accessibility validation tools

These tools are useful for testing accessibility and color contrast:

Accessibility Insights
This browser extension reviews your site, shows accessibility errors, provides suggestions to fix problems, and includes the WCAG specification.
aXe (Chrome)
This highly configurable Chrome extension helps find accessibility defects on web pages.
Web Accessibility Evaluation Tool (WAVE)
This reporting tool evaluates web pages and reports on elements that fail to achieve accessibility. This tool is provided by WebAIM and is available as a web site for evaluating public pages, and it is available as an extension for Chrome to evaluate any page displayed in the browser.
Color Contrast Analyzer (Chrome)
This extension from NC State University analyzes the contrast of text and images to indicate areas of high and low contrast.
Color Contrast Analyzer (Firefox)
This Firefox browser extension lists the text elements on a page that are not accessible.
WCAG Color Contrast plug in for Firefox
A Firefox extension that allows allows you to click on a page element and see the contrast ratio.
Contrast Analyzer
Application for Mac and Windows that analyzes the legibility of text on a page.
Color Contrast plug-in for Mozilla
WCAG Contrast analyzer plugin.
Color Contrast Checker
WebAIM web page for validating color contrast.