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.
The Situation
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.
The Request
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.
The Response
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!
The Details
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.
The Results
See the Pen
Floating Header – focus is kept within the visual space on the page – Positive Example by Equal Entry LLC (@EqualEntry)
on CodePen.
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.
The Lessons
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.
Thanks for this article Heather! These enhancements to CodePen are very welcomed. A couple of questions.
1. Should the skip-links be presented before the HTML button with perhaps an option to skip inside the Results frame?
2. Should the Rerun button set the focus back to the beginning of the CodePen box?
Marcelo, glad you liked the article and the results 🙂
To your questions, we actually spend a bit of time weighing the pros and cons of a skip into (as the only means to get focus into the results Iframe) vs a skip over feature (as an option to avoid). We ultimately decide that a sighted keyboard users might be holding the `Tab` key down and find it more difficult to find and activate a skip into link, when they are looking for focus to enter a CodePen result iframe. Where a skip over is really only necessary if the preview has a very large number of links or a keyboard trap. Our logic was that it would only take once for the user to then slow down to find the needed skip over link. As to where the “Skips Results Iframe” appears we were trying to improve without changing the current users expectations with regard to embedded CodePens.
“Rerun” button was actually never discussed. I think of myself as pretty CodePen knowledge-able but I have to admit I’ve never used that button. I think you might have another excellent suggestion to offer to CodePen support!
Thanks,
Heather
Web accessibility is a team effort, well done Equal Entry and CodePen. No fights, no arguments, just achievement.
Thanks for the comment Chris! We love getting them and I couldn’t agree more. It sometimes feels like accessibility is always an uphill battle, so when collaboration is smooth and yields such fast results it’s inspiring!