Mockup of laptop with redesigned website along with other interfaces of the redesigned website displayed stylistically

Reimagining Squarespace for Accessibility

PRODUCT DESIGN • UX DESIGN • UI & VISUAL DESIGN • PROTOTYPING • ACCESSIBLE DESIGN

ROLE

Product designer

High fidelity prototype evaluated with users
First place 🥇 at Design Frontiers

TIMELINE

May 20-26, 2021

TEAM

2 Product designers
2 User researchers

RESULT

Overview

Product Design at a Glance

Many websites are inaccessible to users with visual impairments, despite the array of digital creation tools that exist today. To tackle the challenge of “How might we empower creators to make more accessible websites for the low-vision/blind community?”, we re-imagined the popular website creation and content management system (CMS), Squarespace, focusing on preventing the most common accessibility failures.

Proactive Education

Build awareness & empathy by incorporating information, tips and videos to educate users

Mockup of a laptop with the user interface giving educational tips on the Squarespace prototype

Automatic Check

Help users immediately detect, fix & learn from mistakes

Mockup of a laptop with the user interface showing the automatic contrast checker on the Squarespace prototype

Accessibility Panel

Centralize all accessibility fixes in one convenient location

Continue reading to take a deeper look at the design process

Problem Discovery

Dialogue with Community Advocate

The project began in dialogue when a member of our team met Jimmy, the UCSD disabilities specialist, and member of the low-vision/ blind community. He said that many individuals are unable to navigate websites created using CMS using screenreaders, & often require the aid of sighted users due to lack of accessibility.

Secndary Research

Lack of Accessibility Hurts Users and Business Owners Alike

I conducted the initial research around the problem space and found that according to a 2020 analysis of 1 million home pages, WebAIM found that 98.1% had home pages with at least 1 accessibility failure based on WCAG 2.0, and there were an average of 60.9 errors per home page.

Graph showing the most common accessibility issues by percentage of home pages (sourced from Global Accessibility Awareness Day)

Thousands of small business owners use Squarespace, yet Squarespace lacks accessibility support, alienating users with visual impairments. Lack of accessibility can hurt their bottom line since e-commerce sales have an expected value of $722.64 BN in 2021, and the revenue is expected to grow due to COVID-19.

1,000,000,000+

14,000,000+

Individuals with disabilities worldwide

Individuals with visual impairments (USA)

1,000,000+

18,000+

Squarespace users

Squarespace online stores

Exploratory Interviews

Low-Vision and Blind Users are Frustrated Navigating the Web

The user researchers conducted interviews with two members of the low vision/blind community. My co-designer and I helped create the interview protocol.

Jimmy expressed frustration when using Squarespace to create his own website, requiring workarounds to deal with a lack of accessibility features.

Jason, a blind developer, often requires the aid of his sighted partner to navigate sites. He manually tweaks his screenreader to skip pictures due to lack of alt text.

Key Takeaways

Web accessibility frustrates and prevents users with screenreaders from navigating sites
CMS services need to include accessibility features
CMS users need to be educated on accessibility issues, and prompted to make their sites accessible

Solution Ideation

Finding a Solution with the Greatest Social Impact

Browser Extension

A browser extension to evaluate website accessibility i.e. WAVE, or to describe images and alt text, similar to plug-ins such as a11y and hypothes.is.

PROS

Can address issues across multiple sites, not just sites created with a specific CMS like Squarespace

CONS

Without prior awareness of accessibility, users have little incentive to seek out a browser extension to address issues
Is a retroactive fix, rather than a part of the site design process

Redesign Squarespace

Integrate accessibility awareness and checks into the already existing Squarespace interface.

‍

PROS

Squarespace has a large pre-existing user base with over 1 million users
Thousands of pre-existing small business already employ Squarespace
Provides opportunity to incorporate accessibility during the design process

CONS

Little opportunity for accessibility improvement on the creator-side

New CMS Service

Build a competitor CMS from scratch incorporating accessibility features, similar to Squarespace, Wix, Weebly, and other services.
‍

PROS

Presents the opportunity for accessibility improvement on both the creator AND consumer side

CONS

Does not address the thousands of websites already created through competitor CMS services
Difficult to compete with established CMS services with large existing user base

Solution

Ultimately, our team chose to redesign Squarespace because of the low barrier to entry and the ability to leverage the pre-existing user base and website creation features already built into Squarespace’s platform.

Many individuals have little awareness of accessibility issues or what accessible online content means. These users would be unlikely to download a browser extension or choose a new CMS service based on accessibility features. This solution also has the potential to create the greatest social impact by taking advantage of the pre-existing user base. As a prominent CMS service, Squarespace sets an example for other CMS companies, modeling whether or not accessibility is worth prioritizing.

Goals

Since Squarespace acts as the first introduction to web design for many users, our “North Star” was to provide accessibility features within Squarespace, but design it as an entry point to web accessibility awareness and education. In doing so, we had 4 main goals:

Empower users to easily design accessible websites

Allow users to learn from their accessibility mistakes

Build empathy for screen-reader users’ experience

Increase awareness & education about accessibility

MY ROLE

I designed the full user flows and UI for the contrast checker, the alt text checker and the grayscale checker. I also was responsible for the visual design of the completed website, and ensured overall consistencies between styles. My co-designer designed heading levels, the accessibility panel and the final check as well as the ‘guide’ avatar within the prototype. We both wired the prototype, while I also focused on small details to ensure a consistent and immersive prototype experience.

Design Process

Explorations & Iterations

For our low contrast checker I ideated three locations to provide the user with appropriate feedback about the level of contrast between the text and the background. Once the user flow was established, I ideated two potential designs to display feedback about the contrast ratio. After conducting a preliminary user test between the two options, I made further improvements to the design. Mid-fidelity mockups and final designs displayed below.

Exploration 1: User Flows of The Contrast Checker

An example of a potential user flow for the contrast checker with low-fidelity wireframes. The user can click on the error symbol to get feedback on the contrast level in the pop-up message.

Ideation 1: Display Contrast Feedback within Error Message

This option gives the user specific feedback about the error state directly in the error message. This option is most discoverable; however, the user will only get feedback about contrast when there is an error and would need to open the error message to view it.

An example of a potential user flow for the contrast checker with low-fidelity wireframes. The user can click on the error symbol to get information on the error, but the contrast feedback is located in the text styles bar in a separate button.

Ideation 2: Separate Contrast Checker in Editing Toolbar

This option provides a separate button that is dedicated to checking contrast. This allows the user to check contrast at any time; however, it adds an extra step that the user must take to view specific information about the contrast ratios.

Ideation 3: Display Contrast Feedback within Colour Picker Tool

This option provides the user with feedback about the contrast ratio while simultaneously selecting colours from the toolbar. It also keeps the error message simple and better aligns with the other user flows based on detected errors within the prototype.

Final Design

The final design embeds the feedback about the level of contrast within the colour picker. The error message takes the user directly to the colour picker where they can view information about the contrast and change the colour simultaneously.

Exploration 2: Interface Designs for Contrast Checker

A quick A/B user test with an individual unfamiliar with accessibility revealed that the initial ideations didn’t meet the needs of our users. Both designs that displayed contrast ratio values were too complicated and use of jargon lead to confusion. I realized that the user did not need to know the specifics of the contrast ratio in order to meet the accessibility requirements, rather, the user only needed to know whether the contrast was sufficient or not. In my next iterations I simplified the design as much as possible.

Two mid-fidelity wireframes showing potential ideations for the contrast checker. The contrast checker provides feedback about the contrast values for the recommended ratio between the text and the background.

Ideation 1: Displaying Contrast Ratio Values

The option on the left clearly states the value of the contrast ratio between the background text compared to the desired ratio for best accessibility, whereas the option on the right omits the numeric values and instead more clearly states the accessibility error.

Two mid-fidelity wireframes showing potential ideations for the contrast checker. The contrast checker provides feedback about whether low contrast is detected or if there are no accessibility issues.

Ideation 2: Simple Pass/Fail Feedback

In this ideation, I played around with only letting the user know whether there was an accessibility error or not. However, this design still uses more technical phrasing.

Two mid-fidelity wireframes showing potential ideations for the contrast checker. The contrast checker provides feedback by answering a simple yes or no question of whether the contrast is sufficient

Ideation 3: Simple Question & Answer

In this design, I tried to simplify the information even more by asking and answering a single question. This option more directly lets the user know whether there is enough contrast. However, the feedback statements, ‘yes’ or ‘no’ were not clear enough statements for the user.

The final interface design for the contrast checker. The contrast checker provides simple feedback of whether the contrast is acceptable.

Final Design

For the final design, I combined aspects from the previous two ideations; however, I provided more descriptive details in the feedback statement. I included recognizable symbols and used a darker green colour to ensure sufficient contrast between the written text and the background.

Design Decisions

Consistency with Squarespace

One of the things I was cognizant of throughout the design process, was that our solution involved integrating additional features into an existing software service, with established workflows, interface design, visual language, and visual aesthetic. While designing, I made it a priority to maintain consistency with Squarespace as much as possible in these areas.

Workflow of Added Features

Squarespace’s Native Workflow for Adding a Header Image

This showcases Squarespace’s native workflow for adding a header image, along with the options provided in the edit image menu.

Workflow for Adding Alt Text in Prototype

We seamlessly embed the option to add alt text and a caption to the header image in Squarespace’s edit image menu.

Comparison between Squarespace's menu for adding a picture and the prototype's redesigned menu that allows the user to input alt text

Squarespace's Menu and the Redesigned Menu

The following images compare screenshots from Squarespace’s interface (left) with our redesigned image editor (right).

One decision I faced was where to integrate the option to add alt text to images. One option was to allow the user to hover over the image and have the button to add the alt text appear. This style would be similar to other websites such as Medium, and would be immediately discoverable for the user. However, Squarespace uses this button-on-hover option to edit sections and photos and multiple buttons while hovering would likely confuse users.

The second option was to nest the alt text option within Squarespace’s “Edit Image” pop up. This solution was chosen because aligns with Squarespace’s current workflow (shown below). While this option may not be as initially discoverable for the user, omitting the alt text would trigger feedback for the user to improve the site’s accessibility, leading to the desired end result.

Interface Design

Comparison between Squarespace's site styles panel and the prototype's accessibility panel

Site Styles Panel and Accessibility Panel

The accessibility panel (right) was designed to reflect the visual design of other features within Squarespace, such as the site styles panel (left).

Comparison of a pop-up message in Squarespace's interface and a pop-up message in the redesigned prototype.

Confirmation Messages and Error Messages

Similar styles for confirmation messages were adopted within our prototype (right) compared to styles already used within Squarespace (left).

In addition to maintaining a consistent user flow to Squarespace, I ensured our designs maintained a consistent visual language to Squarespace in the user interface. This can be seen in the button designs, pop-up notifications, hover states etc. However, some liberties were necessary for the context of our prototype e.g., Squarespace uses a proprietary typeface.

Visual Design

Screen capture of the Squarespace interface with a generic template website

Squarespace’s Template Website

The above image showcases a basic template site generated on Squarespace which was used as a reference for our initial prototype design.

Screen captures of the initial prototype interface with a yellow gradient background

Initial Template Website for Prototype

The above images show the initial mid-fidelity mockups of the template website designed by my co-designer. I redesigned the prototype to improve the visual aesthetics. The content of the website was not fully fleshed out, there was no cohesive story, and the colours of the gradient background and overall website design were not visually appealing.

Screen captures of the final prototype interface design with updated visuals and a clean aesthetic

Final Template Website Design for Prototype

I redesigned the visuals, style and content of the ‘example’ website for the high fidelity prototype. The visual redesign was essential to convey the feel of Squarespaces’ branding, while the cohesive story told through the ‘travel blog’ was important to fully immerse the user in our prototype. Overall, the visual redesign elevated the feel of our final prototype for a more refined experience.

Another aspect of visual design that I explored was the look of the ‘example’ website in our prototype. Squarespaces’ branding emphasizes the importance of building visually beautiful websites as shown on their website, “Squarespace is the all-in-one solution for anyone looking to create a beautiful website” and through their previous ad campaign slogan “Build it beautiful”. Therefore, our prototype would also need to align with the sleek and minimalist website templates synonymous with their branding style.

User TEsting

Prototype Increased Users' Knowledge & Awareness

The user researchers tested our prototype with two fully sighted, 23-24 year-old individuals who had previously used services like Wix, Weebly or Wordpress, but had no experience with Squarespace. More users were not tested due to time constraints. The user testing protocol was developed by the user researchers in collaboration with myself and my co-designer.

After using our prototype, participants revealed they learned about accessibility terms and issues, and how they help individuals from the low-vision blind community.

“I like how it gives off error messages as a reminder for me to better design my websites with accessibility. I have never encountered anyone with disability nor wonder how [they access] online services.”

“I did not know anything about accessibility or [that we] have that integrated in our phones or computer! ... This brings a whole other perspective of how they can use these features or even how I can benefit from these features!”

Users Need Context and Simple Phrasing for Accessibility Tools

Prior to using our prototype, most participants had little to no knowledge on web accessibility, including associated terms due to a lack of public awareness on this topic.

"What is accessibility? I have never heard of it".

User testing highlighted areas in our prototype that overloaded the participant with information and used too much technical jargon. Our user testing also revealed a larger social layer to the problem space; a general lack of public awareness about accessibility issues. The most striking example of this is that our users thought the term “screenreader” (an assistive technology to help individuals in the low-vision/blind community navigate online spaces) referred to themselves since they were the ones ‘reading the screen’.

Key Takeaways

Technical jargon and information overload should be avoided
Users need to be educated about the context and importance of accessibility features
Users should be encouraged to empathize with and understand screenreader users

Design Changes

Implementing User Testing Insights

Reducing Complexity

Contrast Checker

Through user feedback, the design on the left was found to be overly complex. The redesign on the right, simplified the design to provide the user with only the necessary information and avoided the use of technical jargon i.e. specific numeric ratios.

Educating Users

A screen capture comparing the original design of the grayscale and contrast check panel and the redesigned version with more information and an additional information icon for extra information

Grayscale Checker

During testing, users said that they didn’t understand the ‘why’ behind checking their site in grayscale. I realized this was an opportunity to provide additional information using a clickable icon. This design provides the user with the ability to read extra information without overloading the panel with unnecessary information.

Empathizing with Screenreader Users

Heading Levels

Users revealed that they knew very little about the challenges individuals in the low-vision and blind community may face when navigating websites online, and therefore lacked a mental model of screenreader navigation. To address this, we added videos showcasing how screenreader users would interact with site elements. The video helps users better empathize with screenreader users and understand the impact of accessibility.

Final Design

Prototype Features & Design

Our features guide users to avoid the most common accessibility failures. Individual accessibility features can be grouped into 3 main categories: proactive education, automatic check and the accessibility panel.

Proactive Education

Simple explanations and information about each feature were included throughout the inform users and increase awareness. User testing revealed that users lack a mental model of how screenreaders work, so we included videos with additional tips.

Heading Levels

We notify the user when there is a missing heading level, explain why this impacts accessibility and provide an easy shortcut to fix it.

In our example Heading Level checker, we include:

A description of what heading levels are
A description of why they are important
A video showing a screenreader user interacting with headings

So the user can identify their mistakes, learn from them and immediately fix them.

Automatic Check

Auto-check automatically detects accessibility issues and prompts the user to make changes. This allows the user to proactively identify issues during the creation process, and manage accessibility in bits rather than complete a retroactive check at the end.

Contrast Checker

The user is immediately notified of low contrast between the text and the background and they are immediately taken to the color picker to correct it. Positive feedback lets the user know when the issue is corrected.

Alt Text Checker

The alt text checker notifies the user that the image lacks alt text and they are taken to the input field to provide it.

Missing alt text was one of the frustrations most emphasized by our initial exploratory interviews and the 2nd most common accessibility error indicated in the secondary research I conducted. Future iterations could automatically generate alt text for images in place of user generated text.

Accessibility Panel

All accessibility fixes were centralized into one convenient panel, in line with Squarespace’s existing design patterns.

Grayscale Checker

This feature allows the user to review their site in grayscale to ensure that all pertinent information is conveyed without solely using colour. The same location in the panel also hosts the colour contrast checker.

Final Check

The user is notified of any unresolved accessibility issues, after they finish creating or editing their page. The ‘General Check’ tab ensures the user can view all issues from a single location, and easily fix them before they exit the editor.

View Full Prototype in Figma

Next Steps

Future Project Improvements

Address social layer of awareness and education. Our design provided website creators with the tools and basic knowledge make their sites more accessible; however, user testing revealed a larger problem of the disconnect between everyday users and those with increased accessibility needs. While we baked in tips relating to accessibility throughout our design, those with no knowledge of accessibility got confused about the meaning of accessibility itself.

Squarespace's side panel with the word accessibility and an arrow pointing to a spot on the panel

Prioritize other features we haven't yet addressed, e.g. aria labels, form labels, etc.

This could be addressed in another area of Squarespace prior to website editing e.g. highlighting accessibility during onboarding for site creation, or providing a section within the initial website management menu dedicated to education and resources, like a small tutorial or educational course.

Build accessibility for creators so that screenreader users (like Jimmy) can easily create an online presence to market and express themselves, not just consume.

Reflection

Lessons Learned

Overall, this design-a-thon was a great experience and I learned a lot working with my co-designer on product design as well as leading the user researchers. Not only did I learned more about accessibility challenges for online websites and lack of resources within content management systems, but I also learned more about design processes.

Remote Work & Communication

Our team worked entirely remotely from 3 different time zones, which meant we had to adapt to the challenges of both synchronous and asynchronous online communication and documentation by using a variety of tools such as Discord, Loom, Zoom, Notion and Figma.

Adapting to Limited Time & Resources

Given the short-time frame of the designathon we traded some efficiency for more time spent getting right into the work. For example, to save time near the start, we didn’t fully flesh out a style guide but worked simultaneously on the project and made retroactive fixes.

Similarly, due to being short on time and resources we were unable to do a lot of user research prior to prototyping and the lack of public awareness and education was made apparent through user testing. I think we could have had a better understanding of the users’ knowledge with more time spent researching upfront.

Make it Simple

In our final prototype, we removed some of the features we had planned and even partially prototyped, in order to simplify the user testing experience and tell a more focused story about our design. While the final prototype had less features, it taught me that sometimes simpler is better.