Accessibility

Our CEO Steve reminds us ‘How we do our work is just as important as what we do. One of our Blue Box values is “we do what’s right” and I believe that is among the things that makes us a great company — and charts a path to an even greater future.’ Code of conduct (americanexpress.com)

For digital accessibility, doing what’s right means we should all be able to use Amex products, regardless of physical or cognitive impairments. In this instance, the term ‘we’ represents our customers, colleagues, contractors, merchants, and partners, any of whom may be either neurotypical or neurodivergent. The term ‘we’ should be considered to include everyone.

Approximately 20% to 30% of us that use the internet have some form of disability. (This statistic is based on self-identified people with disabilities.) Disabilities can be permanent, temporary, and situational. They may affect how we see, hear, communicate, learn, understand, process information, and navigate the world. Assistive technologies originally designed and built for permanent disabilities can improve everyone’s experience. For example, if you have an ear infection (temporary) or a noisy office (situational), captions originally designed for the deaf (permanent), will allow you to follow a townhall. By creating accessible and inclusive designs, we enable everyone to interact with, understand, and navigate the American Express experience.

On this page we’ll cover getting started with Accessibility, role checklists, semantic HTML, aria and accessibility tools.

Getting Started with Accessibility

Advantages of Accessible Products

Improved SEO: By making our products accessible and providing meaningful alternate text for images and using proper and clear heading structure, we also increase the page ranking of our websites.

Improved User Experience: Accessible products are also more consistent and operable for all customers, improving the overall user experience.

Legal Obligations: We have a legal obligation to make our services available to everyone, without discrimination. Make web accessibility part of your standard design and development practices.

Introduction to Accessibility Guidelines

Throughout this guide, we will refer to the Web Content Accessibility Guidelines 2.1 (WCAG), the most commonly used set of guidelines and best practices, put together by accessibility experts. The Web Content Accessibility Guidelines or WCAG apply to all or digital experiences: web, mobile web and mobile app projects. WCAG should be used by both developers and designers. The WCAG has three levels of standards A, AA, and AAA. At Amex we aim for WCAG 2.1 A and AA standard with 11 additional AAA. We have put together an overview of WCAG and it’s four principals to get you started.

Although the DLS provides accessible components, we can’t guarantee by using DLS your experiences will be accessible. Accessible websites need to provide logical hierarchy, keyboard navigation, and many other inclusive patterns. By using WCAG 2.1 as your guide, you are setting up your product to be inclusive and provide an experience for all.

For a comprehensive overview, of Amex success criteria, including market specifics, check our digital accessibility policy AENB77 and TECH06.26,

Contact for More Information

Please contact digitalaccessibilitypolicy@aexp.com or DLS@aexp.com

Checklists by Role

Accessibility is a team effort. The following guide explains a few important items that each team member can use to improve the overall experience of their product. While WCAG provides a comprehensive overview, it can also be a bit overwhelming. To help mitigate this, we have put together an easy-to-follow checklist for each role, targeted specifically for web content.

Introduction to Semantic HTML

Usage

A semantic element clearly describes its meaning. Semantic HTML helps assistive technology users understand the content’s structure and meaning, and a number of elements have built-in interaction with keyboard support. Use proper semantic HTML in your UI to convey meaning in a non-visual manner and to offer keyboard accessibility. HTML should be coded to represent the information and not its default presentation styling. How it should look is the responsibility of CSS.

Semantic Properties

Every HTML element has some of the following semantic properties:

• Role or type: describes the element’s type such as “link”, “button”, or “input”
• Name: computed label from the element’s text content or attributes such as “alt”, “aria-label”, or label tags
• Value: value that the user has entered
• State: current status of an element such as expanded or collapsed, open or closed

Examples of non-semantic elements:

• <div>
• <span>

Examples of semantic elements:

• <article>
• <button>
• <footer>
• <form>
• <nav>
• <p>
• <section>
• <table>
• <ul>

MDN web docs have a full list of semantic HTML elements (developer.mozilla.org)

Example - Headings

      <h1 class="heading-6">Top level heading</h1>
    

      <span class="heading-6">Top level heading</span>
    

Example - Navigation

      <nav">...</nav>
    

      <div role="navigation">...</div>
    

Example - <a> vs. <button>

Visually, the anchor and button elements may look identical in style and design, but semantically they are different. An anchor element represents a hyperlink to a page or a section within a page. The button element represents an interaction when clicked on. Additionally, links are expected to be triggered with the Enter key, while buttons are expected to be triggered using the Space key.

Use anchors if it is a link with a meaningful href. Use buttons for interactions that do not redirect or navigate.

      <button onclick="doSomething();">Do Something</button>
    

      <a href="#" role="button" onclick="doSomething();">Do Something</a>
    

      <a href="#section5">Section 5</a>
    

      <button onclick="goTo('#section5');">Section 5</button>
      or
      <a href="#section5"><button>Section 5</button></a>
    

Using ARIA

When using ARIA (Accessible Rich Internet Applications) to provide text for screen readers, follow the following guidelines:

• Always use native HTML elements or attributes with the semantics and built in behavior instead of repurposing an element and adding an ARIA role, state, or property to make it accessible.
• Hide text that shouldn’t be read, such as the punctuation used to convey ideograms and smileys.
• Avoid changing native semantics.
• All interactive ARIA controls must be usable with the keyboard. If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.
• Do not use role=“presentation” or aria-hidden=“true” on a visible focusable element because it will result in some users focusing on “nothing.”
• All interactive elements must have an accessible name. An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value. Adding an ARIA role overrides the native role semantics in the accessibility tree, which is reported through the accessibility API, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.

      <span class="sr-only">Smiley face</span>
<span aria-hidden="true">:-)</span>
    

      <span>:-)</span>
    

For more details on using ARIA, W3C have put together an ARIA Authoring Practices Guide (APG) with ARIA pattern examples.

Tools and Resources

There are a variety of tools available for website owners, developers, and testers to test and verify the accessibility of a site.

Slack Community

#a11y
American Express Slack channel for accessibility discussions

#productinclusion
Our goal is to make a commitment to our colleagues and customers to proactively and purposely design product experiences with inclusion at the forefront.

Accessibility Tools

• Color Contrast Analyzer: Helps determine legibility of text and contrast of visual elements
• aXe / aXe-core: Automated HTML accessibilty testing library. To avoid regressions, especially in a continuous integration environment, incorporate a library like axe-core into your automated test suite. Axe-core is the same engine that powers the aXe Chrome extension, but in an easy-to-run command line utility.
• Lighthouse by Google: Helps determine legibility of text and contrast of visual elements. Lighthouse measures the performance of your web product, but also uses the axe-core library to power a set of accessibility tests. If you’re already using Lighthouse, keep an eye out for failing accessibility tests in your report. Fixing these will help improve the overall user experience of your site.
• Wave by WebAim: Chrome and Firefox extensions that evaluate web content for accessibility issues within Chrome and Firefox browsers
• Siteimprove: Chrome extension that evaluates web pages for accessibility issues
• eslint-plugin-jsx-a11y: Checks accessibility rules on JSX elements

Resources

A list of external and Amex internal resources to get you started with accessibility.