ADA Compliance Product Upgrades - by Dave Seifried

Over the last few months the Privy engineering team has been hard at work making all of our campaign displays ADA compliant. This is a high-level overview of what ADA compliance is, how this changes campaigns authored in Privy, and what type of functionality you can expect in the future.

What is ADA compliance?

The Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design in September 2010. These standards state that all electronic and information technology must be accessible to people with disabilities.

Who does the law affect?

  • Americans with disabilities and their friends, families, and caregivers
  • Private employers with 15 or more employees
  • Businesses operating for the benefit of the public
  • All state and local government agencies

How does this change my Privy campaigns?

To most users this should result in no noticeable change of functionality. On the other hand, users relying on screen-readers or other assistive technologies to browse the web should notice a large range of improvements.

What do I need to do?

All functionality mentioned below is automatically available on all campaign types. To ensure the campaign has the most recent ADA changes applied, open a campaign’s display editor and click save.

What’s new?

Headings

We’ve added the ability to create HTML headings as part of our text editor. Any text you edit should now have an updated set of controls. Users can now select between normal text, Heading 1, Heading 2, and Heading 3. The three headings mentioned will now ensure all text rendered uses the appropriate HTML heading.

Headings are important for a variety of reasons:

  • It conveys the importance of the message
  • Denotes a relative position on the page
  • Allows users to quickly navigate the page (navigating between headings)

Labels & Roles

All buttons, inputs, images and dialogs now have associated labels and roles assigned to them. Screen readers are able to recognize these roles and labels to provide contextual feedback about what element is currently focused, whats its purpose is, and its current state. A few examples are:

  • Buttons - (close button is labelled as such, so is the sign up/submit button)
  • Popup/Spin-to-win campaigns - Have a role of dialog to ensure users are aware a new modal has been opened.
  • Input elements - Describe what this field is attempting to capture. Also has associated labels for its current checked state, and potential how many items are in the group.
  • Alerts/warnings - Now properly labelled
  • Tab buttons - Correctly labelled as a button

Keyboard navigation

Users can now reliably navigate within a Privy display. This means using the Tab and Shift+Tab keys to change focus between elements, using the Escape key to close the dialog, and using the Enter/Space keys to submit buttons.

In addition to that, the arrow keys also allow navigation within a given radio button group.

Focus locking

When a Privy modal display is opened, focus is now properly locked within that display. In brief, this means the following:

  • Popup and Spin-to-win campaigns are the only two display types where focus locking applies
  • When locked, focus can not exit the container until the display is closed
    • This means keyboard navigation will not accidentally focus an item not within the display

All dialogs also now immediately focus the first focuss-able element within them.

What’s next?

  • Proper use of color contrast between text and its background
  • Placeholder text for various inputs
  • Allowing users to set custom alt text for images

We’re committed to ensuring that our current displays and campaigns remain ADA compliant. Keeping accessibility concerns top of mind when authoring, reviewing, and shipping code can be challenging. It’s easy to forget that we all don’t navigate and browse content the same way on the web. Writing code in an ADA compliant fashion can seem tedious, overly descriptive, and often feel like you’re duplicating work and it’s not until you try using a screen reader that it becomes immediately apparent why this is so important. Without labels, roles, keyboard controls, and proper use of focus, its nearly impossible to navigate a page effectively, let alone understand where you are.

Just like the web is meant to be an open and accessible place for all, the code we write should also follow the same principles.