FAQs

Being compliant with Accessibility guidelines enables a better experience for all users, including those with impairments, and also protects American Express from legal repercussions.

Our partners in GCO created a Digital Accessibility Policy, that defines the Accessibility standard as meeting all AA listed guidelines, as well as 11 additional AAA guidelines. The list of AAA criteria can be viewed on Standards and Resources | DLS - Confluence (aexp.com).

WCAG 2.1, the list of full criteria can be viewed on WCAG 2.1 Quick Reference.

Several issues were found across the DLS components, between both libraries. The majority of issues found are small ones that can be easily fixed, though some were found that require a more comprehensive change to a given component. Approximately 25% of all issue require visual changes, whereas the rest are issues that are non-visible changes, for example supporting better reflow across device sizes, as well as the use of assistive technologies like screen readers. If you would like a detailed breakdown of all issues found in the DLS, you can view them in Airtable.

All DLS Accessibility remediations were released with DLS v6.23.1. We paid special attention to make these changes backwards compatible with any existing v6 DLS components and and classes that your applications may already use. In order to comply with the accessibility guidelines, you may need to update your application to include some additional information, such as labelling for assistive technology. The process for this can be achieved iteratively, however, and you shouldn't have any issues upgrading your application to use the v6.23 changes in production whilst you add in the accessibility enhancements.

DLS v5 will not be updated to include accessibility compliance. Teams using DLS v5 will need to update to v6 in order to benefit from the DLS Accessibility remediation work.

GCO has indicated that teams will have 1 year after the announcement of the Accessibility policy to become compliant with it. Reach out to your local compliance partner for up-to-date guidance.

The DLS will not be able to assist teams in assessing which issues are DLS related vs. which are experience-specific. Please refer to our Airtable, which provides a detailed breakdown of all known DLS issues.

'Even if we could accurately measure how many people with disabilities used our site, it isn’t a very meaningful number. If our site is inaccessible to people who use voice control, chances are those people are shopping with our competitor instead. The reason they don’t show up in our numbers might be just that.' - How many people with disabilities use our site? | hidde.blog

All DLS Accessibility issues were released with DLS v6.23.1, making them backwards compatible with any previous DLS v6 version. This will still require teams to update to the latest DLS v6 version containing the Accessibility fixes. Note: teams can skip minor versions and adopt the latest version with the Accessibility fixes (e.g. a team currently on v6.5 can jump to v6.23 without issues).

Yes, the new kit has been released (v6.23) and all updates are tracked on the DLS Design Kit Release Notes.

• Manual download: download kit from DLS site, duplicate and relink symbols.
• Using Local File:

1. 1) Duplicate file to have a backup and to be used as a side by side for copy/state
2. 2) Download DLS Design Kit v6.23 from the DLS site
3. 3) Relink library
4. 4) Run “Update Components” button in sketch
5. 5) Click on symbol and change it in the right hand panel
6. 6) Turn off “Swap at Original Size”
7. 7) Relink each Symbol to the DLS Design Kit v6.23 library
8. 8) You might have to revert overrides and update your copy or state

• Contrast: Sufficient color contrast is a key requirement for any accessible experience. (see WCAG Success Criterion 1.4.1: Use of Color for more details). The DLS has updated its neutrals to ensure sufficient contrast with the most common background colors used across the enterprise*. In addition, which neutral is used for key visual indicators, such as borders, have also been updated to ensure sufficient contrast.
• Size of targets: Due to the minimum requirement for touch targets to be 44x44 pixels (see WCAG Success Criterion 2.5.5: Target Size for more details), spacing of both individual and nested elements needed to be reconsidered and updated across several components within the DLS.
• Hierarchy & Reflow: The WCAG site states that the success criteria around reflow is to help people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.

• Use the DLS whenever possible
• Follow the DLS Accessibility best practices
• Use the DLS Checklist by Role
• Use the DLS Accessibility best practices
• Use the DLS Tools and Resources
• Follow the Digital Accessibility Policy
• Reference WCAG whenever possible
• Reach out on #a11y to speak to the accessibility community
• Join the DLS Support Drop-In sessions (held every Tuesday)
• Check out the product inclusion toolkit (Coming soon!

• Insufficient color contrast
• Nested tables
• Making critical information harder to get to by nesting elements
• Adding unnecessary title attributes
• Non descriptive copy that does not provide sufficient information to the user
• Not offering keyboard navigation
• Improper use of tabindex
• Improper use of ARIA attributes
• Input fields without labels
• Using icons alone to communicate crucial information
• Providing skeleton pages that impact the Accessibility tree

Yes. Through extensive research and our partnership with Deque, the DLS team recommends underlining inline links within blocks of text. Color contrast is not sufficient alone to distinguish a link from adjacent text. This is also a very long established visual affordance pattern used throughout the internet.

• Use of color (A) standard: Understanding Success Criterion 1.4.1: Use of Color | WAI | W3C
• Use of color failure: https://www.w3.org/WAI/WCAG21/Techniques/failures/F73
• Ensuring additional visual cues with links: http://w3.org/WAI/WCAG21/Techniques/general/G182
• Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on hover for links or controls where color alone is used to identify them: https://www.w3.org/WAI/WCAG21/Techniques/general/G183

• No, it will not meet color contrast ratio of 3:1 for adjacent text within our system of colors.
• Use of color (A) standard: ‘if content relies on the user's ability to accurately perceive or differentiate a particular color an additional visual indicator will be required regardless of the contrast ratio between those colors.’ Understanding Success Criterion 1.4.1: Use of Color | WAI | W3C
• Use of color failure: https://www.w3.org/WAI/WCAG21/Techniques/failures/F73

We have tested a variety of colors to see how we can best meet color contrast with adjacent text and found there is a very limited color palette that allows for this to be accessible when also considering a 3:1 contrast ratio. In addition, changing the contrast ratio alone is still not fully accessible. In the examples below, though example 2 and 3 pass contrast it still remains difficult to identify links within a paragraph. Using an underline provides users of all abilities the additional signifier that 'this is a link'.

No. The underline is sufficient enough to meet the requirement for inline links within blocks of text.

Standalone links require a visual differentiator to allow users to distinguish them from tertiary buttons. This needs to remain consistent across the organization to allow system users to reliably identify different components. Within the DLS we are using the underline pattern to signify links. Some components that you will see with this update are Inline Link, Standalone Links, and Cards with Link.

Our major consideration is that the underline visually distinguishes standalone links from the DLS tertiary button when both are used within the same journey. Whilst there are some exceptions for when an underline can be optional, there are no times where including the underline makes the component less accessible. In other cases, such as inline links, underlines are a requirement in order to meet the accessibility guidance. Based on the expected use-cases of these components across the organization, we expect this to be a requirement in the majority of instances. Introducing a new prop will introduce a new variant and technically make our component inaccessible.

Your buttons most likely have underlines because you are using the ‘Anchor’ component and including extra styling to make it look like a button. This component has been updated to always include the underline style.

• If the action is a button action - affecting something in the current page or submitting the form in the page - it needs to be coded and styled as a button.
• If the action is an anchor action - navigating to another resource - it needs to be coded and styled as an anchor (link).

Each of those two objects have different ways users can interact with them, have different ways their APIs are handled, and need to be identified as what they are. In other words, if you have a link that looks like a button, or a button that looks like a link, it should fail the “consistent identification” test (SC 3.2.4).

We recommend that you don’t remove the underline, as it reduces the visual signifiers that differentiate Standalone links from our tertiary button. If you do choose to remove the underline, it can be accomplished by adding your own styling with the theme prop.

Links that appear in nav elements typically don’t require an underline because they are expected to be navigation links and are designed in a way that makes them easily recognizable as links. In our design system, there are enough visual signifiers to not need an underline.

Although navigation uses <a> tags, navigation is semantically different from links or buttons as the navigation component surrounds the list of <a> tags with <nav>.

Please refer to our blog post on Links vs Buttons (OneDev Blogs)