CEROS STUDIO

CONTENT ACCESSIBILITY INITIATIVE

Ceros is a SaaS platform that allows users to create interactive web content without the need for code. Content is created in a web-based design app called Studio, and the designs are converted to code and hosted by Ceros. Studio did not have a robust system that allowed designers to create accessible digital content effectively, and as clients’ concerns about providing such content began to grow, the decision was made to develop a feature set designers could utilize to ensure their output met accessible web standards. Since Ceros’ main business objective is to provide a codeless, free-form design platform for creating and hosting digital experiences, all accessibility solutions would need to refrain from limiting the platform’s openess while meeting accepted accessible web content expectations.

ROLES

Research, Information Architecture, UX Design, UI Design, Testing, User Working Group

INITIAL RESEARCH

There were two main research initiatives that needed to be tackled - we needed to conduct user research of course, but we also needed to do our own research on accessibility standards and tools in order to understand what we needed to solve for and why.

TEAM RESEARCH

My team began compiling sources and documentation to ensure we had the best understanding of accessibility standards and the various tools available to aide users. Additionally, we conducted analysis on other web content creation platforms to see how they were handling accessibility. We also paired with a third-party vendor that specializes in accessibility initiatives. They helped us understand the legal applications alongside best practices and the expectations of users who rely on assistive technologies while teaching us how to use a number of assistive tools properly so we could design, test, and implement solutions with confidence.

USER RESEARCH

Parallel to our internal investigation, we created a working group consisting of clients who had expressed interest in accessibility and conducted user research with them to understand how much knowledge they had of web accessibility, the tools used, and how it would affect their design process and content creation. We were eager to learn about how they felt their workflows would change and what steps they planned to take in order to ensure the content they were publishing would be considered accessible.

EARLY USER DATA

When our first round of user research data was synthesized, we were able to identify some trends we could use to help us decide how to proceed with the initiative.

Key Takeaways

There was limited understanding among clients what was actually necessary to reach accessibility standards, even though most teams felt it was important to meet them
Clients were much more aware of accessible visual design principles (contrast, text size, etc) than the necessary content structuring and tagging needed for assistive technologies
Designers would be generally responsible for understanding the accessible design principles and applying them correctly
Most teams did not have an accessibility expert on hand and would instead rely on screening tools to alert them when they did not meet passable accessibility criteria

SCOPE

Considering our internal and user research alongside our technical limitations, platform systems, and the accessibility criteria, we decided to provide users the means to create and publish WCAG (Web Content Accessibility Guidelines) 2.0 compliant content. Although WCAG 2.1 was becoming the standard, we knew we would not be able to achieve one of the main requirements for that level, which is text reflow. Ceros is not built to create responsive web content, instead relying on adaptive layouts to correctly serve various device sizes. In order to provide the ability for designers to create responsive sites with text reflow, the Ceros Studio would need to be completely rebuilt, and at this time, that was well out of scope.

The rigidity of WCAG 2.0 really set the overall scope for the initiative, since we would need to complete all features necessary for users to reach compliance. We did however decide to add some functionality outlined in WCAG 2.1 into our scope to get as close as we could, since we knew it would make for better accessible experiences.

REJECTED MODELS

One option we investigated but decided against was moving to a component-based system in Studio that would look closer to what Squarespace and Wix were doing. However, the idea of components had never been particularly popular with stakeholders, as they felt it went against the core mission of Ceros. On top of that, we would need to create all the components and develop a management system so they could be accessed and edited, which would have taken up too much time and too many resources.

Another idea was to create a completely separate “accessibility mode” in our Studio. Users would move into this mode to do any accessibility related tagging or organization. This idea was scrapped because there was a lot of grey area between certain object properties that could be accessibility but also might not be. It was also a little strange as a mental model and ultimately didn’t offer a ton of benefit compared to handling accessibility updates in the current Studio model.

ACCESSIBILITY UPDATES & FEATURES

Providing the means to reach WCAG 2.0 compliance would be done by reworking our published content structuring and rendering while providing a set of features in Studio that designers could utilize to ensure accessible page navigation and proper screen reader performance. These features would try to remain as close to our current interaction model as possible, and they would be released to an accessibility working group in a Beta program so we could get feedback and conduct testing. In addition, we would develop training for the new features that could be shared with clients to help guide them.

ACCESSIBLE NAVIGATION

Proper keyboard and screen reader navigation methods are imperative to reach compliance, and we needed to find a way to ensure content created in Studio’s free-form manner would adhere to the expectations of users utilizing those mechanisms.

In order to accomplish this, we started by modifying the DOM structure of published experiences to more closely match the visual ordering of the content, applying <button> tags to any object containing an “On Click” interaction (the concept of a “button” did not previously exist in the content output), and designing a system to toggle focus on elements shown or hidden with clicks and hovers so both users and screen readers could move into newly displayed content at the correct time.

We also gave designers the ability to apply standard HTML element tags to headers and blocks of content. This made it easier for users to move through various sections of an experience using keyboard navigation while also benefiting screen readers. Once section tagging was available, we were able to add a Skip to Main Content function, which allows a user to immediately focus on the content wrapped in a <main> tag.

SCREEN READER OPTIMIZATION

In addition to the visible text on a page, screen readers rely on a good deal of material that isn’t actually rendered for a sighted user in order to provide the best experience. Because of this, it was necessary for designers in Studio to have a means to add this information, so a number of tools were implemented.

At the highest level, a screen reader needs to understand what language is being presented so it can pronounce words effectively. Studio previously had no way to change the default HTML <language> tag to something other than English, so a method was added.

Screen readers can use aria-labels to describe content that relies on visual cues to users, so we designed and implemented a way for designers to add these to objects created on the Studio canvas.

True inline links were lacking in Studio, and users needed to manually create click interactions on text boxes that opened other pages. This was tedious for designers creating non-accessible content, but it was even more problematic for designers creating content for screen readers. There was no way for a screen reader to understand something was a inline link within the context of the surrounding text, so that needed to be addressed.

VIDEO ACCESSIBILITY

Designers using Ceros Studio can upload video files into the digital experiences they create, but they could not add accessibility aides like closed captioning. In order to include closed captioning, we had to replace the video player that Ceros had been using, which meant a designs for a new video player UI were needed alongside designs for the closed captioning feature.

FEATURE LIST

Toggle Reduced Motion
Accessibility Account Activation
Accessibility Experience Toggle
Video Player UI Update
Video Closed Captioning
Aria Labels

Skip to Main Content
Pinch-to-Zoom
HTML Language
Screen Reader Only Text
Hide Text from Screen Readers
HTML Semantic Element Tags

Zoom Control Overlay
Published Page Titles
Inline Links
Transient Content Focus
HTML Text Tags
Button Tags

ACCESSIBILITY VENDOR FEEDBACK

As we moved through this initiative, my team was in constant contact with our contracted third-party accessibility experts. This was extremely beneficial, as we were able to get clarification on various accessibility standards when needed while also getting direct feedback on our accessibility features as they were designed, prototyped, and built out. Their input helped us validate our solutions and ensure that the content output would fall within all necessary accessibility guidelines.

USER TESTING & FEEDBACK

Throughout each feature’s design and implementation, we were testing with users and looking to gain feedback, not only on each individual solution, but on the overall accessibility implementation. As this process continued, we got feedback on the actual patterns and interactions of the features while additionally starting to gain a more realistic idea of how much time and effort users were willing to put into designing accessible content, which allowed us to make decisions on feature depth and scope while making any necessary iterations.

Unfortunately, once users had the entire suite at their disposal in our Beta program, it became even more apparent that people were not sure how they should go about making accessible content on the most basic level. We were told time and time again that they understood how each feature worked, but they were not feeling confident in the way they were creating content or making sure they had ticked all the boxes necessary to be compliant, even if using scanning software. Furthermore, clients were concerned they would need to dedicate too much time learning how create the actual content.

EDUCATING USERS

Providing user education on how to use the accessibility feature set was always part of the plan, but the information we were getting from clients in the Beta program relating to general accessibility best practices and time to value made us realize we would need to provide more robust resources to clients in order for the initiative to reach its full potential. The Product Team worked closely with our Education Team to develop an education plan for those interested in using the accessibility features.

Early on in the initiative, my team made a decision to control the majority of accessibility features via an account level flag which would allow Ceros to toggle access to the features for individual clients when they wanted to enter the Beta program. However, we used this to our advantage even as we moved out of Beta. Since there was so much confusion and concern about accessibility best practices, my team (along with other stakeholders at Ceros) felt it would be best to require training before a client could use most of the new features. In addition to the educational materials provided on Ceros’ website, which my team developed with the Education Team, the trainings helped familiarize users with the available features as well as overall best practices when creating accessible web content.

ACCESSIBILITY WORKING GROUP

In order to continue our learnings once people started to get their hands on the new features, we continued discussions with our working group comprised of clients designing accessible content. Once a client opted in to the group, they agreed to provide us with further feedback and be available for followup interviews. In return, they got Beta access and received updates on new features and propsed changes to those already existing once the features were part of general availability. They were also getting a direct line to the Ceros employees in the working group (which included myself). The information we gained from these select clients during and after the Beta was very valuable and included things that worked well, pain points they were experiencing, feature requests, and updated workflow behaviors that were put in place once utilizing the features.

IMPACT

The accessibility initiative is ongoing, and the team continues to iterate on features and prioritize next steps based on feedback and business needs. The first phase was very successful, leading to an increase of new contracts and renewals as clients begin to focus more on providing accessible web content. It has also now become more important to take accessibility into account when designing new features for our own products.