In baking, to achieve good results, key ingredients must be mixed using the right proportions and in the correct sequence, then left to cook at the ideal temperature for a certain amount of time. With patience and good techniques at every step of the process, one can turn those ingredients into a great cake or pastry. The same holds true when it comes to implementing digital accessibility into an organization’s product and content development processes.

The term specialist might come to mind in relation to digital accessibility, just like a pastry chef in the field of baking. By specialist, I mean someone who has the expertise and knowledge on implementing accessibility requirements and making sure that accessibility is considered at every stage of design and development. Having a specialist on a team is extremely beneficial: they can be a source of knowledge and can easily spot when a feature or a piece of content is inaccessible. On top of that, their experience with in-depth testing ensures no barriers have been introduced once everything is ready for launch.

However, organizations must not fall into the trap of over-relying on specialists and “dumping” all their accessibility needs onto a few people. Accessibility is often not considered at every stage of design and development, and more often than not, it is “bolted on” after launch, which is costly and time-consuming.¹ Some organizations might not even have access to specialists, in which case accessibility could be deprioritized altogether. 

To properly “bake” accessibility into a process, it must be a collaborative effort. Accessibility needs to be considered and implemented with the right techniques at every stage of the process until it becomes a natural part of the process. To illustrate this, I will use some examples from my work as a specialist at SAGE Publishing (SAGE), highlighting approaches used to embed digital accessibility into our workflows. 

My Role as a User Experience Accessibility Specialist

SAGE has been seriously considering platform and content accessibility for about 7 years. We have come a long way since then. There have been efforts made to embed accessibility in multiple departments, such as design, development, production, and testing. They cover both accessibility on the platform side (for our various platforms) as well as the content side. 

The key challenge is making sure accessibility remains a priority, especially when people leave the organization, and teams change. This requires constant training and knowledge-sharing across departments that have fewer accessibility experts. For example, when hiring for designers, we have recently added accessibility awareness and knowledge as part of the job description to make sure that it remains an integral part of their work.

I have learned a lot in my 4 years at SAGE, and my involvement in digital accessibility has deepened and grown to include multiple responsibilities. Resourcing for accessibility is not always easy, so advocating for accessibility alongside my specialist colleagues is one of my main priorities. However, we wear multiple hats and accessibility is not our only responsibility, so this advocacy work across the business is key in ensuring that we can evenly spread the work across teams. Initially, this was focused on the product management and development teams, but recently, my role has expanded to include advocacy, training, and support for various departments based in both the UK and the U.S.

We also need to keep accessibility awareness high across departments so that it does not get deprioritized. To do so, we constantly create accessibility documentation and repositories that can then be applied to our suite of products by various departments. By making sure that multiple teams have a strong accessibility foundation, we can then fill in the gaps where more technical expertise is needed. 

Short-Term: Start Small

The smallest steps in embedding accessibility can ensure a strong foundation when tackling more longer-term approaches and strategies. As mentioned before, one of the main principles to follow is not to leave accessibility work until the end, but to consider it at every step, from ideation, to design, development, and release or publication. This principle can also serve as a useful personal mantra for anyone: “Have I considered accessibility implications in my work?” 

It is much more expensive and time-consuming to go back and fix accessibility issues after a product or a piece of content has launched.² Furthermore, consciously and continuously considering accessibility at every step allows a team to be more granular in identifying opportunities for improving the accessibility of a feature. 

Everyone involved in a project should be considering accessibility, not just the experts. Teams can be tempted to relegate specific accessibility requirements to 1 or 2 people, but having more people involved in considering accessibility is much more effective, and the key is starting small. For example, elements of accessibility such as color contrast³ and alternative text,^4,5 which can be easily reviewed and tested, are a good place to start. 

A small step we have taken early on to make sure accessibility is always being considered is adding accessibility sections to technical requirements that need to be completed before being sent out to developers. Over time, these requirements have become more detailed and are not just being left to the specialists to fill out. I usually review requirements that have been written and change or add to them where appropriate. 

Short-Term: Education

Training and education are a key part of raising and maintaining accessibility awareness that can be implemented early on in developing an accessibility process. There are plenty of free educational websites and tools anyone can access to learn about the tools for testing and evaluating the accessibility state of a site or application, as well as best practices, guidelines, and insights into what other organizations are doing. 

Many of these resources are meant for anyone, not just experts, and can be a continuous source of knowledge as well as inspiration. Here are fi5ve of my favorites:

1. Web Accessibility in Mind⁶ (WebAIM): a fantastic resource from Utah State University’s Institute for Disability Research, Policy and Practice. They provide accessibility guidance, tips, commentaries, and training in a practical and easy to understand format. They also have a strong social presence and community and have developed the free to use Web Accessibility Evaluation (WAVE) Tool. 
2. A11Y Project⁷: the A11Y Project “is a community-driven effort to make digital accessibility easier” and takes a very hands-on approach to getting started with digital accessibility. 
3. 24 Accessibility⁸: an “advent calendar” style blog with tips and stories about working with digital accessibility. 
4. AccessibiltyOz⁹: an Australian consultancy founded by Gian Wild with offices in both Australia and the US, they also provide excellent training resources and webinars. 
5. UX Movement¹⁰: a user experience site that publishes very specific and practical articles. Their accessibility articles debunk many myths surrounding accessibility. 

We also encourage colleagues to attend free webinars and training sessions. These tend to be practical and cover concepts that are immediately applicable, and even more importantly, give the audience a chance to ask questions. Deque,¹¹ TPGi,¹² and Level Access¹³ have some excellent free webinars. 

At SAGE, we’ve run accessibility training sessions for different groups. The most effective of these have been the “Accessibility Bootcamps,” where we start by building empathy and making the case for accessibility, then we move on to more technical guidelines. These inclusive training sessions offer a great starting point for colleagues who have little experience with digital accessibility. 

Medium-Term: Effective Communication

Having raised awareness for the need to design and create accessible products, the ongoing challenge in the medium-term will be making a smart and effective case for accessibility. Although it is necessary to highlight the legal implications of having inaccessible content, framing accessibility work as a positive ethical and business benefit rather than a burden is much more effective for a sustainable process.¹⁴ 

…framing accessibility work as a positive ethical and business benefit rather than a burden is much more effective for a sustainable process.

On top of that, when designing with accessibility in mind, the experience will improve for all users.^15,16 This has helped us multiple times when making the case for an accessibility feature to be added to a page. For example, if you are making the case for video captions, do not just say, “We need captions on our videos or else we will get sued.” Legal action might be a strong motivator to introduce captions, but it usually leads to quick fixes that will not be sustainable in the long run. Instead, frame the need for captions as a strong benefit for everybody, “Captions are now widely used across video streaming services, and people use them for many different reasons. Adding them would make our videos more accessible and usable by everyone.” This way, captions become an expected and usable feature for videos rather than a one-time fix. 

As your organization starts to incorporate more accessibility features, the requirements needed for these features will become longer and more granular. A side effect is that these requirements can become confusing. Describing expected behavior for keyboard and assistive technology can lead to lengthy documents and the need for clarification. An effective way of solving this issue is using visual annotations on wireframes or screens to visually indicate elements such as headings, alternative text, landmarks, and reading order.  

This makes it much easier to show where elements need to go and how they should be marked up, as well as demonstrating how an assistive technology and/or keyboard user might navigate the page. Deque have an excellent guide¹⁷ with getting started with these annotations, which can then be tweaked to suit specific needs. 

Long-Term: Reuse, Share, and Improve

There is no need to reinvent the wheel every time a new project, feature, or collection is launched. Reuse what has already been created to set a standard process for accessibility and to create a knowledge base that everyone in your organization can tap into.¹⁸

We have added accessibility and inclusive design to our Design System (Figure).

In short, a design system is a collection of reusable components, standards, and guidelines for building products. This not only ensures that the whole organization has access to an agreed-upon set of accessibility standards for different design elements, but also includes other factors that can influence the accessibility of a page, such as typography and language. The Design System from telecommunications company Orange¹⁹ is a fantastic resource for getting started. 

When a new feature or product has launched, it is also worth running accessibility-focused retrospectives. These are sessions during which a team evaluates a recent project and considers what went well and what could be improved. Was accessibility considered at every stage, and if not then why? Running these retrospectives with a focus on accessibility is a useful tool for everyone involved to understand the small steps needed to constantly improve the accessibility workflow. 

Was accessibility considered at every stage, and if not then why?

Long-Term: Avoid Silos

One of the most difficult long-term challenges will be communicating these accessibility developments to the wider organization in order to share knowledge and demonstrate the impact of the work surrounding accessibility. The latter is always problematic, as sometimes the impact of an accessibility development is not immediately demonstrable compared to other features, which often rely on usage data to show their impact.²⁰ 

A practical way around this is to set meetings focusing specifically on accessibility. At SAGE, I attend a monthly Accessibility Working Group (AWG) meeting. Representatives from different departments who are involved in accessibility work meet to share updates, coordinate new projects, and discuss developments in the industry. We have also run quarterly Stakeholder Meetings of the AWG, where we have updated stakeholders on different developments across the business, demoed new accessibility features, and opened the floor to questions. 

Awareness of and attendance at these meetings are something we are trying to improve. We want to make sure the attendees are engaged and cascading the information presented to their respective teams, and to do so we often tweak the format and seek feedback on how to make these meetings more informative. Even at this stage of accessibility maturity, it is essential to adapt and keep accessibility high in the organization’s priorities. 

Accessibility Is a Continuous Process

All these process improvements for baking-in accessibility are things my colleagues and I are constantly working on to improve and adjust to fit user needs, the business requirements, and our resources. In the context of an organization, this is similar to security and privacy where ongoing investments and maintenance are needed in order to maintain a strong level of safety. 

Ultimately, the challenge is making sure that people are aware of the importance of designing with accessibility in mind, and the major driver for this is collaboration. As soon as teams become siloed or accessibility becomes relegated to 1 or 2 people, accessibility goes back to being a checkbox feature rather than a foundational principle. Through continuous training, improvement, communication, and standardization, accessibility can remain at the forefront of priorities and become “baked-in” into an organization’s workflow. 

References and Links

1. Steadman M. This is the way: a phased approach to accessibility in the development lifecycle. Deque. 2021. https://www.deque.com/blog/this-is-the-way-a-phased-approach-to-accessibility-in-the-development-lifecycle/. 
2. Groves K. Getting instant return from your accessibility testing. Tenon.io. 2016. https://blog.tenon.io/getting-instant-return-from-your-accessibility-testing/. 
3. WebAIM. Contrast and color accessibility evaluating contrast and color use. 2021.  https://webaim.org/articles/contrast/evaluating.
4. Smith J. Back to the basics: alternative text. WebAIM. 2006. https://webaim.org/blog/alternativetext/.
5. WebAIM. Alternative text. 2021. https://webaim.org/techniques/alttext/.
6. https://webaim.org/ 
7. https://www.a11yproject.com/ 
8. https://www.24a11y.com/ 
9. https://www.accessibilityoz.com/ 
10. https://uxmovement.com/
11. https://www.deque.com/resources/type/webinars/page/2/ 
12. https://www.tpgi.com/events/ 
13. https://www.levelaccess.com/resources/ 
14. Rush S. The business case for digital accessibility. W3C Web Accessibility Initiative. 2019. https://www.w3.org/WAI/business-case/.
15. Youngblood S. 2012. Communicating web accessibility to the novice developer. J Bus Tech Commun. 2012;27:209–232. https://journals.sagepub.com/doi/full/10.1177/1050651912458924. 
16. Lawton Henry S, Abou-Zara S, White K. Accessibility, usability, and inclusion. W3C Web Accessibility Initiative. 2016. https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/. 
17. Pearlman A. Top 5 most common accessibility annotations. Deque. 2020. https://www.deque.com/blog/top-5-most-common-accessibility-annotations/. 
18. Beaumont S. 2021. Shifting left: how introducing accessibility earlier helps the BBC’s design system. Medium. 2021. https://medium.com/bbc-design-engineering/shifting-left-how-introducing-accessibility-earlier-helps-the-bbcs-design-system-716ec5cfbcd8. 
19. https://system.design.orange.com/0c1af118d/p/0127c5-design-system 
20. Zaraysky S. 2019. Making the case for accessibility. Medium. 2019. https://medium.com/google-design/making-the-case-for-accessibility-350da9e30c84.       

Lorenzo Milani (ORCID: 0000-0003-4803-4229) is Associate User Experience Specialist at SAGE Publishing.

Opinions expressed are those of the authors and do not necessarily reflect the opinions or policies of the Council of Science Editors or the Editorial Board of Science Editor.