Website Builders Still Contribute To Inaccessible Web Design

Abstract

Website builders enable individuals without design or technical skills to create websites. However, it is unclear if modern websites created by website builders meet accessibility standards. We reviewed six popular website building platforms and found a lack of accessibility support. Wix provided the most comprehensive accessibility documentation and robust accessibility features. However, during an accessibility audit of 90 Wix webpages, we found many accessibility issues, raising concerns about how users are supported.

Full text

Website Builders Still Contribute To Inaccessible Web Design
Athira Pillai
athirapillai@mail.rit.edu
School of Information
Rochester Institute of Technology
Rochester, New York, USA
Kristen Shinohara
kristen.shinohara@rit.edu
School of Information
Rochester Institute of Technology
Rochester, New York, USA
Garreth W. Tigwell
garreth.w.tigwell@rit.edu
School of Information
Rochester Institute of Technology
Rochester, New York, USA
ABSTRACT
Website builders enable individuals without design or technical
skills to create websites. However, it is unclear if modern websites
created by website builders meet accessibility standards. We re-
viewed six popular website building platforms and found a lack
of accessibility support. Wix provided the most comprehensive
accessibility documentation and robust accessibility features. How-
ever, during an accessibility audit of 90 Wix webpages, we found
many accessibility issues, raising concerns about how users are
supported.
CCS CONCEPTS
• Human-centered computing → Accessibility.
ACM Reference Format:
Athira Pillai, Kristen Shinohara, and Garreth W. Tigwell. 2022. Website
Builders Still Contribute To Inaccessible Web Design. In The 24th Interna-
tional ACM SIGACCESS Conference on Computers and Accessibility (ASSETS
’22), October 23–26, 2022, Athens, Greece. ACM, New York, NY, USA, 4 pages.
https://doi.org/10.1145/3517428.3550368
1 INTRODUCTION AND RELATED WORK
Websites continue to be inaccessible [
11
,
13
,
14
,
20
]—a 2021 audit
found 97.4% of 1 million home pages had at least one Web Con-
tent Accessibility Guidelines (WCAG) violation [
22
]. Novice web
designers who use website builders likely have little accessibility
training and knowledge since accessibility skills are even lacking
among professionals [9, 16].
Website builders help individuals to create appealing websites
without requiring design or technical knowledge. Authoring tools,
such as website builders, also have the potential to support the cre-
ation of accessible web content [
10
,
15
,
17
,
18
,
23
]. However, a 2007
study found Apple’s iWeb website builder and its preset templates
had a distinct lack of accessibility conformance and features [
17
].
The study advocated for improved accessible web design support.
We assess whether current website builders have improved. We
evaluated the documentation of six popular website builders for ac-
cessibility support. We found that Wix (wix.com) was the platform
with the most explicit support for accessible web design. We then
conducted accessibility audits for 30 websites (90 pages in total)
created using Wix.
We found websites created by Wix had poor accessibility de-
spite Wix oering the most accessibility support out of the six
popular website builders. We expect a higher case of inaccessibility
when using other website builders since they were less focused
on supporting accessible web design. Future work should utilizes
User-Centered Design methods to identify how to improve website
builders to increase user engagement with accessibility features.
2 UNDERSTANDING ACCESSIBILITY
SUPPORT OF WEBSITE BUILDERS
We used BuiltWith’s data on website builder usage in the top 1
Million websites [
4
] and data for ‘live websites’ to identify and
investigate further the following popular platforms: Wix (7 mil-
lion) [
8
] and Squarespace (2.8 million) [
5
], Weebly (1 million) [
7
],
Tilda (372 thousand) [
6
], Artisteer (139 thousand) [
2
], and Carrd
(22 thousand) [3].
We found that the websites/online documentation of the pre-
viously listed website builders vary in their acknowledgment of
accessibility. For example, Artisteer, Carrd, and Tilda do not men-
tion accessibility on their websites or in documentation. Although
Weebly has a ‘What is Accessibility?’ page, it is only discoverable us-
ing the search feature, and it makes no mention that their platform
has accessibility features, whereas Squarespace and Wix do.
Squarespace platform. Squarespace’s website builder showed no
clear references to accessibility; for example, the only way to add
alt text is by adding an image caption or editing its “Filename”
eld—the lename is also marked as optional. It is also not very
intuitive to write an alt text description of the image in a text eld
requesting le name. If no action is taken to add a name or de-
scription, then the image’s le name and extension are used as
the alt text by default. With regards to the image caption doubling
as alt text, this is usually discouraged [
19
] because an image cap-
tion may not include the appropriate level of detail for an alt text
description, and it is important we take care in how we write alt
text descriptions [
1
]. Although Squarespace discusses accessibility
in support documentation, their website builder lacks sucient
guidance, which is arguably where users will spend the most time.
Wix platform. In the Wix software, a menu option for the ‘Acces-
sibility Manager’ allows users to toggle three accessibility features:
enabling visual indicators, setting the Document Object Model
(DOM) order of the page automatically, and turning on advanced
settings. We found some or all of these features are disabled by
default in certain templates. Adding alt text to images is clearer in
the Wix editor because each image has a eld titled “What’s in the
image? Tell Google.” However, similar to Squarespace, Wix defaults
to using the image’s le name when a user does not add specic alt
text. Additionally, “Learn More” is provided as an example of button
text in an informational alert, but lacks descriptive information as
recommended by WCAG [12].
ASSETS ’22, October 23–26, 2022, Athens, Greece
© 2022 Copyright held by the owner/author(s).
This is the author’s version of the work. It is posted here for your personal use. Not for
redistribution. The denitive Version of Record was published in The 24th International
ACM SIGACCESS Conference on Computers and Accessibility (ASSETS ’22), October
23–26, 2022, Athens, Greece, https://doi.org/10.1145/3517428.3550368.

ASSETS ’22, October 23–26, 2022, Athens, Greece Pillai et al.
Although Wix seems to place more emphasis on accessibility
through their accessibility articles and manager in the editor, this
information is still somewhat hidden. For example, their website
does not provide a link to their accessibility articles in the main
menu at the top of the page, which reduces the visibility of accessi-
bility information. Most people using website building platforms
may not even notice these features or information, especially if
they lack accessibility knowledge to identify their importance.
Summary. Overall, we found Wix to include more information
and guidance on accessibility. Therefore, we chose Wix as our ex-
emplar tool to understand further how accessibility features are
being used and to gain some insights into whether the current
design supports users in creating accessible websites. Wix also has
2.5x as many live websites hosted online compared to Squarespace
(7 million vs 2.8 million). It would be unfair to analyze the web-
sites created by other website builders that do not report oering
accessibility features.
3 ACCESSIBILITY AUDIT
After determining that Wix was the most accessibility-focused con-
sumer website builder we ran an accessibility audit of websites
created with Wix to identify whether the support Wix oers trans-
lates to accessible websites.
3.1 Audit Materials and Procedures
We ran an accessibility audit of 30 Wix websites selected through
Wix’s ocial blog, which showcases exemplar websites created
with Wix. To preserve the anonymity of the creators, we high-
light just the main selection criteria. We selected 10 websites from
each of the following categories to ensure content variety: blogs,
eCommerce, and small business. We examined three pages from
each website (homepage, a primary content page, an about/contact
page); therefore, we skipped over websites that did not meet this
criteria or had 404 errors when we visited the website. We audited
90 webpages in total (30 websites x 3 pages each).
We structured our audit to focus on four key accessibility guide-
lines from WCAG 2.1 [
12
]: heading structure, link/button link text,
image alternative text, and color contrast. WCAG has an extensive
list of instructions, but we wanted to be pragmatic and there are
several reasons for our focus on four key areas: 1) People using
website builders are likely to create websites predominately com-
posed of text and images, 2) The rst three guidelines are important
for eective screen reader navigation and the fourth allows us to
evaluate website accessibility for other vision impairments (e.g.,
color blindness, low vision), and 3) We derived from the rst as-
sessment that Wix either has native support or advises on how to
conform to those accessibility guidelines. We want to stress this
third reason—we were focused on checking for evidence of acces-
sibility on criteria that Wix supports to not unfairly assess the
websites against unsupported criteria.
We followed best practice by combining automated and manual
testing [
11
,
21
]. We used WebAIM’s WAVE (wave.webaim.org) and
manually checked accessibility conformance by consulting WCAG
2.1. 1) Heading structure: we used WAVE and page source code
to check for appropriate heading structures. 2) Link/button link
text: we assigned one of three grades for in-text link and button link
accessibility on every page. A Good grade for descriptive text on
all links and buttons, an Acceptable grade for pages with somewhat
descriptive links and buttons, and Needs Improvement for pages
without descriptive links or buttons. 3) Image alt text: we used
WAVE and the page source code to check for alt text. Decorative
images without alt text passed, but images with le names or mean-
ingless text as the alt text are inaccessible. 4) Color contrast: we
used WAVE’s automated color contrast check and manually checked
colors using Apple’s built-in Digital Color Meter with WebAIM’s
Contrast Checker (https://webaim.org). We checked navigational
menu items, link text, buttons, main content, etc. on each page.
3.2 Audit Analysis and Findings
The results of the audit indicated an overall lack of accessibility
within websites created by Wix across our chosen four accessi-
bility categories supported by Wix. The most common issue was
color contrast, with heading structure and image alt text following
closely behind. Link and button link text were relatively sucient
in accessibility, but not perfect. Additional patterns of Wix-wide
accessibility issues within each category were also noted during
the audit. For example, frequent default image description issues
and non-descriptive log in links (see Sections 3.2.3 and 3.2.4).
3.2.1 Color Contrast. Of the 90 pages we audited for color contrast,
64 pages had elements that failed WCAG criteria, resulting in 71%
of the audited pages having insucient color contrast across all
relevant elements (e.g., text on the background, text on a button).
We found 77% of the audited blog pages had insucient color con-
trast among the measured elements, but this rate was slightly lower
for business pages (67%) and eCommerce pages (70%). Since many
elements failed minimum contrast ratios (normal text contrast ra-
tio=4.5:1; large text contrast ratio=3:1), they would by denition
also fail level AAA’s contrast ratios (normal text contrast ratio=7:1;
large text contrast ratio=4.5:1).
3.2.2 Heading Structure. Only 88 of the 90 webpages were applica-
ble for us to include in an audit focused on whether an appropriate
heading structure was used because two webpages had no head-
ing. We found that overall 58% of webpages incorrectly followed
WCAG’s criteria for heading structure. Of the blog pages audited,
40% had an ineective heading structure, whereas 66% of the small
business webpages had ineective heading structure, and 69% of the
eCommerce webpages had ineective heading structure. Many web-
pages were missing an H1 tag, and many used somewhat random
heading structures. Although Wix oers drag-and-drop headings to
create a heading structure, it appeared that many users are applying
the headings for aesthetic purposes (i.e., for size/style), rather than
for accessibility.
3.2.3 Image Alternative Text. Among all 90 audited webpages, 55%
of images across all websites inappropriately used alternative text,
which meant a majority of images were inaccessible—we not only
looked for whether an image had alt text but considered the over-
all context (i.e., decorative images do not need alt text, is the alt
text suciently descriptive of the image, etc.). Within the 30 blog
webpages (10 websites, 3 pages each), 53% of images made inappro-
priate use of alt text, whereas this was 60% when looking at small
business websites, and 52% among the eCommerce websites.

Website Builders Still Contribute To Inaccessible Web Design ASSETS ’22, October 23–26, 2022, Athens, Greece
We noticed some common image alt text details across all audited
websites. File name was often used for image alt text, many social
media icons have ineective default alt text, product and gallery
images often had redundant product or image titles as alt text, and
nearby product images all had the same alt text, which was usually
the product title. As we note in Section 2, Wix defaults to using the
image’s le name when a user does not add specic alt text. Our
audit results also suggest that Wix users were either not aware of
the need to include alt text or did not know how to assign alt text
to images within the Wix interface.
3.2.4 Link and Buon Link Text. Of the 83 applicable audited pages
with links or buttons, 53 had Good link text
1
, resulting in only 36%
of links that could be more descriptive. The remaining seven web-
pages did not include any links or buttons on the page (besides the
constant nav/footer elements which were counted once for each
websites homepage). We found only 18% of the blog pages’ link text
did not meet our Good grade criteria (Acceptable=14%, Needs Im-
provement=4%), whereas the rate increased to 50% among the small
business webpages (Acceptable=23%, Needs Improvement=27%), and
41% of the eCommerce webpages (Acceptable=20.7%, Needs Improve-
ment=20.7%). On most of the blog pages, a “log in” link for leaving
a comment appears towards the bottom of posts. However, the
link only says “log in”, which is not descriptive enough to tell a
screen reader user what they are logging in to do, which would be
to leave a comment. An improved link text could simply be “log
in to leave a comment”. This link issue appeared on all of the blog
sites using the comment feature and many of the form elds used
placeholder text as label text by default, suggesting these were
things that were inaccessible by default rather than from the users’
lack of knowledge.
4 DISCUSSION
Website builders have the potential to guide novice web designers in
creating accessible websites. Modern website builders are increasing
eort to oer accessibility features, unlike in the past [
17
]. However,
through our examination of website builders and webpages created
using Wix—the most popular and accessibility-focused website
builder—we found that website builders are still not eective in
supporting the creation of accessible websites. Website builders are
targeted toward people without design and technical skills, which
underscores the importance of these services to support accessible
website creation. We do want to acknowledge that software goes
through updates and the popularity of design tools changes, thus
our study is a snapshot of the current situation. We are highlighting
that although some website builders have increased their support
for accessible web design since earlier work, it is not enough.
4.1 Recommendations and Future Work
Recommendation 1. Companies of website builders should pro-
mote the importance of accessibility and explain how their tools can
supports building accessible websites. Accessibility topics should
not be buried in documentation. A person’s rst encounter with
1
A Good grade meant that descriptive text was used for all links and buttons overall,
an Acceptable grade was assigned to pages that had somewhat descriptive links and
buttons, and Needs Improvement was assigned to pages that did not have descriptive
links or buttons.
website building platforms will likely be the company website, and
this is an early opportunity to make website builder users aware of
web accessibility.
Recommendation 2. Accessibility features should be easily
discoverable and prioritized. We learned from our review of the
Wix interface that the hidden accessibility features and external
article support (rather than built-in tooltips or similar), likely point
to Wix requiring too much eort and knowledge on the part of
the user to be able to make use of any of the accessibility features
oered. For example, discoverability could be improved by ensuring
accessibility features are found within all relevant menus (e.g., main
menu, element mini-menus), and the position in the menu should
be near where the user will rst begin reading through the list so
that accessibility features are prioritized.
Recommendation 3. Website builders should play an active
role in guiding the user toward making choices that improve web-
site accessibility. There are opportunities for the system to provide
alternative design suggestions, notication reminders, and warn-
ings, throughout the design process up to publishing the website.
For example, a pop-up notication could appear near where the
user is working so that it is noticeable, and the immediacy would
ensure the user thinks about accessibility while working rather
than leaving accessibility to the end when the website is complete.
Future Work. Future work could examine these recommenda-
tions across other website builders to determine a more compre-
hensive baseline of how accessibility is handled by this genre of
technology. It would also be useful to interview and observe people
who use website builders to better understand their awareness of
accessibility features, as well as any potential issues with how the
features are currently implemented and used. Furthermore, it would
be useful to build prototypes and evaluate how to implement such
features eectively. For example, how could we ensure accessibility
pop-ups are designed in a way that will not annoy the user? And,
how could we present guidance in a way that is actionable and clear
for users who have little knowledge of WCAG?
5 CONCLUSION
We found that, in general, website building platforms lack a clear
stance on supporting website accessibility. Despite some website
builders fullling the recommendations of prior work by oering
accessibility features, we are not at a point where those features
are proving eective. We found that websites created by the most
accessibility-focused website builder were not accessible, suggest-
ing that the intended users of website builders are not making use
of those accessibility features. There is an opportunity for HCI
researchers to understand how we can redesign those accessibility
features in a way that is engaging for users of website builders to
maximize creating accessible websites.
REFERENCES
[1]
Cynthia L. Bennett, Cole Gleason, Morgan Klaus Scheuerman, Jerey P. Bigham,
Anhong Guo, and Alexandra To. 2021. “It’s Complicated”: Negotiating Accessibil-
ity and (Mis)Representation in Image Descriptions of Race, Gender, and Disability.
In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems.
Association for Computing Machinery, New York, NY, USA, Article 375, 19 pages.
https://doi.org/10.1145/3411764.3445498
[2]
BuiltWith. 2022. Artisteer Usage Statistics. https://trends.builtwith.com/cms/
Artisteer. Accessed: 2022-01-12.

ASSETS ’22, October 23–26, 2022, Athens, Greece
[3]
BuiltWith. 2022. Carrd Usage Statistics. https://trends.builtwith.com/cms/Carrd.
Accessed: 2022-01-12.
[4]
BuiltWith. 2022. Simple Website Builder Usage Distribution in the Top 1 Million
Sites. https://trends.builtwith.com/cms/simple-website- builder. Accessed: 2022-
01-12.
[5]
BuiltWith. 2022. Squarespace Usage Statistics. https://trends.builtwith.com/cms/
Squarespace. Accessed: 2022-01-12.
[6]
BuiltWith. 2022. Tilda Usage Statistics. https://trends.builtwith.com/cms/Tilda.
Accessed: 2022-01-12.
[7]
BuiltWith. 2022. Weebly Usage Statistics. https://trends.builtwith.com/cms/
Weebly. Accessed: 2022-01-12.
[8]
BuiltWith. 2022. Wix Usage Statistics. https://trends.builtwith.com/cms/Wix.
Accessed: 2022-01-12.
[9]
Michael Crabb, Michael Heron, Rhianne Jones, Mike Armstrong, Hayley Reid,
and Amy Wilson. 2019. Developing Accessible Services: Understanding Cur-
rent Knowledge and Areas for Future Support. In Proceedings of the 2019 CHI
Conference on Human Factors in Computing Systems (Glasgow, Scotland Uk)
(CHI ’19). Association for Computing Machinery, New York, NY, USA, 1–12.
https://doi.org/10.1145/3290605.3300446
[10]
Mardé Gree and Paula Kotzé. 2009. A Lightweight Methodology to Improve
Web Accessibility. In Proceedings of the 2009 Annual Research Conference of the
South African Institute of Computer Scientists and Information Technologists (Van-
derbijlpark, Emfuleni, South Africa) (SAICSIT ’09). ACM, New York, NY, USA,
30–39. https://doi.org/10.1145/1632149.1632155
[11]
Shaun K. Kane, Jessie A. Shulman, Timothy J. Shockley, and Richard E. Ladner.
2007. A Web Accessibility Report Card for Top International University Web
Sites. In Proceedings of the 2007 International Cross-Disciplinary Conference on Web
Accessibility (W4A) (Ban, Canada) (W4A ’07). Association for Computing Ma-
chinery, New York, NY, USA, 148–156. https://doi.org/10.1145/1243441.1243472
[12]
Andrew Kirkpatrick, Joshue O’Connor, Alastair Campbell, and Michael
Cooper. 2018. Web Content Accessibility Guidelines (WCAG) 2.1.
https://www.w3.org/TR/WCAG21/ Accessed: 2018-12-11.
[13]
Eleanor T. Loiacono, Nicholas C. Romano, and Scott McCoy. 2009. The State
of Corporate Website Accessibility. Commun. ACM 52, 9 (Sept. 2009), 128–132.
https://doi.org/10.1145/1562164.1562197
[14]
Pedro Lorca, Javier De Andrés, and Ana B. Martínez. 2018. The Re-
lationship Between Web Content and Web Accessibility at Universities:
Pillai et al.
The Inuence of Social and Cultural Factors. Social Science Computer
Review 36, 3 (2018), 311–330. https://doi.org/10.1177/0894439317710435
arXiv:https://doi.org/10.1177/0894439317710435
[15]
Lourdes Moreno, Paloma Martínez, and Belén Ruiz. 2008. Guiding Accessibil-
ity Issues in the Design of Websites. In Proceedings of the 26th Annual ACM
International Conference on Design of Communication (Lisbon, Portugal) (SIG-
DOC ’08). Association for Computing Machinery, New York, NY, USA, 65–72.
https://doi.org/10.1145/1456536.1456550
[16]
Rohan Patel, Pedro Breton, Catherine M. Baker, Yasmine N. El-Glaly, and Kris-
ten Shinohara. 2020. Why Software is Not Accessible: Technology Profession-
als’ Perspectives and Challenges. In Extended Abstracts of the 2020 CHI Con-
ference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI EA
’20). Association for Computing Machinery, New York, NY, USA, 1–9. https:
//doi.org/10.1145/3334480.3383103
[17]
Christopher Power and Helen Petrie. 2007. Accessibility in Non-Professional
Web Authoring Tools: A Missed Web 2.0 Opportunity?. In Proceedings of the 2007
International Cross-Disciplinary Conference on Web Accessibility (W4A) (Ban,
Canada) (W4A ’07). Association for Computing Machinery, New York, NY, USA,
116–119. https://doi.org/10.1145/1243441.1243468
[18]
Garreth W. Tigwell, David R. Flatla, and Neil D. Archibald. 2017. ACE: A Colour
Palette Design Tool for Balancing Aesthetics and Accessibility. ACM Trans. Access.
Comput. 9, 2, Article 5 (Jan. 2017), 32 pages. https://doi.org/10.1145/3014588
[19]
Shari Trewin. 2019. Describing Figures. https://www.w3.org/WAI/standards-
guidelines/atag/. Accessed: 2021-7-1.
[20]
UsableNet. 2018. 2018 ADA Web Accessibility Recap: Lawsuit Report. https://
blog.usablenet.com/2018-ada- web-accessibility- lawsuit-recap- report. Accessed:
2020-03-11.
[21]
Markel Vigo, Justin Brown, and Vivienne Conway. 2013. Benchmarking Web
Accessibility Evaluation Tools: Measuring the Harm of Sole Reliance on Au-
tomated Tests. In Proceedings of the 10th International Cross-Disciplinary Con-
ference on Web Accessibility (Rio de Janeiro, Brazil) (W4A ’13). Association
for Computing Machinery, New York, NY, USA, Article 1, 10 pages. https:
//doi.org/10.1145/2461121.2461124
[22]
WebAIM. 2021. The WebAIM Million – An annual accessibility analysis of the top
1,000,000 home pages. https://webaim.org/projects/million/. Accessed: 2021-6-20.
[23]
Yeliz Yesilada and Simon Harper. 2019. Web accessibility: a foundation for research
(2 ed.). Springer.