It all started with us submitting a support ticket.
No threats. No demands for escalation. Just a simple support ticket.
We know that’s not the answer most people expect with Americans with Disabilities Act (ADA) lawsuits driving media attention. Most would assume we threatened or demanded escalation to get the co-founder’s attention. But here is a story about the value of reporting accessibility issues and exceptional customer support.
Equal Entry was working with a government agency to update its web accessibility guidelines. We created web pages to explain specific Web Content Accessibility Guidelines (WCAG) success criteria and provide real-world examples from their own sites.
We opted to show code samples via CodePen embeds. CodePen is a web application and library. It provides developers with an environment to write code in their browser and see the results as it’s being built. In short, CodePen embeds can show formatted HTML and its rendered results.
This worked great in most cases. However, a few embeds failed automated accessibility checks. Specifically the axe scrollable-region-focusable rule.
When the CodePen contained a large HTML or Results area, it automatically added scroll bars. But keyboard users could not tab to and then scroll these elements. We also found that the preview content which contained actionable elements wasn’t keyboard accessible.
A quick internet search found CodePen Support. After some research within the documentation, we contacted Support with the following message.
“While we LOVE CodePen — we have some accessibility concerns about the Embeds. Specifically the addition of scroll bars to the HTML or Results — do not allow a sighted keyboard user to gain focus and scroll the content. Embed v3 provides a zoom capability for the Results, but does not auto-select the option that would not require scrolling, nor is there a way to overwrite the default 1x. Please consider this in future improvements.”
No threat, no demands, just a straightforward request for future improvements.
Not surprisingly, the first response was a request for clarification … But what was a surprise was that the response came from none other than Chris Coyier. Chris is the co-founder of CodePen and active in the front-end development community. It means a lot to hear from him because it sends the message that the organization cares about accessibility.
We had an ongoing email exchange with Chris for about a month. He and his talented team made changes that improved the accessibility of ALL embedded CodePens. AND without requiring the authors of the pens or the page to make changes!
In our correspondence with Chris, we discussed the following specific issues and we created a CodePen Embed test page to provide the CodePen team with the reproducible steps to help them understand the issues
- CodePen Embeds didn’t support keyboard scrolling.
- CodePen Embeds didn’t support navigation to Preview actionable elements.
- Request to have CodePen Embed option to load Embed with 0.5x or 0.25x as the default Result zoom level.
- Request to fully label — “Edit On CodePen” button — it was originally read by screen readers as just “Edit on” with the CodePen graphic hidden as an SVG element with no text alternative.
1. No support for keyboard scrolling
Issue 1 is the overarching issue that caused us to reach out to CodePen. It appeared on multiple pages in which we had embedded CodePen showing our client’s issues and how to fix them. This issue also occurred on all three of the embeds we created on the CodePen Embed test page.
- Test 1 was horizontal scrolling of the HTML.
- Test 2 had scrolling of both the HTML and Results.
- Test 3 showed Results that added both horizontal as well as vertical scrolling.
2. No support for navigation to preview
Issue 2 appeared on several client pages and is represented via Test 1 and Test 2 on our test page. Test 1 has a skipped link within the results that couldn’t be activated by the keyboard. Test 2 is an embedded CodePen showing how a fixed header needs to accommodate for keyboard focus. So, it requires the user to tab through all the elements within the results or preview window.
The only way we could get focus into the preview results was to use the mouse and click into one of the edit boxes. From there, the user can tab between the edit boxes and see that the header works correctly.
3. Embed result zoom level not pre-definable
We discovered Issue 3 when creating examples to test color contrast of text over images. We embedded an example of Test 3. The image is so large that the text on the image can’t be seen.
4. “Edit On CodePen” button not correctly labeled
We found Issue 4 on every CodePen embed. You can refer to any of the three test embeds to find the Edit on CodePen button. The “CodePen” logo originally showed up in a way that hid it from screen readers, which caused the button to be announced as just “Edit on.”
If you want to see this in action, play with the CodePen Embed test page.
We were happy that CodePen addressed issues 1, 2, and 4 without making any changes to the page. We ultimately decided that while the ability for an author to define the zoom level of the results was related to accessibility, it was more of a feature request.
CodePen later solved this with “data zoom,” which was added to Embedded Pens Override Attributes and requires author modification of the embed code.
Everyone, please take the time to report accessibility concerns! If there are issues impacting you, they are most likely impacting others. And you’d be surprised how a company may respond. Teams like CodePen want to have an accessible product that can be used by many people, but they need feedback to ensure it happens.
Developers can encourage individuals to report accessibility concerns by doing the following:
- Make the process of reporting accessibility issues easy.
- Follow up quickly with those who report issues.
- Fix issues to benefit more than the person who reported the issue.
- Share stories of accessibility issues reported and how they were resolved.