Conference PaperPDF Available

Exploring Accessibility Features and Plug-ins for Digital Prototyping Tools

Authors:

Abstract

Many digital systems are found to be inaccessible and a large part of the issue is that accessibility is not considered early enough in the design process. Digital prototyping tools are a powerful resource for designers to quickly explore both low and high fidelity design mockups during initial stages of product design and development. We evaluated 10 popular prototyping tools to understand their built-in and third-party accessibility features. We found that accessible design support is largely from third-party plug-ins rather than prototyping tools' built-in features, and the availability of accessibility support varies from tool to tool. There is potential to improve accessible design by increasing the potential for accessibility to be consider earlier in the design process.
Exploring Accessibility Features and Plug-ins for Digital
Prototyping Tools
Urvashi Kokate
uk4890@rit.edu
School of Information
Rochester Institute of Technology
Rochester, NY, USA
Kristen Shinohara
kristen.shinohara@rit.edu
School of Information
Rochester Institute of Technology
Rochester, NY, USA
Garreth W. Tigwell
garreth.w.tigwell@rit.edu
School of Information
Rochester Institute of Technology
Rochester, NY, USA
ABSTRACT
Many digital systems are found to be inaccessible and a large part of
the issue is that accessibility is not considered early enough in the
design process. Digital prototyping tools are a powerful resource
for designers to quickly explore both low and high delity design
mockups during initial stages of product design and development.
We evaluated 10 popular prototyping tools to understand their built-
in and third-party accessibility features. We found that accessible
design support is largely from third-party plug-ins rather than pro-
totyping tools’ built-in features, and the availability of accessibility
support varies from tool to tool. There is potential to improve ac-
cessible design by increasing the potential for accessibility to be
consider earlier in the design process.
CCS CONCEPTS
Human-centered computing Accessibility.
ACM Reference Format:
Urvashi Kokate, Kristen Shinohara, and Garreth W. Tigwell. 2022. Exploring
Accessibility Features and Plug-ins for Digital Prototyping Tools. In The 24th
International 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.3550391
1 INTRODUCTION AND RELATED WORK
Accessible design should not be an afterthought in the design pro-
cess [
4
]. When accessibility issues are checked later in the design
process, it requires more time, money, and eort in redesigning
and reprogramming the product [
9
,
13
,
23
,
24
]. Therefore, it is ben-
ecial to move accessible design as early as possible in the design
process [16].
Accessibility tools are an essential part of the design process
to support people meeting accessible design standards set by the
Web Content Accessibility Guidelines (WCAG) [
12
], and mobile
app design guidelines also incorporate WCAG criteria [
2
,
7
,
17
] due
to an increasing need for mobile accessibility [
1
]. Designers and
developers have access to a multitude of accessibility tools [
5
,
10
].
However, they generally fall into two categories: those to be used
during design and development, and those that run evaluations after
development. Automated accessibility checking generally results
in missing some issues compared to manual assessment [
14
], and
there is also a lack of consistency among accessibility evaluation
tools [
6
,
18
]. However, there is potential with accessibility tools that
support people in meeting WCAG (e.g., color contrast checkers),
especially if they are designed to be used earlier in the design
process (e.g., the Accessible Colour Evaluator, which was developed
through a User-Centered Design process [22]).
Prototyping is a design method used early in the design process
to lay down ideas and also support quicker evaluations [
11
,
20
].
There are many approaches to facilitating prototyping practice rang-
ing from working oine (e.g., pen and paper) to using low-cost,
readily available software (e.g. Microsoft PowerPoint) to high-end
professional software (e.g., Adobe XD). We anticipated that proto-
typing tools are likely not providing enough feature support for
users since prior work already found prototyping tools themselves
are not made to be accessible [
15
]. Some prototyping software
also supports the use of plug-ins, and there is potential with this
approach to oer accessibility plug-ins (e.g., Adee [8]).
There are many scenarios where prototyping tools could support
accessible design. For example, notifying the user when color pairs
are inaccessible due to not meeting WCAG minimum contrast crite-
ria, warning when button target sizes may be too small for certain
devices, recommending accessible fonts styles and font sizes.
We formally evaluated 10 popular design tools that can be used
to support digital prototyping to understand what accessibility sup-
port they provide. We found that only a few tools have built-in
features to support accessible design and most of the tools rely on
third party plug-ins that provide features to check for accessibil-
ity. The majority focused on color contrast checking and oered
problematic color blind simulations. We recommend that compa-
nies and the HCI community focus more on providing a range of
accessibility check features to support accessible design during on
of the earliest points of the design process.
2 EVALUATION OF DESIGN PROTOTYPING
TOOLS
Selection of tools. We selected 10 UI design tools from the 2020 design
tools survey conducted by UX tools [
19
]. Our selection included:
Adobe Illustrator, Adobe Photoshop, Adobe XD, Anity Designer,
Axure, Figma, Framer, InVision Studio, Sketch, and UXPin.
Evaluation method. Our evaluation process had three steps.
Step 1: Find and document any accessibility-related support re-
ported in the prototyping tool’s documentation and/or website. We
rst browsed through the website and then did a keyword search
to look up for specic sections of the page. We selected keywords
related to visual design, accessibility, and guidelines since interface
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.3550391.
ASSETS ’22, October 23–26, 2022, Athens, Greece Kokate et al.
prototyping does not often have the ability for audio (see list of key-
words in supplementary materials). We rst checked the top-level
menus and landing page of each tool’s website. Then we did a key-
word search in the help/support/documentation, and blog section
of each website. Step 2: Check for any built-in accessible design
features in the tools. We checked the top menu, tool bar, and right
clicked on design elements to identify any accessibility features
the prototyping tools oer. Step 3: Check for third-party plug-ins
for each tool that supports accessible design. We searched plug-in
managers with Step 1’s list of keywords. We read the description of
each plug-in and noted down its features. We also checked whether
it was free, free with paid features, or paid.
2.1 Findings
2.1.1 Searching through each prototyping tool’s documentation and
website. We found two out of 10 tools (Anity Designer, Framer)
did not have any content related to accessibility. Six prototyping
tools (Adobe XD, Axure, Figma, InVision Studio, Sketch, UXPin)
featured blogs based on dierent topics of accessibility such as
‘what is accessibility’, ‘design practices for accessibility’ and ‘why
designers should think about accessibility’. Adobe Illustrator and
Adobe Photoshop mention about their inbuilt color blind simula-
tion features in their documentation. UXPin highlights the built-in
features of color contrast checker and color blind simulation in
the ‘features’ section of their websites. Adobe XD and Figma also
highlight the Stark plug-in which provides dierent accessibility
check features to the users such as color contrast checker, color
blind simulator, and focus order.
A majority of the tools provide information on why and how to
include accessibility in design, but only half of the tools mention
how the tool itself can support them in designing or checking for
accessibility. Also, the information provided is limited and hard to
nd on the website. None of the tools have a section in the top-level
menu for accessibility on their website. To look up content, a user
needs to search for the content using dierent keywords. ‘Accessi-
bility’ and ‘contrast’ were the keywords that returned informative
content about accessibility for seven of the prototyping tools. We
based how easy it was to search for information about accessibility
on the number of results that were returned and the time taken to
nd relevant results out of the total returned results. More time
was taken to look up content which returned more results. Figma
proved more most dicult to nd relevant content because search-
ing for ‘accessibility’ in the help center gave over 200 results out
of which only 3 included the word accessibility since most of the
results were for the word ‘access’. It was easiest to look up for
content on UXPin because it returned fewer results and the built-in
features were highlighted on the feature page of the website, which
was easier to spot.
Table 2 in Supplementary Materials provides a breakdown of
accessibility content for each prototyping tool.
2.1.2 Evaluating tool’s built-in accessibility features. Anity De-
signer and Sketch did not have any built-in accessibility features.
We were able to identify ve categories that built-in accessibility
features would t. The categories were: (1) color contrast checker
(found in UXPin); (2) adding audio feedback and speech output
(found in Adobe XD); (3) color blind simulation (found in Adobe
Illustrator, Adobe Photoshop, UXPin); (4) voice prototyping (found
in Adobe XD); and (5) adding keyboard navigation (found in Adobe
XD, Axure, Figma, Framer, InVision Studio, UXPin).
UX Pin is the only tool that had a built-in color contrast checker
that automatically identies text colors with insucient contrast
with respect to WCAG guidelines. It also had a color blind simulator
that allowed users to view their designs in eight dierent types of
color blindness, as well as a prototyping feature to add keyboard
shortcut as a trigger to transition across screens. Adobe Illustrator
and Adobe Photoshop both provided color blind simulation features,
but they only allowed users to view in Protanopia or Deuteranopia.
Adobe XD was the only prototyping tool that allows users to add
audio feedback and speech output in the design to provide guidance
for users who can access the prototype with only sound. Adobe
XD also supports voice prototyping, which allows users to design
transitions through voice commands. Axure, Figma, Framer, and
InVision also had the prototyping feature to add keyboard shortcuts
for transition. Table 3 in Supplementary Materials provides an
overview.
2.1.3 Evaluating third-party accessibility plug-ins. Anity Designer,
Axure, and UX Pin did not support any third-party plug-ins. We
were able to identify three general categories that plug-in accessi-
bility features would t, and we provide examples for each. Table
4 in Supplementary Materials provides an overview of the plug-
in accessibility features category type found for each prototype
tool, While Tables 5-11 provide details on each prototyping tool’s
plug-ins.
Plugins used for accessibility checking: Color contrast checker:
checks contrast between two color layers (foreground text color and
background color); Touch target size checker: checks touch target
size with respect to devices and shows if it violates guidelines; and
Epilepsy checker: checks if images and animated GIFs in designs are
safe for people with photosensitive epilepsy to view.
Plugins used to enhance accessibility: Alt text generator: adds
alt-text for images to share with the developers; Focus orderer: adds
focus order for keyboard navigation; Screen reader support: adds
ARIA roles, ARIA properties and tab index in designs; and Text
resizer: creates legible texts with respect to screen size.
Plugins used to support understanding impairments: Color
blind simulation: tests designs with dierent color blind simulation;
and Visual Impairment Simulation: checks elements against dier-
ent types of visual impairments such as central loss, blind spots,
hemianopia, peripheral loss, retinal detachment, ocular albinism.
We list all third party accessibility plug-ins in Table 1 by proto-
typing tool. Figma oered the most number of plug-ins equal—17 in
total. Though Figma had relatively more plug-ins, 11 out of the 17
plug-ins actually only included features to check colors accessibility.
Table 4 in Supplementary Materials shows the 17 plug-ins cover
seven accessibility feature categories. Most of the plug-ins were
free to use. The Stark plug-in is common across the top 3 most
popular tools—Adobe XD, Figma, and Sketch. Stark provides color
contrast checking, a color blindness simulator, and focus orderer,
but there is limited functions within the free version of Stark. The
paid features provide smart suggestion of colors to use if the cur-
rent colors in the design do not adhere to accessibility guidelines.
None of the free plug-ins provide color suggestions to the users.
Exploring Accessibility Features and Plug-ins for Digital Prototyping Tools ASSETS ’22, October 23–26, 2022, Athens, Greece
Table 1: List of all third party plug-ins. Details of each tool and plug-in are found in supplementary materials.
Prototyping tools List of plug-ins
Figma
Able, Zebra, Contrast, A11y - Color Contrast Checker, Color blind, Epilepsy Blocker, Stark,
Color Contrast Grid, Cards for Humanity, A11y - Focus Orderer, Adee Comprehensive
Accessibility Tool, Contrast, Contrast Grid, HCL Easy, Color Contrast, Low Vision
Sketch
Stark, Adee Comprehensive Accessibility Tool, Cluse, Color Contrast Analyzer, Check Con-
trast, Color Blindless, Sketch WCAG
Adobe XD Stark, Colorsinspo, Dopely colors
Adobe Illustrator Pantone Connect
Adobe Photoshop Pantone Connect, Check Contrast Ratio
InVision Studio Contrast
Framer Color Contrast checker, Color check, Accessibility Tool Kit
Epilepsy blocker is a paid plug-in available only on Figma. It was
the only plug-in to allow users to check if images and animated
GIFs in designs are safe for people with photosensitive epilepsy.
The Adee Comprehensive Accessibility tool plug-in provided the
maximum number of features and is available to install in Figma
and Sketch only. It was totally free and included features such as alt
text generator, touch target size checker, a color blindness simulator
and a contrast checker. It also allows users to generate a report for
any guideline violations found in a design with respect to touch
target size and color contrast. The plug-ins Visual Impairment Sim-
ulation and Epilepsy checker were only available for Figma. Screen
reader support feature was provided by a plug-in available only
on Framer. Color blindness simulators and color contrast checkers
were the most popular features oered by plug-ins. Six out of the
Seven prototyping tools that support third party plug-ins had color
contrast checkers and color blindness simulators.
3 DISCUSSION
We found that although prototyping tools do oer some level of
support for accessible design, there is still room for improvement.
We found evidence of prototyping tool websites providing informa-
tion about accessible design practice and info on support their tools
oered. However, the information was hard to nd since none of
the websites had a homepage that linked to an accessibility features
support page.
Furthermore, we found the built-in accessibility features in pro-
totyping tools to be limited. The common features were the ability
to add keyboard navigation, check color contrast, and run a color
blindness simulator. In fact, the majority focused on color contrast
checking and oered color blind simulations. We want to acknowl-
edge that color blindness simulations are often limited in accuracy
and disability simulations are problematic [
3
,
21
]. It is concerning
that so many of the tools and plug-ins focused on color blindness
simulations without adequate information on the limitations of
using such a feature [
21
]. Although use of color is a prominent as-
pect of design, we nd that more eort needs to be directed toward
creating accessibility features for other accessible design criteria.
It would be useful to conduct follow-up work to understand user
perspective on what features to prioritize and how.
While we found fewer accessibility features provided within
the tools themselves, we did notice a decent oering from third
party plug-ins that either supported the creation or evaluation of
accessible design. It is clear that Figma and Sketch have beneted
from opening their platforms up to the design community to allow
designers and developers to contribute new prototyping features.
Figma had 17 accessibility plug-ins and Sketch had seven accessi-
bility plug-ins both with a variety of features, whereas the other
prototyping tools had only one to three plug-ins that provided basic
color contrast checks and color blindness simulations.
However, if prototyping tools are relying on third party devel-
opers, rather than adding built-in accessibility features, then we
do want to reect on the potential limitations of this. If a specic
accessibility feature is only available as a third party plug-in, then
the user has to actively seek it out by searching through the plug-in
store. A new user of the prototyping tool may not know about being
able to install plug-ins. Finally, there is a question of validity. There
is no clear vetting process and what determines a plug-ins success
is likely community based (e.g., ratings, comments, feedback). The
prototyping tool companies are potentially in a better position to
develop accessibility features that accurately conform to current
standards and best practice guidelines.
For future work, we will employ qualitative methods to inter-
view dierent stakeholders (e.g., designers and prototyping tool
companies) to understand their attitudes and concerns for built-in
and plug-in accessibility features. We also plan to run additional
evaluations of the accessibility features to understand how they are
used within the design process and individual workow styles to
identify whether there are opportunities to improve usability.
4 CONCLUSION
Designers should include accessibility practices in the early phase
of design such as while creating design prototypes. Prototyping
tools can be used to provide good assistance to designers to verify
design accessibility. We evaluated 10 design prototyping tools to
research on the current accessibility assistance provided by these
tools. There is support provided by prototyping tools largely in the
form of third-party plug-ins, but minimal assistance in the form of
built-in features. Also, the availability of these features varies from
tool to tool. We argue that there is potential to improve accessible
design by increasing the potential for accessibility to be consider
earlier in the design process, but the current approach needs more
renement.
REFERENCES
[1]
Shadi Abou-Zahra, Judy Brewer, and Shawn Lawton Henry. 2013. Essential
Components of Mobile Web Accessibility. In Proceedings of the 10th International
ASSETS ’22, October 23–26, 2022, Athens, Greece
Cross-Disciplinary Conference on Web Accessibility (Rio de Janeiro, Brazil) (W4A
’13). Association for Computing Machinery, New York, NY, USA, Article 5, 4 pages.
https://doi.org/10.1145/2461121.2461138
[2]
Apple. n.d.. Human Interface Guidelines: Visual Design. https://developer.
apple.com/design/human-interface- guidelines/ios/overview/themes/. Accessed:
2020-07-18.
[3]
Cynthia L. Bennett and Daniela K. Rosner. 2019. The Promise of Empathy: Design,
Disability, and Knowing the "Other". In Proceedings of the 2019 CHI Conference
on Human Factors in Computing Systems. Association for Computing Machinery,
New York, NY, USA, 1–13. https://doi.org/10.1145/3290605.3300528
[4]
Vicente Luque Centeno, Carlos Delgado Kloos, Martin Gaedke, and Martin Nuss-
baumer. 2005. Web Composition with WCAG in Mind. In Proceedings of the 2005
International Cross-Disciplinary Workshop on Web Accessibility (W4A) (Chiba,
Japan) (W4A ’05). Association for Computing Machinery, New York, NY, USA,
38–45. https://doi.org/10.1145/1061811.1061819
[5]
Lisa Dziuba. 2019. Accessibility tools for designers and develop-
ers. https://uxdesign.cc/accessibility-tools- for-designers- and- developers-
ea400a415c0a. Last Accessed: 2022-6-11.
[6]
Tânia Frazão and Carlos Duarte. 2020. Comparing Accessibility Evaluation Plug-
Ins. In Proceedings of the 17th International Web for All Conference (Taipei, Taiwan)
(W4A ’20). Association for Computing Machinery, New York, NY, USA, Article
20, 11 pages. https://doi.org/10.1145/3371300.3383346
[7] Google. n.d.. Material Design. https://material.io. Accessed: 2020-07-18.
[8]
Samine Hadadi. 2021. Adee: Bringing Accessibility Right Inside Design Tools. In
The 23rd International ACM SIGACCESS Conference on Computers and Accessibility
(Virtual Event, USA) (ASSETS ’21). Association for Computing Machinery, New
York, NY, USA, Article 101, 4 pages. https://doi.org/10.1145/3441852.3476478
[9]
Shawn Lawton Henry and Andrew Arch. 2012. Financial factors in de-
veloping a web accessibility business case for your organization. W3C.
http://www.w3.org/WAI/bcase/n#decreasing. Accessed: 2014-08-16..
[10]
Shayna Hodkin. 2019. 8 tools that make accessible design easier. https://www.
invisionapp.com/inside-design/accessibility- tools/. Last Accessed: 2022-6-11.
[11]
Gopinaath Kannabiran and Susanne Bødker. 2020. Prototypes as Objects of Desire.
Association for Computing Machinery, New York, NY, USA, 1619–1631. https:
//doi.org/10.1145/3357236.3395487
[12] Andrew Kirkpatrick, Joshue O’Connor, Alastair Campbell, and Michael Cooper.
2018. Web Content Accessibility Guidelines (WCAG) 2.1.
[13]
Chris Law, Julie Jacko, and Paula Edwards. 2005. Programmer-Focused Website
Accessibility Evaluations. In Proceedings of the 7th International ACM SIGACCESS
Conference on Computers and Accessibility (Baltimore, MD, USA) (Assets ’05).
Association for Computing Machinery, New York, NY, USA, 20–27. https://doi.
org/10.1145/1090785.1090792
[14]
Jonathan Lazar, Patricia Beere, Kisha-Dawn Greenidge, and Yogesh Nagappa.
2003. Web accessibility in the Mid-Atlantic United States: a study of 50 homepages.
Universal Access in the Information Society 2, 4 (2003), 331–341. https://doi.org/
10.1007/s10209-003- 0060-z
[15]
Junchen Li, Garreth W. Tigwell, and Kristen Shinohara. 2021. Accessibility of
High-Fidelity Prototyping Tools. In Proceedings of the 2021 CHI Conference on
Human Factors in Computing Systems (Yokohama, Japan) (CHI ’21). Association
for Computing Machinery, New York, NY, USA, Article 493, 17 pages. https:
//doi.org/10.1145/3411764.3445520
[16]
Adriana Martín, Alejandra Cechich, and Gustavo Rossi. 2011. Accessibility at
Early Stages: Insights from the Designer Perspective. In Proceedings of the Inter-
national Cross-Disciplinary Conference on Web Accessibility (Hyderabad, Andhra
Pradesh, India) (W4A ’11). Association for Computing Machinery, New York, NY,
USA, Article 9, 9 pages. https://doi.org/10.1145/1969289.1969302
[17]
Microsoft. n.d.. Universal Windows Platform documentation. https://docs.
microsoft.com/en-gb/windows/uwp. Accessed: 2020-07-18.
[18]
Marian Padure and Costin Pribeanu. 2020. Comparing six free accessibility
evaluation tools. Informatica Economica 24, 1 (2020), 15–25. https://doi.org/10.
24818/issn14531305/24.1.2020.02
[19]
Taylor Palmer and Jordan Bowman. 2020. 2020 Design Tools Survey. https:
//uxtools.co/survey-2020#conclusion. Last Accessed: 2022-6-11.
[20]
K. Schneider. 1996. Prototypes as assets, not toys. Why and how to extract
knowledge from prototypes. (Experience report). In Proceedings of IEEE 18th
International Conference on Software Engineering. 522–531. https://doi.org/10.
1109/ICSE.1996.493446
[21]
Garreth W. Tigwell. 2021. Nuanced Perspectives Toward Disability Simulations
from Digital Designers, Blind, Low Vision, and Color Blind People. In Proceedings
of the 2021 CHI Conference on Human Factors in Computing Systems. Association
for Computing Machinery, New York, NY, USA, Article 378, 15 pages. https:
//doi.org/10.1145/3411764.3445620
[22]
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
[23]
Shari Trewin, Brian Cragun, Cal Swart, Jonathan Brezin, and John Richards.
2010. Accessibility Challenges and Tool Features: An IBM Web Developer
Kokate et al.
Perspective. In Proceedings of the 2010 International Cross Disciplinary Confer-
ence on Web Accessibility (W4A) (Raleigh, North Carolina) (W4A ’10). Asso-
ciation for Computing Machinery, New York, NY, USA, Article 32, 10 pages.
https://doi.org/10.1145/1805986.1806029
[24]
Brian Wentz, Paul T Jaeger, and Jonathan Lazar. 2011. Retrotting accessibility:
The legal inequality of after-the-fact online access for persons with disabilities
in the United States. First Monday 16, 11 (Nov. 2011). https://doi.org/10.5210/fm.
v16i11.3666
... Improved design tools for accessible design have been suggested as one way to address resource restrictions [19,33,44], yet, our participants felt current tools (e.g., design plugins) did not adequately support their needs. Therefore, more attention is needed on exploring resources such as tools to support light and dark mode design. ...
Article
Full-text available
Mobile app light and dark modes offer improved usability within different contexts (e.g., dark mode for easier night reading). Yet, little research has investigated the prevalence of light and dark modes across platforms, the intricacies of UI color changes, and challenges in the design and development process. Our investigation focused on comparing light and dark mode designs. We carried out a manual inspection of 120 popular Android and iOS apps to find that only 55% (Android) and 48% (iOS) of the apps included any modes. We also found significant variability in how many UI elements changed between modes. We interviewed 15 designers and developers to understand the creative process, motivations for design decisions, and what challenges exist in the processes that affect alternative mode implementation. We identified several issues that HCI researchers are equipped to solve, ultimately improving support for mobile app creators looking to implement dark modes (and beyond) for increased mobile usability in different contexts.
Conference Paper
Full-text available
Designers of digital content have access to various resources that they use to help them meet disabled people's accessibility needs. Disability simulations are one resource, but often criticized for failing to guide digital designers appropriately, and it is unclear if digital designers are aware of the issues surrounding disability simulations. I surveyed 92 digital designers to understand their perspectives toward disability simulations (both perceived advantages and disadvantages). I then shared work process challenges faced by digital designers and their reasons for using disability simulations with 17 people with vision impairments to facilitate a discussion on this topic. The interviewees discussed ideas that suggest many paths can be explored to connect digital designers and disabled people, in general, to reduce reliance on simulations, and a change is needed within workplace processes, culture, and staffing to further support positive change. There are research opportunities to investigate establishing avenues for connecting digital designers and disabled people in a way that is beneficial to both groups.
Article
Full-text available
The web is continuously growing in content and functionality having an important impact on society. An objective of the Digital Agenda for Europe is to make the web technologies available for all. Recently, a European directive has been issued that requires the accessibility of public websites by September 2020. Given the low accessibility of public websites, systematic evaluation and monitoring strategies are needed. Covering the huge number of public websites with reasonable effort is only possible in a tool-based approach which makes the selection of a suitable tool a critical issue. The goal of this paper is to compare six accessibility evaluation tools as regards the coverage of accessibility-related issues, identification, reporting, and documenting of accessibility errors. The comparison is illustrated with six case studies of Romanian municipal websites. The results show large differences as regards the way of reporting and the number of errors which suggest that only one tool is not enough.
Conference Paper
This paper examines the promise of empathy, the name commonly given to the initial phase of the human-centered design process in which designers seek to understand their intended users in order to inform technology development. By analyzing popular empathy activities aimed at understanding people with disabilities, we examine the ways empathy works to both powerfully and problematically align designers with the values of people who may use their products. Drawing on disability studies and feminist theorizing, we describe how acts of empathy building may further distance people with disabilities from the processes designers intend to draw them into. We end by reimagining empathy as guided by the lived experiences of people with disabilities who are traditionally positioned as those to be empathized.
Article
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, daprlab.com/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
The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) develops strategies, guidelines, and resources to make the Web accessible to people with disabilities. This includes ensuring that core web technologies such as HTML and CSS provide support for accessibility; developing complementary web specifications to support accessibility, such as WAI-ARIA and IndieUI; and maintaining a set of internationally recognized guidelines that define accessibility criteria for web authoring tools such as content management systems and code editors, for user agents such as web browsers and media players, and for web content including text, images, scripts, audio-visual media, and more. This communication paper explores the impact on these essential components of web accessibility as the Web rapidly evolves into an increasingly mobile and ubiquitous medium, and highlights opportunities for research and development to help make the Web universally accessible to all users.
Conference Paper
Suggested methods for conducting website accessibility evaluations have typically focused on the needs of end-users who have disabilities. However, programmers, not people with disabilities, are the end-users of evaluations reports generated by accessibility specialists. Programmers' capacity and resource needs are seldom met by the voluminous reports and long lists of individual website fixes commonly produced using earlier methods. The rationale for the need to consider the whole website development process, and the social characteristics of programmers and project managers is presented. A new programmer-centric Streamlined Evaluation and Reporting Process for Accessibility (SERPA) is described in detail.