Development of the AASPIRE Web Accessibility Guidelines for Autistic Web Users

Abstract

Websites figure predominantly in everyday life. However, many websites remain inaccessible to autistic people, and existing efforts to improve accessibility are in early stages, do not directly include autistic users in their development, or have not been empirically evaluated. The Academic Autism Spectrum Partnership in Research and Education (AASPIRE) used a community-based participatory research approach to create a website to improve health care access for autistic adults. We used the creation of that website as a “living laboratory” to develop the AASPIRE Web Accessibility Guidelines for Autistic Web Users. Our guidelines are grounded in accessibility theory, had autistic end-user involvement at all stages, and were empirically evaluated through a usability study and evaluation surveys. We incorporated what we learned into the design of the website, and compiled the accessibility information into a set of guidelines. The guidelines offer recommendations for increasing the physical, intellectual, and social acceptability of websites for use by autistic adults. In the evaluation of the website by 170 autistic end users, nearly all indicated it was easy to use (97%), easy to understand (95%), important (97%), and useful (96%). Ninety-two percent would recommend it to a friend, and 95% would recommend it to a health care provider. There were no significant associations between usability or understandability and education level, receipt of help using the site, browser type (e.g., IE or Safari), or device type (e.g., PC or tablet). We recommend using the guidelines to improve website accessibility for autistic Internet users.

Lay Summary

AASPIRE Web Accessibility Guideline: This guideline is a summary of the accessibility features we identified and implemented during the course of our study. None of these items were difficult or expensive for us to implement. They did not require special expertise beyond basic web programming and technical communications skills. We recommend that anyone seeking to create accessible websites for autistic users follow the Academic Autism Spectrum Partnership in Research and Education (AASPIRE) Web Accessibility Guideline in addition to broader web and communications standards and principles.

Physical accessibility:

• Provide at least one low-contrast neutral color palette option to accommodate sensitive vision.

• Provide a selection of color palettes, including one with a dark background and one with a light background, again to accommodate color and contrast sensitivity.

• Provide a no-style option (i.e., no cascading style sheets (CSS) to accommodate browser customization and users who prefer no stylistic formatting.

• Provide simple consistent navigation and highly consistent site behavior for increased ease of operation.

• Avoid textured backgrounds, moving images, decorative elements that do not convey information, and other visual and/or sonic “clutter”; these types of elements may make the site difficult or impossible to comprehend.

• Provide smaller font sizes in addition to larger ones; large font sizes may make the page appear cluttered and difficult to read.

• Use a plain accessible sans-serif font (e.g., Arial) for ease of readability.

Intellectual accessibility:

• Use the simplest interface possible for ease of understanding.

• Use simple concrete icons or images to communicate redundant information with text, and accommodate multiple ways of understanding information.

• Clearly label site elements with their purpose everywhere on the site, even if it seems redundant, to make navigation and site functionality easier to follow.

• Provide concrete examples where applicable to accommodate difficulties in understanding abstractions or generalizations.

• Minimize scrolling so the user does not need to rely on assumptions about content to guess what might be on the page.

• Show all important features and site navigation (as opposed to within combo box drop-down areas) so the user does not need to rely on assumptions to guess whether the item exists and how to access it. For example, completely visible list boxes or radio buttons can be used instead of combo boxes.

• Make content as short as possible without sacrificing precision and specificity, to reduce cognitive burden.

Social accessibility:

• Be specific and precise in language use; avoid colloquialisms, idioms, and ambiguity to accommodate difficulties with language pragmatics.

• Explain the reason behind any nonstandard instructions or unusual information; provide additional pragmatic context to accommodate difficulties with language pragmatics.

• Provide alternatives to definitive response items on surveys and forms, for example, “do not know,” “do not wish to say,” or “not applicable,” to reduce frustration for not being able to produce an exact answer.

• Use FAQ formats to organize complex information to enhance clarity as to why the information might be useful to the user and how it connects to their life.

• Define terms that might have different meanings depending on social context, or which might be jargon related to a specialized field (e.g., “drug interactions” and “health care providers”), to accommodate difficulties with language pragmatics.

• Be mindful of autistic culture and community preferences, including the language used to describe autism and how community-based symbols and history might influence content and perception of site credibility.

Introduction

Internet accessibility and autism

The internet, including the World Wide Web, is woven into the fabric of life in much of the world, and is instrumental in activities such as finding employment and housing, managing bank accounts, navigating maps, accessing health systems and health information, and staying informed about local and world events. Web accessibility for autistic users may be especially important, as a large number of them likely use the internet,^1–3 and the autistic community has developed largely through web-based interaction.^4,5 The Internet has been called “to autistic people what [American Sign Language] is to the deaf.”⁶ Indeed, a recent online survey reported that the Internet helped autistic people communicate more than it helped nonautistic people because of its textual basis, provisioning of time to think, unique opportunities for practicing social interaction (including control of which people with whom to interact, and control of communication media), facilitation of meeting similar people, and expression of one's true self.⁷ However, uneven attention has been paid in existing guidelines to the specific web accessibility needs of people on the autism spectrum, which may be different from the needs of people with other types of disabilities.

Web accessibility refers, broadly, to making the web accessible to all, including people with a variety of disabilities, or functional limitations. Multiple policy guidelines, such as Section 508 of the U.S. Rehabilitation Act⁸ and the United Nations Web Accessibility Mandate,⁹ support individuals' rights to accessible web-based information. The international body responsible for setting the technical standards on which the web operates—the World Wide Web Consortium—includes the Web Accessibility Initiative (WAI),¹⁰ which developed and maintains the Web Content Accessibility Guidelines (WCAG). The WCAG provides a set of technical standards to address concerns of interface detection, control, comprehension, and cross-platform sustainability, which are broadly implemented throughout today's web. Most web accessibility features are cost-effective and simple to implement,¹¹ particularly if implemented from the outset. However, major accessibility standards such as the WCAG were largely created by and for individuals with physical and sensory (i.e., vision and hearing) disabilities, not by individuals with other sensory processing, communication, or cognitive disabilities, such as many people on the autism spectrum. Aware of this, the WAI convened a Cognitive and Learning Disabilities Task Force¹² to provide guidance around cognitive accessibility; however, this study remains in preliminary stages,¹³ and it is unclear if any of the individuals on the task force are autistic.

Involving autistic people in developing web accessibility guidelines matters because of the great need for end-user engagement in both the creation of accessible websites,^14–21 and in disability-related research.^22–25 Individuals who do not have a particular disability lack the first-hand experience that provides important insight into understanding effective access strategies for those who do, or even which functional limitations need to be accommodated.^26,27 Although laudable, the idea of “universal design” (accessibility features that work for everyone) is ultimately impractical due to the fact that access needs can conflict with each other. For example, some guidelines intended for people with intellectual disability^17,19,20 recommend simplifying vocabulary, which—if implemented without retaining the precision afforded by more complex wording—can make language pragmatics more difficult for autistic users to understand.^28,a Likewise, high-contrast color schemes suitable for people with low vision may be painful or unreadable to autistic users with hypersensitive vision.

Internet spaces made by and for autistic users may incorporate accessibility features naturally; however, there is little guidance for developers of websites, including those who may want to take advantage of some autistic people's affinity for the Internet, to develop resources for autistic adults. Clear guidelines, informed by autistic end users and developed through a systematic process, are needed.

Our aim was to use a community-based participatory research (CBPR) approach to create a set of guidelines for developing accessible websites targeting autistic web users. We created these guidelines from lessons learned during the development and evaluation of a website focused on health care for autistic adults.

AASPIRE and the AASPIRE Healthcare Toolkit project context

The Academic Autism Spectrum Partnership in Research and Education (AASPIRE) is a long-term CBPR collaboration comprised of autistic adults, academic researchers, and other stakeholders. In this article, we describe several accessibility lessons learned during a 3-year study to create and test an interactive web-based toolkit for improving health care access and quality for autistic adults in the United States.²⁹ During the study we solicited feedback about web accessibility from autistic participants and from our own CBPR team, which consists mostly of autistic adults. After the research was completed, we compiled the accessibility lessons into the AASPIRE Web Accessibility Guidelines presented in this article. The full details of the research project (the AASPIRE Healthcare Toolkit project) are reported in-depth elsewhere.^29–31 However, it is important to understand the context of the research project, since we used it as the “living laboratory” in which to develop and validate the accessibility features that we then compiled into the guidelines.

The 3-year research project consisted of four study components that are described in varying detail in this article. Two study components primarily informed the accessibility features used on the website: (1) qualitative interviews with autistic adults about their health care experiences and ideas for interactive online health care tools³⁰ and (2) a series of studies to develop, refine, and test an accessible online survey tool that is used as part of the website.^29,32,33 The other two study components verified and evaluated our accessibility features: (1) a usability study of the initial (alpha) version of the website and (2) an evaluation of the revised (beta) version of the website. The results of the interview and survey tool components are summarized where relevant; the results of the usability study and the evaluation study are presented in this study in greater detail.

The AASPIRE Healthcare Toolkit consists of an informational website and an interactive report generator called the Autism Healthcare Accommodations Tool (AHAT). The AHAT uses the accessible online survey tool to collect information and then generates a customized health care accommodations report for health care providers and their staff. The intended audience for the site is autistic adults, people who support them in health care, and health care providers. The toolkit can be found online.^b See Figure 1 for a map of the full project.

FIG. 1.

AASPIRE Healthcare Toolkit project. AASPIRE, Academic Autism Spectrum Partnership in Research and Education.

Theoretical foundation

We compiled what we learned from our study in the “living laboratory” of the AASPIRE Healthcare Toolkit project into the AASPIRE Web Accessibility Guidelines, using existing theory and established principles of web accessibility. As a theoretical foundation, we used the “information worlds” model provided by Jaeger and Bernett (Jaeger 2011).¹¹ The model defines three dimensions of information access: physical, intellectual, and social. Physical accessibility has received the most focus on the web¹¹; examples include image descriptions, forms that are navigable by keyboard, user-controlled font sizes, and other accommodations for sensory disabilities. An example of intellectual (i.e., cognitive) accessibility is translating prose into a simpler and less abstract vocabulary. Examples of social accessibility would be content that explicitly spells out language pragmatics, or content that takes social or cultural context into account; for example, avoiding the use of the jigsaw-puzzle symbol for autism because in autistic and neurodiversity culture, this symbol is considered dehumanizing.^34,35

As guiding principles for physical accessibility, we used the principles of the WCAG, the most widely used web accessibility standard: sites must be perceivable (can users make it out?), operable (can it be controlled?), understandable (can it be comprehended?), and robust (can it run on current and likely future technologies?).^36,37 As guiding principles for intellectual and social accessibility, we used the principles of the plain language movement. Plain language is defined behaviorally by the Center for Plain Language: “Can the people who are the audience for the material quickly and easily find what they need, understand what they find, [and] act appropriately on that understanding.”³⁸

Methods to Create the Guidelines

CBPR process

AASPIRE uses a CBPR approach, with autistic adults and academic scientists (not necessarily mutually exclusive roles) contributing equitably to the study.^39,40 We have been working together for more than a decade, and meet and make decisions together through text-based chat, selective in-person meetings, and a group mailing list.^41,42 Throughout the project, adult autistic web users on our team led accessibility discussions and provided solutions. Figure 2 summarizes the iterative developmental process. The figure shows the nature of involvement by autistic people at each stage: on our CBPR team, as research participants, or by autistic staff; the lead web developer and technical writer, and first author of this article, is autistic. This section describes our process for generating, and then verifying, our accessibility solutions.

FIG. 2.

Website Development Process.

Website content

The website development began by reviewing information from our qualitative interviews on the experiences of autistic adults in health care,³⁰ as well as our team's ideas for what might be helpful to them or to other autistic people. Staff compiled those ideas into an outline of content to include and presented it to the full team for further development.

Accessibility discussions focused on making the content intellectually and socially accessible. Qualitative study participants and research team members noted significant problems with existing websites and descriptions of medical practice, and offered recommendations for overcoming them. Examples are not assuming that patients can use the telephone to make appointments, attending to sensory and organizational challenges related to exercise, and addressing how to make a change in diet when someone else, such as a care provider, is in charge of one's food. We discussed whether to include a potentially controversial section on therapy, which autistic people have found both a source of increased quality of life and a source of harm or oppression.^43–45 We decided that we would be able to present therapy in a way that was socially accessible by drawing on the expertise of the autistic members of the team.

In creating the full draft of the content, staff writers implemented WCAG and plain-language principles, and drew on our autistic partner's expertise. We wrote at an eighth-grade reading level, used specific and precise language, and avoided idioms, minimized length, and used an FAQ-formatted information architecture. More explanation of social context was added than would be for other audiences, such as through inclusion of interaction scripts (e.g., for making an appointment, requesting accommodations from a health care provider, or asking for a referral for a diagnosis).

Staff provided the draft to the full team for review and additional accessibility checks. Autistic team members highlighted the following additional accessibility points and examples for intellectual and social accessibility.

• Content modifications based on lived experience: knowing it is possible to be evaluated for autism even if no one is available to give an early childhood report, information about free clinics, and explaining why health care providers might be antagonistic toward accommodation requests.

• Clarifications of ambiguities: how to communicate medicine dosages if more than one is listed on the label, acceptability of leaving blanks on intake forms, prefacing recommendations with “not all of these items may apply to you.”

• Enhanced precision of language: specifying “call or email” instead of “contact,” defining “health care providers,” providing examples for open-ended recommendations (“advocate for accommodations in the waiting room—adjust the music, lights, etc.”).

• Clarifications due to community-specific context: clarifying special diet as “diabetic diet” or ”low-salt diet” (not a “cure-autism” diet), changing “wait in my car” to “wait outside” so as not to presume the person has a car.

• Recommendations for restructuring text to reduce length or increase clarity: removing nonessential items from a long list, referencing repeated information in a single separate section instead of pasting it repeatedly.

• Simplifying language or reducing reading level through multiple wording changes.

Website user interface

Simultaneously with the content development, staff created mock-ups of how the website might look. Because the lead developer was autistic, accessibility features were built into the mock-ups, including using a low-contrast color theme, an accessible sans-serif font, and visual simplicity, including plain flat backgrounds.

In discussion, the team came to consensus on preferred layout quickly; however, the color palette was more difficult. Team members expressed divergent preferences and noted that the “wrong” palette could lead to eye strain, migraines, and an inability to read the text. Furthermore, although a low-contrast palette is an accessibility need for many autistic people, it presents a barrier to accessibility for individuals with low vision. We decided to create multiple color themes—users could choose based on preference—including two high-contrast themes that met the WCAG for contrast ratio,¹⁰ with a default palette similar to that of the AASPIRE website, which has a low-contrast purple and tan theme that everyone on the team liked. Having multiple color options has provided unusual benefits to autistic people, such as reading words and facial expressions.^46,47

Staff created the website from the selected mock-up, implementing user-controlled font sizes and color themes, including a “theme” with no formatting at all; a simple and clutter-free interface; predictable navigation and layout; and use of simple but meaningful icons to delineate and organize content areas and topics. The full team then reviewed the working website and made the following further accessibility comments and requests.

For intellectual accessibility:

• Decreasing clutter: remove or visually tone down horizontal lines as separators and increase use of white space.

• Reducing scrolling: make all navigation and key page elements visible in a typically sized browser window.

• Increasing predictability: position similar elements in the same place on various pages, add “breadcrumbs” (indicators of location in a hierarchical structure) even for shallow navigation trees.

• Reinforcing information architecture with icons: increase usage of icons, because they provide redundancy with the nature of the content, and make it easy to understand how the content is structured.

For social accessibility:

• Increasing explicitness: use words on the home page to make it very clear what the site is about and why someone might use it; replace “change skin” with “change theme”; make key areas, such as the entry point for the AHAT, more distinct.

• Replacing icons with unwanted symbolism: butterfly held too many pre-existing connotations within the autistic community, lightning bolt communicated aggression.

For physical accessibility:

• Adding colors: provide alternatives, including a theme with a dark background and a theme with a light background, for both the low- and high-contrast palettes.

Interactive survey tool

The interactive survey tool generates a customized accommodations report for health care providers based on how a user completes a web-based form. It was built on Portland State University's Audio Computer-Assisted Self-Interview (ACASI) platform, a web-based survey tool previously developed in partnership with individuals with a wide range of disabilities, including autistic people. It incorporates several accessibility features,^32,33 including read-aloud (feedback from participants was that the inflection of human-recorded speech, not computer-generated, is what enabled them to understand the information), user-controlled font sizes, consistent and clutter-free navigation, the capacity to play American Sign Language translations of text, and screen reader optimization. A detailed description of the ACASI software can be found elsewhere.³³

AASPIRE team members liked the neutral colors and the existing accessibility features, and no one had difficulty using the survey. They identified accessibility barriers as (1) the inability to go back to previous pages; (2) dependence on Flash (an online application that was popular at the time) for the nonscreen reader version, which limited compatibility with some platforms and with assistive technology; and (3) lack of alternative color schemes. We added a “back” button and addressed the Flash issues by rebuilding the platform in HTML5, and merging the screen reader and main versions. We deferred providing alternative color schemes for a future version.

We configured the tool to work with our application, and made the accessibility changes recommended by the group. We then conducted a brief preliminary evaluation of just the tool with autistic participants and supporters; it included a cognitive interview of the survey items, and a short questionnaire about perceived usability, accessibility, and acceptability. Details are available elsewhere²⁹; in this study, we summarize findings relevant to the website accessibility.

Regarding intellectual and social accessibility, participants were able to paraphrase survey content, and the overwhelming majority said the material was easy to understand. Qualitative suggestions for improving the user interface included the issues identified by our team. They also included: (1) clarifying the reason for open-ended items; (2) adding a “not sure” or “N/A” option to reduce anxiety about not being able to answer exactly; (3) allowing people to write in their own answers instead of selecting from the checklists; and (4) correcting a confusing combination of a checkbox and a narrative-text (write-in) field. Participants noted the need to reduce the font sizes to display more text per page, and to minimize scrolling. We made all of these changes except allowing people to provide narrative responses, because this would have interfered with core aspects of the intervention. This both confirmed that the accessibility features of the survey tool were otherwise working, and provided some additional information about desirable features to be added.

Alpha website usability testing

Methods

Staff implemented all accessibility changes, and put the full toolkit together. We then conducted a usability study⁴⁸ of the site. We recruited participants through community connections in the Portland, Oregon Metro area. Participants needed to be live in the Portland, Oregon metro area as the study was administered in person, and be at least 18 years of age. They also had to be one of the three intended audiences for the website, defined as meeting one of the following criteria: (1) be diagnosed with an autism spectrum disorder (ASD); (2) support someone who has been diagnosed with an ASD; or (3) be a primary care provider. These three populations are the audiences for the website. In addition, participants were purposefully selected to represent a range of comfort with Internet technology, a range of educational levels, and multiple target use cases (task-oriented, exploratory, and proxy—using the site on behalf of a family member or client).

We followed a typical protocol for software usability testing,⁴⁸ where participants were asked to complete a series of tasks involving the website functionality while the first author observed, asked follow-up questions, and recorded the results. Data recorded on the tasks were (1) whether it could be completed; (2) how long it took to complete; (3) observations (e.g., of what the participant was doing with their mouse); and (4) participant comments. Tasks covered basic web functionality (e.g., search and navigation), accessibility functions (e.g., color theme switching and font size control), and functionality specific to the toolkit (e.g., downloading content for offline use).

The first author met with participants in person. With the exception of one health care provider, the study was conducted in the same location with the same equipment. Where there appeared to be a usability problem, the first author probed participants for ideas for why the problem might exist, and what might fix it. The first author placed both verbal information (e.g., participant comments about locating a link) and behavior from participants (e.g., whether their mouse pointer found the link quickly) into a series of matrices to assess usability issues, and prioritized the issues based on severity (to what degree did it affect the person's ability to find and make use of the data) and pervasiveness (how many people had the same experience).⁴⁸ During the process, the first author referred to observational field notes and participant comments to gain a more in-depth understanding of issues, and relied on their experience as a programmer to make decisions about what to address from the aggregate issues matrix based on severity ranking and the level of effort to correct the issue. The full team then met to discuss the findings.

Results

Eight people participated: three autistic, three supporter, and two primary care providers. This is a typical and sufficient number of participants for a usability study.⁴⁹ They were aged 18 to 50 years, and were diverse in observed technical ability and self-reported education (Table 1). Although all participants were able to complete the tasks, they did identify several usability issues, which are summarized in Table 2. The issues of highest priority were a consequence of the forms and worksheets displaying as the default page after entering the patient or provider side from the home page, and lack of clear labeling for the topic and outline navigation. These issues were remedied by defaulting to a topic summary page and adding headers. The usability issues were not specific to any one user group; in cases where an issue was reported by more than one person, those individuals spanned multiple stakeholder groups. This was important to us, since all three audiences would be using the site. It also made it clear that the issues were general user interface problems, not accessibility problems.

Table 1.

Usability Demographics

Website usability study
Stakeholder group
Autistic	3
Supporter	3
PCP	2
Age
18–34	2
35–50	2
50+	4
Gender
Male	2
Female	6
Education
HS or modified diploma	2
Undergraduate degree	3
Graduate degree	3
Technical ability (observed)
Low	3
Medium	3
High	3

HS, high school; PCP, primary care provider.

Table 2.

Usability Matrix

No. of reports	Severity	Issue	Actions	Stakeholders
1	High	Not clear site is about autism	Add some identifiers	pcp
1	High	Overwhelming and not clear what would be relevant (PCP side)	Redo the information architecture for the PCP side	pcp
3	High	Topic and outline links not clear	Add “Topics” or “Outline” header above the links	aut
3	High	Topics not clear	Change default to splash page to description of topics	aut, sup
1	Med	Did not process right-hand side of main page where AHAT link is	Add AHAT link also to topic list on left-hand side	aut
1	Med	Not clear site is about primary care only	Add some identifiers	sup
1	Med	Font size adjuster hard to read for someone with low vision	Make high contrast always	n/a
1	Med	Printed PDFs lack navigation and branding	Add table of contents and branded footer to PDFs	aut
1	Med	Close window button only relevant in the pop-up print version	Hide close window button when “No CSS” used as theme	aut
3	Low	Slight crowding/narrow margins	Make white space a little bigger, bullet links	aut, pcp
1	Low	Could not find detail actions (print, email, download)	Thought a special “tool” area on the top bar might work	aut
3	Low	Looked for static content links on bottom of page	Add static links to bottom in addition to top	aut, sup pcp
5	Low	Graphic for switching sides not effective; unclear what it will do	Change graphic to plain text; consider other ideas	aut, sup, pcp
5	Low	Dropdown to change back to layout hard to find on no CSS theme	Place dropdown in same place as on formatted layout	aut, sup
1	Low	Insufficient PDF identification and resources	Add PDF indicator, link to Acrobat, information for how to get alternative format	aut
1	Low	Looked for email on main page	Offer email option in a special content area on the main page	aut
1	Low	Not sure what “No CSS” meant	Change to “no layout”	aut

Italicized items not addressed due to determination of limited benefit given the effort to implement effectively.

AHAT, Autism Healthcare Accommodations Tool; aut, autistic adult; CSS, cascading style sheets; pcp, primary care provider; sup, person who supports an autistic adult in health care settings.

Participants were encouraged to “think out loud” as they performed the usability tasks. Several participants noted the accessibility features of the site during their dialogue. Autistic participants said that they appreciated the ability to change colors (“because some people may have a harder time seeing one… not many sites I know do that”); appreciated the icons and the simple, predictable navigation (“I like how you can go back to top from any place so you don't get lost”); the lack of clutter (“calming not to have the splashings and the fancies”); and the highly structured information architecture and FAQ-formatted content (“clear, categorical information in an accessible format is great and sorely needed. Most sites present information in the form of vague statements instead of a question…this is an intuitive web site…it's in question form so I know where to go”). The results of the usability study help verify that we were able to create an accessible website by drawing on the expertise of the autistic people on our research team.

Staff revised the website to address the issues identified during the usability testing. We used the resulting beta site in the Beta Website Evaluation, described next.

Beta website evaluation

Methods

We conducted an evaluation of the AASPIRE Healthcare Toolkit to determine its feasibility and acceptability as an intervention to improve health care for autistic adults. Details of that study can be found elsewhere.²⁹ In this study, we describe the results of the subset of evaluation items related to the usability and accessibility.

Our sample included U.S. residents age 18 or older who also met at least one of the following criteria: (1) diagnosed with an ASD, and/or (2) providing support to an individual diagnosed with an ASD who would not be able to participate in the study themselves, even with accommodations and supports. We recruited a convenience sample of participants through word of mouth and our networks, including community electronic mailing lists, local developmental disabilities agencies, and social media. We also recruited through broader online recruitment channels, including the Interactive Autism Network^c and several general online study recruitment boards.

Participants took a preusage survey, which then directed them to the beta website. One month later, we sent participants a link to a postusage survey that included the evaluation questions about the website. Multiple-choice questions on the postusage survey asked how easy the website was to use and understand, how important and useful the information was, and whether participants would recommend it to friends or primary care providers. Open-ended items solicited information about what the participant liked most and least about the website, what they thought was most useful, and recommendations for how to improve the website.

We analyzed quantitative data using Stata 11 (College Station, TX).⁵⁰ The primary analysis consisted of summary statistics for the combined patient and supporter populations. We conducted a secondary analysis using chi-squared tests for association between evaluation variables and the population, education level, and browser and device type used. We summarized the recommendations provided in the open-ended items.

Results

Demographics from the 170 participants are in Table 3. They represented a diverse range of age (18–63), gender (54% female, 44% male, and 2% other), educational attainment (19% high school or less, 25% some college, 37% undergraduate degree, and 18% graduate degree), and support needs (63% needed support always or often to receive health care). Most participants accessed the site through a desktop or laptop computer, and in a Google Chrome or Mozilla Firefox browser. Nearly all participants found the toolkit easy to use (97% N = 120 very easy or somewhat easy) and easy to understand (95% N = 117 all or most of the site). Most indicated that the information was important (63% N = 79 very important; 34% N = 42 kind of important). Most indicated that the information was useful (53% N = 63 very useful; 43% N = 53 somewhat useful). Ninety-two percent (N = 105) would recommend the toolkit to a friend, and 95% (N = 111) would recommend it to a health care provider.²⁹ In t-tests for association, no significant associations were found between usability or understandability and education level, receipt of help using the site, browser type, or device type.

Table 3.

Evaluation Demographics

Toolkit evaluation study
Study participation
Participated independently	70% (123)
Participated with support	10% (18)
Proxy	19% (34)
Age
Average	36.5
Standard deviation	12.9
Range	18–68
Gender
Male	44% (75)
Female	54% (91)
Other	2% (4)
Education
High school or less	19% (32)
Some college (no degree)	25% (43)
Undergraduate degree	37% (63)
Graduate degree	18% (31)
Non-Hispanic white	86% (142)
Requires assistance to receive health care
Always or often	32% (54)
Sometimes	31% (52)
Rarely or never	37% (61)
Device used
PC or laptop	88% (111)
Tablet	8% (10)
Smart phone	4% (5)
Browser used
Chrome	29% (38)
Firefox	33% (43)
IE 9+	16% (21)
IE 8-	3% (4)
Safari	16% (21)
Opera	1% (1)
Other	2% (3)

Qualitative comments related to access and usability were minimal. The most frequent recommendation was alternative color schemes on the survey tool, confirming what we already believed. A few participants felt that the survey tool's user interface was too cluttered, possibly due to some items having a large number of possible options; this was addressed by the use of formatting in a subsequent release. Some participants noted the accessibility and usability as what they appreciated about the site: “the questions aren't vague, and they are easy to understand,” “it was easy to navigate and it was free,” and “very well organized and easy to use.”

Based on these evaluation data, we feel that the features that we identified throughout our processes created a highly accessible website for a population of autistic users with a diverse range of age, gender, education, and support needs.

The public release of the toolkit can be found at https://autismandhealth.org. Future releases will add user-controlled color themes to the survey tool user interface.

AASPIRE Web Accessibility Guidelines

These guidelines are a summary of the accessibility features we identified and implemented during the course of our study. None of these items were difficult or expensive for us to implement. They did not require special expertise beyond basic web programming and technical communications skills. We recommend that anyone seeking to create accessible websites for autistic users follow the AASPIRE Web Accessibility Guidelines, in addition to broader web and communications standards and principles such as the WCAG.

Physical accessibility

• Provide at least one low-contrast neutral-color palette option to accommodate sensitive vision.

• Provide a selection of color palettes, including one with a dark background and one with a light background, to accommodate color and contrast sensitivity.

• Provide a no-style option (i.e., no CSS) to accommodate browser customization and users who prefer no stylistic formatting.

• Provide simple consistent navigation and highly consistent site behavior for increased ease of operation.

• Avoid textured backgrounds, moving images, decorative elements that do not convey information, and other visual or sonic “clutter”; these types of elements may make the site difficult or impossible to comprehend.

• Provide smaller font sizes in addition to larger ones; large font sizes may make the page appear cluttered and difficult to read.

• Use a plain accessible font such as a sans-serif font (e.g., Arial) for ease of readability.

Intellectual accessibility

• Use the simplest interface possible for ease of understanding.

• Use simple concrete icons or images to communicate redundant information with text, and accommodate multiple ways of understanding information.

• Clearly label site elements with their purpose throughout the site, even if it seems redundant, to make navigation and site functionality easier to follow.

• Provide concrete examples where applicable, to accommodate difficulties in understanding abstractions or generalizations.

• Minimize scrolling, so that the user does not need to rely on assumptions about content to guess what might be on the page.

• Show all important features and site navigation, as opposed to within combo box drop-down areas, so the user does not need to rely on assumptions to guess whether the item exists, and how to access it. For example, completely visible list boxes or radio buttons can be used instead of drop-down combo boxes.

• Make content as concise as possible without sacrificing precision and specificity, to reduce cognitive burden.

Social accessibility

• Be specific and precise in language; avoid colloquialisms, idioms, and ambiguity to accommodate difficulties with language pragmatics.

• Explain the reason behind any nonstandard instructions or unusual information; provide additional pragmatic context to accommodate difficulties with language pragmatics.

• Provide alternatives to definitive response items on surveys and forms, such as, “do not know,” “do not wish to say,” or ”not applicable,” to reduce frustration for not being able to produce an exact answer.

• Use FAQ formats to organize complex information to enhance clarity as to why the information might be useful to the user and how it connects to their life.

• Define terms that might have different meanings depending on social context, or that might be jargon related to a specialized field (e.g., “drug interactions” and “health care providers”), to accommodate difficulties with language pragmatics.

• Attend to autistic culture and community preferences, including the language used to describe autism, and how community-based symbols and history might influence content and perception of site credibility.

Discussion

We present a systematically derived, theoretically grounded, and empirically tested set of guidelines for web accessibility for end users on the autism spectrum. These guidelines were created through AASPIRE's collective expertise and our iterative engagement with end users on the autism spectrum. The guidelines add to the growing literature of disability-specific accessibility recommendations that go beyond what the WCAG supports, and cover all three dimensions of accessibility: physical, intellectual, and social.

A small number of unofficial web accessibility guidelines or recommendations for people on the autistic spectrum do exist. However, they do not have our strong combination of autistic end-user engagement in all phases, systematic guidelines generation, empirical testing, explicit grounding in accessibility theory, and holistic approach. For example, both the National Autistic Society and the U.K. Home Office have guidelines available outside the peer-reviewed literature.^51,52 An article from the proceedings of the 2016 International Conference on Advances in Computer–Human Interactions reviewed and compiled recommendations for autism-specific guidelines scattered throughout the peer-reviewed literature.⁵³ The compiled list, arranged in categories, includes a number of items identified in our study (e.g., customization and simplicity), further confirming our findings. However, it focuses on physical accessibility and does not catch, for example, the importance of cultural considerations or the cognitive impact of navigational scrolling. Other guidelines also focus on a particular area of accessibility such as text and readability⁵⁴ rather than the web as a whole, or do not present results of empirical testing.

This study has some limitations. First, the guidelines were generated from a study on a primary informational website with a simple form-based application. Additional items may be needed for websites with more complex or specialized functionality. Second, the study was done in the United States and, although the technology of the Internet is international, cultural and technological considerations in localization (e.g., assumptions about available Internet speed) outside the United States were not considered. Third, the empirical findings from the final evaluation are from a convenience sample of a study with a primary purpose to evaluate the potential impact of the toolkit on health care outcomes, rather than a primary focus on usability. Fourth, due to the requirements of the study design, participants needed to have been diagnosed with an ASD, leaving out people with self-diagnosis who may have similar accessibility needs. Lastly, both our CBPR team and our participant samples were primarily non-Hispanic white, leaving out key racial and ethnic dimensions of diversity. Future study should address some of these gaps.

Owing to an affinity for the web among many autistic people, there may be significant impact from increasing accessibility for the autistic population by using the AASPIRE Web Accessibility Guidelines. We strongly support the implementation of accessible websites for all people; implementing these accessibility recommendations could improve access to information and technology for the 1% of the adult population on the autism spectrum⁵⁵—and the 1 in 59 of young people on the autism spectrum who will become adults⁵⁶—as well as to others who may not be autistic but who have similar or overlapping accessibility needs (e.g., attention deficit disorder/attention-deficit/hyperactivity disorder, psychosis, or traumatic brain injury). We also strongly recommend engaging the assistance of autistic web users directly as subject-matter experts in website development. Accessibility matters and has real impact on reducing the significant inequities experienced by adults with disabilities.

Authors' Contributions

All authors contributed to all stages of the research described in this article as full AASPIRE partners. D.M.K., S.K.K., and E.A. contributed as autistic community partners, with D.M.R. and S.K.K. also contributing academic expertise in accessibility and autism and the internet, and E.A. contributing written content for the website. Furthermore, D.M.R. was the lead engineer and technical writer for the website. C.N. was the principal investigator for the study, and served as a senior mentor throughout. She is both a family member to an autistic person and a health care provider. K.E.M. and M.W. (also a health care provider) served as academic partners, providing expertise in disability accessibility and web-based bioinformatics. On this article, D.M.R. took the lead role in organizing the data, creating the first full draft, and revising subsequent drafts. All authors reviewed the initial draft and revisions, contributed additional ideas and content, and approved the final version before submission. Earlier versions of this study were included as part of D.M.R.'s PhD dissertation. This article has been submitted solely to this Journal and is not published elsewhere.

Author Disclosure Statement

No competing financial interests exist.