This is the third in our series on testing and improving the accessibility of KPR’s websites. Previous posts focused on how we conducted systematic do-it-yourself accessibility testing and how we fixed the accessibility problems we found. Some of the toughest challenges involved dealing with third-party code. This post presents the main problems related to third-party code and gives some details about how we fixed them.
How we use third-party code
As noted in our last post, we do almost all of the coding ourselves for the KPR main site. However, the site does include some third-party code to provide important features. This includes:
1. Two e-commerce pages generated by MyCommerce Share-it. One page allows registration for a
free trial of Compass software. The other page allows for purchase of Compass licenses.
2. A form for subscribing to the KPR mailing list, provided by MailChimp and included at the bottom of every page.
3. A blog powered by WordPress (like the post you’re reading now).
In the AT-node application, we use third-party code from Bootstrap to provide much of the CSS styling used throughout the site. We also use the Google Charts API to produce the histograms and bar graphs displayed in AT-node reports.
Aside from Bootstrap (which is great, but more of a nice-to-have), this third-party code is essential. We couldn’t provide these features without it. From an accessibility standpoint, some third-party providers make an effort to support accessibility, while others don’t seem to pay any attention to it at all.
This means that it’s up to us to understand the accessibility support of any third-party code we’re using and enhance that accessibility whenever possible. Let’s look at how we did that for the KPR sites.
MailChimp
The MailChimp subscription form gave two types of accessibility errors during our testing. First, the WAVE tool detected an input field with missing label. To fix this, we leveraged the fact that MailChimp gives us full access to their HTML markup. We embed their code directly into our pages, so we can edit it however we want. Of course, we run the risk that our edits will unintentionally break something, but in this case the risk seemed low.
The input field missing a label was actually a hidden field in the form, somehow used for spam prevention. While the missing label is technically an accessibility error, it really has no consequence, since the input field is not intended for human use. (In fact, it’s set to be hidden from screen readers using aria-hidden=”true”.) But I wanted the satisfaction of a clean sheet from WAVE, so to suppress the error, I added a ‘title’ attribute to the input field.
The second MailChimp issue was that the default styling had several visual contrast errors. For example, the default subscription button has low contrast ratio (as discussed in our last post), as do the asterisks they use to mark required fields. It was a bit surprising to find these contrast errors, given that the use of ARIA attributes in the input fields suggests that MailChimp developers paid some attention to accessibility.
To fix this, we needed to override the CSS styling rules that govern these elements. This is a bit of a hassle, but not difficult. And at least it is possible.
WordPress
Our blog theme is based on a WordPress theme that explicitly supports accessibility (the twenty-sixteen theme). So it includes things like .screen-reader-text for its ‘Learn More’ links, a Skip-to-content link at the top of the page, and various other accessibility supports. This built-in support is great, but not entirely glitch-free.
For example, the .screen-reader-text class is nice, and WordPress takes care of creating the markup that uses it. However, be aware that there is a glitch when using VoiceOver with .screen-reader-text where it reads the link segments in reverse order.
Additionally, be sure to check that the Skip-to-content link goes to the correct destination. The default destination was wrong in our case, so the link sent users off to some unexpected place. This change was straightforward to make within the WordPress page templates (header.php, in this case). But we never would have known the change was necessary if we hadn’t tested it out and inspected the code.
One last thing about WordPress accessibility. As in the MailChimp example, WAVE gave us some ‘input field missing a label’ errors from the spam-prevention fields in the WordPress comments form. The difference compared to MailChimp is that I can’t directly edit the markup for those fields. If I did want to get rid of the errors, there may be some template hooks that allow access to the markup. But it’s not immediately clear whether that’s possible. The missing labels don’t create any real accessibility issues, to my knowledge, since the affected fields are hidden on purpose from all users. At this point, I haven’t spent the time to figure this out. I hope I’m right about the fact that the errors are benign.
MyCommerce Share-it
The biggest problem is with our e-commerce pages: the form requesting a free trial of Compass software and the ordering page for Compass software. Indeed, these two pages account for the majority (60%) of the accessibility issues found in our testing. This is not unusual. Unfortunately, e-commerce pages are notorious for their accessibility problems.
Keyboard-only navigation is broken
One major issue is that the order page does not support keyboard-only navigation. It skips numerous items while tabbing through the controls, so there is no way to complete the purchase without using a mouse. The red X’s in the figure below show the 13 links and buttons that are skipped during keyboard navigation.
Poor screen reader support
Additionally, the screen reader support is poor. There are two forms on the page: one to enter billing information and one for payment information. It’s crucial for users to enter information into these forms accurately. However, as shown in the figure above, there are no screen reader labels connected to any of the form fields. When tabbing to the Email field, for example, the VoiceOver screen reader simply says “edit text, blank.” And it says the same thing for every text field. This makes it extremely difficult for the user to know what sort of information is expected.
Connecting a label properly to the field would fix that problem. With an “Email” label connected to the field, VoiceOver would say: “Email star, required invalid data, edit text.” The “Email star” represents the label with its asterisk. The “required invalid data” gives further information that the field is required and that it does not yet contain a valid value.
Can we fix the Share-it issues?
Email exchanges with Share-it suggest that they share my concerns, but so far they have done nothing to fix the problems. The interesting thing is that they seem to have known something about accessibility when creating these pages, as there are numerous ARIA attributes and alt text descriptions.
So, is there a way for me to fix it myself? As with most services, there are some hooks that give some control over the content and styling of the pages, but I can’t control the markup that they end up delivering to my site. I’ll try to figure out some creative ways of doing it, but that will take some time. Hopefully, by the time you read this, we’ll have made some progress on improving the accessibility of our Share-it pages. This may be a subject for a future post…
Are there alternatives to Share-it? Yes, but they may be just as bad, accessibility-wise, and might not meet all of our e-commerce needs. In particular, Share-it gives us the ability to accept purchase orders and ship product before payment is received. I really like this customer-friendly orientation. In searching for more accessible e-commerce platforms, I haven’t yet found one that will deliver software immediately upon receipt of a purchase order. If you know of one, please let me know!
Bootstrap
Bootstrap has paid some attention to accessibility, so you get some accessibility support built-in. For example, suppose you want a top-level navigation bar that uses a typical tribar (hamburger) menu button on a narrow mobile screen, replaced by a horizontal set of links when the view gets wider. If you use Bootstrap’s standard navbar markup, it will not only give you the responsive layout for varied screen widths, it will make sure that a screen reader can announce whether the hamburger button is collapsed or expanded. This is what we use in AT-node.
However, not everything in Bootstrap meets accessibility standards. So you still need to do some testing for things like contrast ratios and keyboard navigation. For keyboard navigation, we found that the hamburger nav button, which was so carefully coded for some aspects of accessibility, had no visible focus styling when we tabbed to it. So, a sighted user, using keyboard navigation for convenience or to accommodate a physical impairment, would have no way of knowing when the nav button was focused and ready for activation.
It turns out that Bootstrap sets the .navbar-toggle:focus style to have no visible outline (outline:0). There is probably a reason for this, but for our keyboard navigation case, it creates an accessibility problem. What we want is for the nav button to have a focus state that looks like every other focusable item on the screen. Normally a problem like this can be remedied by a simple CSS override. In this case, it’s not straightforward.
Since we can’t override Bootstrap’s rule to use the default browser style, we used outline:auto instead. The nav button does visually focus now, but it doesn’t look the same as the other focused items. So this is really a temporary solution. To ensure consistency across all focusable items, we’d need to create :focus styles for all elements. That would take additional time that we don’t have right now.
Google Charts
The Google Charts code in AT-node was the source of a tricky accessibility challenge (read our previous post for more details). WAVE detected this error: “Empty table header. A table header (<th>) contains no text.” The offending <table> element was nested fairly deep inside the markup produced by Google Charts. We were eventually able to figure out the problem and make sure that the table header information was correctly included in the table.
The interesting thing here is that without the WAVE tool, we never would have found this error. We had no idea there was even a <table> element inside of the chart code.
Bottom line
- Don’t assume that brand-name companies always deliver accessible solutions. Third-party code can introduce unexpected issues.
- When the third-party provider gives you full access to the markup code, it is much more straightforward to fix accessibility issues.
- Some fixes can be accomplished by overriding styles of the third-party code, but it would be great if we didn’t have to spend time doing that. And not all styles can be easily overridden.
- E-commerce pages are the source of almost all of KPR’s accessibility issues. We’re still searching for an e-commerce provider that will meet all of our needs, including accessibility.
Have you faced similar challenges when working with third-party code? If you’d like any more details about what we did, please let us know!