Features January/February 2023

Top Six Mistakes to Avoid When Designing Accessible Websites

By Sushil K. Oswal | STC Member

Improve web accessibility for your sites by avoiding some of the most common pitfalls.

Web accessibility instruction is still not common in technical communication courses. Technical communication and web design professionals interested in accessibility do not always have financial resources, time, or energy to take accessible design courses to pursue this interest. This quick tutorial will help you get started. If you pay attention to some of the most common web accessibility mistakes made by designers and discussed below, you are already on the path to designing accessible websites.

1. Let us design and develop our website and then we’ll check it for accessibility when we conduct usability testing.

Building accessibility on top of a website structure designed for nondisabled users is like garnishing a fruitcake with pickles. Disabled users navigate websites both like and unlike nondisabled users, but the interfaces on their end can be as varied as a regular keyboard, for someone requiring non-mouse access due to a hand-motor disability, or someone using a screen reader for navigating pages non-visually. Screen readers are textual browsers, and their users cannot always point to an object with a mouse due to a visual disability.

So, accounting for the presence of a variety of user interfaces by designers is central to building accessibility from the bottom up. This realization about users accessing our websites through these varied interfaces has to happen as early as the beginning of design activity. Besides depicting our users’ general aptitude for technology, backgrounds, and interests, do our personas also represent the difference in human bodies and the way they function? Do the journeys we imagine on behalf of our users reflect how they will carry their diverse bodies?

2. Disabled users don’t know anything about web design, so they have no business meddling in my design until I have a prototype to test.

You might be right that disabled users, like all other users, don’t know a lot about designing and developing web pages, but they are flesh-and-blood beings who interact with websites, and they know a lot more than we do about how their bodies apply themselves to use our designs in these web interactions. They also know a lot more about how their adaptive technology will interact with your website even if you are familiar with adaptive technologies. We must realize that they live with their adaptive user interfaces 24/7.

Including a disabled person with some good user knowledge of adaptive technology on your team before your planning gets going will help you conceptualize the whole project as an accessible enterprise. The coolest of design ideas imagined by a human body inexperienced with a disability can be disabling. We might all recall the hype for those splash pages with little keyboard access and no textual content. Instead of being a gala welcome to the user, they were, and still are, concrete barriers for most disabled users entering your website with a nonvisual adaptive interface, such as a screen reader or a braille array. So are most of the uses of Accessible Rich Internet Applications (ARIA) roles, because developers fail to test their pages with disabled testers who have a better understanding of adaptive interfaces because they use them regularly.

So, let a disabled team member, or at least a consultant, be the tester of your web design ideas from the get-go before the ideas solidify into unexpected and unwarranted accessibility barriers. As you choose a disabled consultant on your team, make sure that they have some good web browsing history and they also use adaptive technologies that affect web design most—screen readers, braille displays, and closed captions.

3. The internet has no boundaries; therefore, why should I not design as vast a website as I like?

Yes, all businesses, nonprofits, and other customers have their website needs. They might also have a desire to put out all the content they like online, since they own the domain, and they are paying you to design it. At the same time, as an expert, it is your responsibility to convince them that sometimes less is more, as long as this less is well designed. And this advice stands true for the structure of the web pages, their design features, and the content itself. Even a well-designed and -executed website requires some effort on behalf of your users—disabled or nondisabled. Persuading the customer that the users have limited attention spans, limited time to spend on the customer’s site, and at times, limited energy to expend to achieve their intended goals during their visit, is an aspect of our job we often neglect. Educating the customer that the internet is not necessarily a medium for going overboard with content can help us move toward reducing the information overload on users. For users with disabilities, feature overload on websites is also a problem, which only web designers and developers, as well as content developers, strategists, and managers, can solve.

So simple designs with elegant features within the limits of our users’ aptitude and capabilities can serve them as well or better than most of the elaborate designs that shut out a large segment of our user population, ranging from 15 to 20 percent, according to U.S. Census and World Health Organization estimates. I believe that no one among us would like to perpetuate such an exclusion consciously.

4. We are dedicated to accessibility because we use Web Content Accessibility Guidelines (WCAG) in our web design.

While we cannot function without web standards—if we want to design and develop accessible pages for diverse bodies employing a variety of user interfaces, browsers, and adaptive devices—following the guidelines alone does not necessarily result in accessible websites. Accessibility mindset, which I characterize as “accessible design orientation,” requires an embodied understanding and acceptance of physical and neurological differences among human beings. Such an orientation can help us as designers and developers move from the thinking that “I also have to accommodate this different user” to “My users are all different, and my web designs need to walk the tight rope where I could cater to the diverse needs of these users.” Adopting this orientation can, at times, mean that we might not always have the design space to pamper our nondisabled users with the extravaganza they might find entertaining, but we might remind ourselves that a meaningful web design is that which assists our users to achieve their practical purposes.

So, if we could help all our users with the tasks they want to accomplish on our website with a simple design, they will not go away disappointed, and our job is well done. Of course, we should never forget that “guidelines are only half the story.” The other half is our orientation toward becoming disability-centered designers and developers.

5. I’m implementing every WCAG standard perfectly and I have tested my prototype with adaptive technology to the best of my capability; therefore, I don’t have to conduct additional testing with disabled users.

Elimination of frustrating troubleshooting to solve the accessibility problems reported by users once the site is up and running, but just not running that well for some users, is not only time-consuming but also costly. Imagine any of those occasions when you had to tell a client that their website would require significant revamping to address their customers’ accessibility complaints, because the designer/developer who originally built the website did not pay attention to accessibility.

Accepting the fact that designers and developers are not always the best testers who can predict the challenges the users might face with our web designs requires humility, but the accessible design orientation bodes well with this mindset. Designer humility shows respect for the users of our products, and it can only grow mutual respect and appreciation for our products. Cultivating this mutual respect among users, designers, and developers is again one of our responsibilities, if we want to put out web products that our intended audiences can use without jumping hoops, can appreciate, and can also enjoy thankfully. How many times do we find ourselves smiling when we can accomplish our task with a design that delivers its promise, and the visitor has a great user experience?

Preventing large costs involved in retrofitting accessibility to an existing website design conceptualized for an average human body is possible if we conceptualize our web designs with all users in mind but also invite them to test our products before making these products public.

Investing in manual testing with disabled users is worth the additional cost. To convince our customer of this manual testing’s value is our job, and these costs should be calculated like other usability and user experience testing costs in the budgets for our project proposals to the client.

6. Our team of designers and developers is well-versed in accessibility, and we can design a really accessible website. We also know that we can build all the structure necessary for an inclusive user experience in our web pages for all our visitors. Do we now also need content developers and strategists who have been trained in accessible design?

Yes, designing an accessible foundation and technical structure for our websites is undeniably central to attaining the aim of accessibility and inclusivity. However, access is just as central to designing simple, functional, and inclusive content. What value is your textual content if a large percentage of your users have to gloss over half the words because the content does not speak to their vocabulary or its syntax addles their mind? Up to 11 percent of our users have invisible disabilities, such as dyslexia or attention-deficit/hyperactivity disorder (ADHD)—also known as attention deficit disorder (ADD), and more than any other users, these users desire texts that are easy to read and easy to process. Reading a wall of lengthy text with a linear device, such as a screen reader, is taxing on ears and mind. Most likely, the users of such adaptive technology will try to escape from such a web environment as quickly as they can. No doubt, nimble and audience-focused content is less taxing for all other users when they are reading in distracting environments.

Small chunks of text requiring the reader to click links to go to the next page are equally problematic. They can be a literal pain point for users with hand-motor disabilities. Moreover, people using text-to-speech (TTS) readers—sighted or blind—find such short snippets of text frustrating because they cannot benefit from the automatic reading features of their TTS software while they multitask. Often these short pages are full of bare space with color, panorama, or other visual artifacts that do not cater to the visitor’s purpose. Inflating such short chunks of text to the level of web design is not convincing because visitors can easily see that the choice is not the outcome of a complex or strategic design decision.

Likewise, we can’t expect our users to complete complicated forms on our pages if they are dysgraphic—a disability that poses challenges in writing complicated language. Images and videos are not exempt from accessibility issues, and content creators need to remember that many of their users might have visual disorders that keep them from processing complicated images.

So, while forming our web design teams, we must pay attention to selecting content creators who are inclusive of all users in their orientation, have enough background in Plain Language theory and practice, and can develop images and videos with these users’ needs in mind.

Further Resources
  1. Cheung, I. W. 2017. “Plain Language to Minimize Cognitive Load: A Social Justice Perspective.” IEEE Transactions on Professional Communication 60, no. 4: 448–457.
  2. Huntsman, S. (2022, July). “An Image for All: The Rhetoric for Writing Alt-Text. 2022 IEEE International Professional Communication Conference (ProComm): 49–52.
  3. Muehlbradt, A., and S. K. Kane. 2022. “What’s in an ALT Tag? Exploring Caption Content Priorities through Collaborative Captioning.” ACM Transactions on Accessible Computing (TACCESS) 15, no. 1: 1–32.
  4. Plain Language Action and Information Network. 2011. “Federal Plain Language Guidelines.” https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf
  5. Slatin, J. M. 2001. “The Art of ALT: Toward a More Accessible Web.” Computers and Composition 18, no. 1: 73–81.
  6. WebAIM. 2020 “Accessible images.” Published September 20, 2020. https://webaim.org/techniques
  7. WebAIM. 2021. “Alternative text.” Published October 19, 2021. https://webaim.org/techniques/alttext/

SUSHIL K. OSWAL, PhD, is professor of HCI and human-centered design in the School of Interdisciplinary Arts and Sciences and CREATE Faculty at the Center for Research and Education on Accessible Technology and Experiences at the University of Washington. He is currently completing a health information design and UX study relating to COVID-19. He can be reached at oswal@u.washington.edu.