Conference PaperPDF Available

Website Builders Still Contribute To Inaccessible Web Design



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.
Website Builders Still Contribute To Inaccessible Web Design
Athira Pillai
School of Information
Rochester Institute of Technology
Rochester, New York, USA
Kristen Shinohara
School of Information
Rochester Institute of Technology
Rochester, New York, USA
Garreth W. Tigwell
School of Information
Rochester Institute of Technology
Rochester, New York, USA
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
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.
Websites continue to be inaccessible [
]—a 2021 audit
found 97.4% of 1 million home pages had at least one Web Con-
tent Accessibility Guidelines (WCAG) violation [
]. 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 [
]. However, a 2007
study found Apple’s iWeb website builder and its preset templates
had a distinct lack of accessibility conformance and features [
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 ( 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.
We used BuiltWith’s data on website builder usage in the top 1
Million websites [
] and data for ‘live websites’ to identify and
investigate further the following popular platforms: Wix (7 mil-
lion) [
] and Squarespace (2.8 million) [
], Weebly (1 million) [
Tilda (372 thousand) [
], Artisteer (139 thousand) [
], 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 [
] 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 [
]. 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,
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.
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 [
]: 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 [
]. We used WebAIM’s WAVE ( 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 ( 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
, 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.
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 [
]. 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
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?
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.
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.
BuiltWith. 2022. Artisteer Usage Statistics.
Artisteer. Accessed: 2022-01-12.
ASSETS ’22, October 23–26, 2022, Athens, Greece
BuiltWith. 2022. Carrd Usage Statistics.
Accessed: 2022-01-12.
BuiltWith. 2022. Simple Website Builder Usage Distribution in the Top 1 Million
Sites. builder. Accessed: 2022-
BuiltWith. 2022. Squarespace Usage Statistics.
Squarespace. Accessed: 2022-01-12.
BuiltWith. 2022. Tilda Usage Statistics.
Accessed: 2022-01-12.
BuiltWith. 2022. Weebly Usage Statistics.
Weebly. Accessed: 2022-01-12.
BuiltWith. 2022. Wix Usage Statistics.
Accessed: 2022-01-12.
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.
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,
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.
Andrew Kirkpatrick, Joshue O’Connor, Alastair Campbell, and Michael
Cooper. 2018. Web Content Accessibility Guidelines (WCAG) 2.1. Accessed: 2018-12-11.
Eleanor T. Loiacono, Nicholas C. Romano, and Scott McCoy. 2009. The State
of Corporate Website Accessibility. Commun. ACM 52, 9 (Sept. 2009), 128–132.
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.
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.
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:
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,
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.
Shari Trewin. 2019. Describing Figures.
guidelines/atag/. Accessed: 2021-7-1.
UsableNet. 2018. 2018 ADA Web Accessibility Recap: Lawsuit Report. https:// web-accessibility- lawsuit-recap- report. Accessed:
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:
WebAIM. 2021. The WebAIM Million An annual accessibility analysis of the top
1,000,000 home pages. Accessed: 2021-6-20.
Yeliz Yesilada and Simon Harper. 2019. Web accessibility: a foundation for research
(2 ed.). Springer.
Conference Paper
Full-text available
The use of web accessibility evaluation tools is a widespread practice. Evaluation tools are heavily employed as they help in reducing the burden of identifying accessibility barriers. However, an over-reliance on automated tests often leads to setting aside further testing that entails expert evaluation and user tests. In this paper we empirically show the capabilities of current automated evaluation tools. To do so, we investigate the effectiveness of 6 state-of-the-art tools by analysing their coverage, completeness and correctness with regard to WCAG 2.0 conformance. We corroborate that relying on automated tests alone has negative effects and can have undesirable consequences. Coverage is very narrow as, at most, 50% of the success criteria are covered. Similarly, completeness ranges between 14% and 38%; however, some of the tools that exhibit higher completeness scores produce lower correctness scores (66-71%) due to the fact that catching as many violations as possible can lead to an increase in false positives. Therefore, relying on just automated tests entails that 1 of 2 success criteria will not even be analysed and among those analysed, only 4 out of 10 will be caught at the further risk of generating false positives.
Conference Paper
Full-text available
Including accessibility in the design of Websites 1.0 entails difficulties, but this situation becomes more complicated when the user becomes a creator in the web. There are new requirements to be considered in the design due to the user's active interaction in the web 2.0 environment, such as the web pages with user-generated content (like Blogs), where there are not only information receptors, but issuers as well,. This paper offers a solution for including accessibility requirements in the design process based on using accessible content templates in order to preserve accessibility and the editing process using models and rules to annotate structure and semantics of contents. This annotation is added to the final codification, which will guarantee a better complement to the standards and accessibility guidelines.
Conference Paper
Full-text available
The advent of Web 2.0 technologies, and the increased par- ticipation of users in personalized web experiences, has cre- ated a need for new web authoring tools intended for use by non-professional web authors. These tools represent a prime opportunity for including accessibility features early in the tool design process. The results from an accessibil- ity evaluation of one of these tools demonstrates that such opportunities could be easily missed.
Conference Paper
Full-text available
Copyright: ACM 2009. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in Proceedings of the South African Institute of Computer Scientists and Information Technologists (SAICSIT) Conference, {978-1-60558-286-3, (2008)} This paper introduces a methodology to improve the accessibility of websites with the use of free so-called automatic tools. The methodology has three iterative phases, namely assessing a website against accessibility guidelines, user testing and creating in-house ‘guidelines’ to prevent similar mistakes in future versions of the system. Aspects of accessibility addressed include the use of colour, accessibility guidelines and priorities, readability or comprehensibility, and screen reader simulators. We recommend free tools for each of these accessibility aspects and discuss the process that should be followed when evaluating a website.
Conference Paper
When creating digital artefacts, it is important to ensure that the product being made is accessible to as much of the population as is possible. Many guidelines and supporting tools exist to assist reaching this goal. However, little is known about developers' understanding of accessible practice and the methods that are used to implement this. We present findings from an accessibility design workshop that was carried out with a mixture of 197 developers and digital technology students. We discuss perceptions of accessibility, techniques that are used when designing accessible products, and what areas of accessibility development participants believed were important. We show that there are gaps in the knowledge needed to develop accessible products despite the effort to promote accessible design. Our participants are themselves aware of where these gaps are and have suggested a number of areas where tools, techniques and guidance would improve their practice.
This research assesses whether universities from varied cultures rank significantly different with respect to the quality of their web contents and with regard to their web accessibility (WA) level. Moreover, this article tests whether universities, which make stronger efforts to improve the quality of their web contents, also take into account WA issues to ease the access to such contents. We use a database containing 399 universities from 16 countries. Main results suggest that universities in Anglo-Saxon countries pay more attention to WA issues and that those in Germanic countries rank significantly higher with regard to web quality contents. On a global basis, there is a significant relationship between the level of accessibility at university webpages and the quality of the web contents. However, if countries are grouped, results are different. While in Germanic, Nordic, and Anglo-Saxon countries, there is no relation between the level of accessibility of university webpages and the quality of the web contents, in Latin countries, this relation is direct and significant.
Colour can convey a mood or elicit a particular emotion and, in terms of web design, colour can influence attitudes, perceptions, and behaviours. However, many websites demonstrate inaccessible colour choices. Numerous online colour palette design tools only focus on assisting designers with either the aesthetics or accessibility of colours.With a user-centered design approach, we developed the Accessible Colour Evaluator (ACE, which enhances web developers' and designers' ability to balance aesthetic and accessibility constraints. We distributed an online questionnaire to 28 web developers and designers to understand their attitudes and utilisation of accessibility guidelines, as well as to gather initial design requirements for ACE. With this information, we created three low-fidelity paper prototypes that were used to create two high-fidelity prototypes. The high-fidelity prototypes were discussed with 4 web developers and designers during a design workshop, and their feedback was used to develop the final version of ACE. A comparative evaluation of ACE and three existing alternative tools was conducted with 10 new web developers and designers. All participants were able to complete a colour palette design task when using ACE and identified ACE as their most preferred tool. The mean scores for the six TLX measures show ACE as providing the best performance and causing the lowest frustration. Finally, we conducted a small focus group with 3 web developers and designers to gather qualitative feedback about ACE. Participants identified a number of ACE's strengths and made suggestions for future extensions and improvements. 2017
Conference Paper
University web pages play a central role in the activities of current and prospective postsecondary students. University sites that are not accessible may exclude people with disabilities from participation in educational, social and professional activities. In order to assess the current state of university web site accessibility, we performed a multi-method analysis of the home pages of 100 top international universities. Each site was analyzed for compliance with accessibility standards, image accessibility, alternate-language and text-only content, and quality of web accessibility statements. Results showed that many top universities continue to have accessibility problems. University web site accessibility also varies greatly across different countries and geographic regions. Remaining obstacles to universal accessibility for universities include low accessibility in non- English-speaking countries and absent or low-quality accessibility policies.