Issue 26 \\ Read past issues

Issue 26 // On The Move

Putting in the time to build something the right way is no guarantee that it'll always work for everyone. Testing and talking with real users before and after you ship are essential to making sure everyone can use your products. And sometimes the foundation upon which we build our software shifts beneath our feet, pushing us to find new techniques. One way or another, we've got to keep moving our craft forward.

In this issue, UX Developer Mardav Wala pulls the curtain back on the recent accessibility improvements made to the Subscriber table in MailChimp, making it more usable in screen readers. UI Designer Caleb Andrews takes web animation into the modern age with SVG. We conclude with some of the best links the web has to offer.
Forward to Friend
Editors: Aarron Walter, Gregg Bernstein & Laurissa Wolfram-Hvass
Artwork: Caleb Andrews

On Twitter: @MailChimpUX

Making MailChimp More Accessible

by Mardav Wala
We are very lucky that our great customers provide valuable feedback—not only about what works well in MailChimp, but also on the things that don't.

Back in the fall, customer Justin Romack tweeted some accessibility issues to us. He struggled with the accessibility of our dashboards and subscriber table.

UX Researcher Gregg Bernstein went back and forth with Justin over email, as Justin explained our app’s accessibility issues. He summed up his position clearly:
“Email marketing is an insanely important part of my business, and the clients I work with each and every day. Being a totally blind guy and depending on screen reading technology, it’s not always easy to find a dynamite option that meets my needs *and* is fully accessible. MailChimp most certainly comes the closest, though.” 
Lucky for us, Justin has consulted on accessibility issues before and offered to assist us to improve MailChimp. He was kind enough to send us videos showing the problem areas in our app and taught us a few things along the way.

By watching those videos and reading some articles, we found that we could greatly improve accessibility in the app by focusing on two objectives:
  1. Establish and provide context on elements using either the WAI-ARIA roles and properties or the HTML title attribute.
  2. Ensure that all markup is semantically correct. (This wasn’t true for the MailChimp subscriber table, which at the time, used a div-based layout.)

Dashboard Improvements

In the last release, we started making accessibility improvements to the dashboards. These easy, but effective, fixes add context to the dashboard elements, which screen readers use to provide audible descriptions.

All dashboard views in MailChimp are based on the slats pattern, which is made up of semantically correct list elements containing a checkbox, a linked heading with supplemental information, and a combo-button with action items. Some dashboards also include a subscriber count, along with open and click rates.

Previously on the Campaigns dashboard, the supplemental information about the campaign type and list name didn’t provide enough information to explain what these elements actually mean. Campaign type “Regular” and list name “Testing 1” aren’t very descriptive or self-explanatory. To fix this, we used aria-label to add descriptions to the campaign and list information. This instructs screen readers to announce text preceded by either “campaign type” or “list name.” We also used aria-label for the dashboard icons to provide audio cues about campaign status.

Although the subscriber count and open/click rates are written in semantically-correct markup, a screen reader would announce the numbers and corresponding labels separately, making the information difficult to understand. To prevent this from happening, we hid the subscriber and open/click rate information from the screen reader, then added the information back as an aria-label on the parent container. This prompts the screen reader to announce the numbers and their labels together. The examples below show the difference between campaign statistics without the aria-label and campaign statistics with it.
In this example, the screen reader announces the data and its labels separately--which makes the information difficult (if not impossible) to understand.
In this example, the data block is defined with aria-label + role="note."  This ensures that the screen reader will announce the data together with its labels.

Subscriber Table Improvements

The subscriber table got a much-needed refactor as we continued to work on accessibility improvements in the last release. It is now defined in semantically correct data table markup.

As shown in this example, our subscriber table scrolls horizontally behind the single fixed column on the left. Originally, we used th, thead, and tbody in conjunction with this absolutely-positioned column, but this made VoiceOver announce two column names per column. For VoiceOver users, this shifted the entire table to the left. To fix this, we now only use td elements in the table and assign the columnheader role to the headers. We found Yahoo! Accessibility's video on implementing accessible tables very useful while we worked through these changes.

We also added more context using title attributes to the subscriber profile checkboxes, which allows screen readers to announce the subscriber email address when a checkbox gets focused, as demonstrated in the example below.
Adding a title attribute on a checkbox conveys a lot more meaning than having screen readers just announce its checked/unchecked state.
We also improved the member rating list for accessibility with ARIA roles and labels.
Originally, the font icons in our star rating system failed to provide any descriptive information to the screen readers.
We improved the accessibility of our star ratings by applying presentation roles to the font icons and adding a descriptive aria-label to the container. This helps screen readers provide relevant audio cues.

View Subscriber Table on Codepen
After we made our adjustments, we asked Justin for a follow-up. We were happy to receive such a positive response:
“Nothing wonky. Nothing weird. It reads straight across perfectly—just as expected. Loving it! :)” 
We feel very fortunate that Justin reached out to us and that he was available to provide feedback on the changes after each release.


Ensuring markup is semantic and providing descriptive context to elements are two very easy things we can do to make an app screen reader-friendly.
Adding HTML titles to provide more context is cheap, and they improve the experience for all users.
For complex JS-based interactions, it's best to use one of the available frameworks. We use Dojo, and as an added benefit, we get all the UI widgets with built-in accessibility features from its UI library.

We’re just getting started on improving accessibility in MailChimp! Expect more of these enhancements in the coming releases for our campaign editor and other places in the app.

Preparing SVGs for Animation

by Caleb Andrews
The scalable vector graphic–or SVG–will be thirteen years-old this September. For some that's hardly a surprise, but others are only now learning about the exciting advantages of the animated SVG.

SVG animation is a subject that's hard to do justice in just one article, so we're going to break it into two parts: Preparing SVGs for Animation and Animating SVGs.

In this issue, I focus on preparing a static illustration for the browser. In Issue 27 we'll take it further, and UX Developer Alvaro Sanchez will bring our SVGs to life with some scripting magic.

We start our SVG animation journey with some tips on file cleanup and preparation that proved to be helpful during our journey to get customers excited about our high five animations.

Tip 1: Layer Hierarchy

In Illustrator, layer hierarchy is king when preparing a SVG illustration. We opted to place animation frames in groups so each illustration was clean and consistent. Properly naming groups goes a long way when you need to identify the output of each group or path in a text editor, which we'll need to do when scripting the animation. For example, Freddie's watch is broken down into paths within a group so we can animate the time of a scheduled campaign.

Tip 2: Remove Excess Anchors

Creating fewer groups, paths, and points in a layer helps keep SVG code light and legible. Notice how the watch on the left has fewer anchor points than the one on the right? By installing Hiroyuki Sato's scripts pack for Illustrator, it's easy to remove excess anchors under File > Scripts > Remove Anchors.

Tip 3: No Masks Beyond This Point

Above, Freddie's high five is merged into a single SVG without masks as three groups. These groups are considered the frames in the animation and can be hidden or revealed when necessary. Sticking with the intended position, we chose to create the masks via code to have more control and a cleaner SVG.

Tip 4: Deselect Illustrator Editing Capabilities

Next, you'll need to export your art out of Illustrator as SVG. This one's easy to miss, but when saving your file in the SVG format, be sure to deselect Preserve Illustrator Editing Capabilities in Options. Doing this will trim a lot of extra weight from SVG code that you don't need in the browser. However, make sure you do this with the final version of your illustration because, as you might guess, you won't be able to easily edit this file in Illustrator again.

Tip 5: Strokes Versus Shapes

You can open your SVG assets in a text editor and take a look at the code generated. In the example above, I have SVG shapes for a rectangle and a stroke. In theory, they're the same thing—a rectangle—but the code to draw them is entirely different. If working with stroked paths isn't your style, a stroke can be easily expanded by heading to Object and selecting Expand in Illustrator.


Not too difficult, huh? With just a little bit of thoughtful preparation, it's pretty simple to output a SVG that lives up to the hype and doesn't bog down the browser.

Join us in the next issue where Alvaro will share some tips for putting SVGs in motion.

UX Around The Web

Ask Us Anything

We want this newsletter to be a dialogue. If you have questions for the MailChimp UX team about which King of Pops flavors are the best, which superhero is Fabio's favorite, or what we pack in our carry-ons when we travel, send them in! Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.

© 2001-2014 All Rights Reserved.
MailChimp® is a registered trademark of The Rocket Science Group

view in browser   unsubscribe   update subscription preferences   

Email Marketing Powered by Mailchimp