How can developers better prioritize accessibility throughout their project cycles?

Dave Kim

Vice president of global diversity, equity, and inclusion at Zendesk

Accessibility is not just a tech or business issue; it’s a human right. Technology should be inclusive of everyone, and that means every new product or service, and each successive update, must be accessible to everyone. In the development process, that means ideating, building and deploying with accessibility top of mind.

When first brainstorming on how to build features, it’s important to design and code with empathy in mind and identify obstacles that could prevent people from using them. Exclusion can happen when we design through our own biases. When we intentionally design inclusively, it’s an opportunity for innovation. For example, if your product is only usable with a mouse, that rules out some users with visual impairments or hand tremors. At Zendesk, our developers identified that gap and came up with a solution — programming commands with universal keyboard shortcuts that eliminate the need for a mouse altogether.

While putting accessibility at the core of your innovation and development initiatives is the right thing to do, it might not be realistic or achievable to assume that everyone on the team will bring that mindset to their work. Start with listening and hiring accessibility champions who take the lead in ensuring it is top of mind across the entire product development cycle and are responsible for working with employees to understand the importance of accessibility in their work as well.

Developing for accessibility isn’t a one-and-done part of the project cycle, but rather a constant goal to strive for in order to guarantee users’ rights and create a good experience.

Tweet this.

Dana Lawson

Senior vice president of engineering at Netlify

First and foremost, leadership has to ensure it is curating a human-centric, customer-focused culture. Accessibility shouldn’t be an afterthought or a nice-to-have if you want to ensure consistency. People all over the world should have the same opportunity as everyone else to use your product, and most developers already have a desire for the world to try what they have built. However, depending on the maturity of your development process, those developers might not have the opportunity to incorporate these needs. To ensure that accessibility “just happens,” you have to not only ensure the team understands the importance, but you also have to make it an automated part of your software development process. To do so, you have to put the right constraints and tools in place to make it frictionless for developers to incorporate and deliver accessible features. For example, when developers use the Jamstack architecture, which leverages modern web frameworks that enable the execution of assistive technology, APIs, and even implement feature flags to serve customized content at the edge, accessibility can be built in from the beginning.

Tweet this.

Andrew Kirkpatrick

Head of accessibility at Adobe

First, developers and engineering teams need to be aware of accessibility, the needs for these features and the benefits they can provide. Once accessibility and inclusion awareness has been prioritized, teams can understand the benefits and build accessibility into the earliest stages of the development cycle. A few ways to accomplish this are to provide developers with design systems, frameworks and implement early usability testing to help scale processes to help enhance accessibility in products.

For example, teams can institute “accessibility bluelines” into design systems to help developers and engineers implement accessibility more easily. Accessibility bluelines are design specifications that define and describe an application’s accessibility support (focus order, keyboard shortcuts, content structure and annotations) so it can be engineered for assistive technology (screen readers, keyboards, etc.). For developers and designers thinking about creating accessible experiences, this is a simple addition to help shed light on improvements that can be made that benefit all users.

Companies must prioritize accessibility — understanding the key drivers including revenue impact, compliance requirements and user impact is necessary for the business to determine that accessibility is a priority. Once the business decision is made, maintaining customer relationships and staying up to date with the latest standards and requirements in this space is critical for success.

Tweet this.

Peter Korn

Director of accessibility, devices at Amazon

Many often believe delivering accessible solutions is difficult, when in actuality it’s not. Developers can better prioritize accessibility via a few simple yet critical avenues.

First, collaborating with people with disabilities and accessibility expertise as early as possible is key — whether working on a specific project or creating a product team. The team will better understand the people and the experience they’re building for, and the better the offering will be.

Another important prioritization mechanism is examining whether there is an opportunity to deliver accessibility in ways that brings broader benefits for all users. For example, closed captions on videos are important accessibility features for people who are deaf or hard of hearing, but they’re also great for non-native speakers of the video or people who are watching in a loud environment, for example. While around 5% of the world population has disabling hearing loss, 80% of the people who use captions don’t have a hearing impairment, and 85% of videos on Facebook are watched with sound off.

Lastly, it’s critical to conduct a thoughtful accessibility evaluation at the start of the project — this will often identify small and inexpensive adjustments that can have an outsized impact in improving accessibility relative to their cost. If that evaluation comes in the later stages of a project, it will be too late. People with disabilities cannot be an afterthought, and their experiences cannot be treated as such either.

Tweet this.

Mohamed Elshenawy

Executive vice president of engineering at Cruise

Accessibility should be a core product feature for autonomous vehicle makers … not an afterthought. AVs are a complex, multidisciplinary achievement, fusing software, hardware, robotics and AI technologies. The complex cross-functional coordination and the extended development timelines that come with manufacturing automobiles at scale requires AV teams to fold accessibility into their research, engineering, product and design processes as early as they can. The earlier in the process that you incorporate accessibility, the more intuitive your end product will be for the diverse communities you serve.

Research early, research often: As your engineering and product teams begin to scope a new product or form factor, treat user research and customer/community input as gold. When beginning work on Cruise’s purpose-built vehicle, the Origin, we knew that a vehicle without a front or back seat, steering wheel or pedals had the potential to help a variety of communities including wheelchair users, people who are blind or have low vision, seniors, those recovering from injuries and many more. As we’ve developed the Origin, we partnered with disability-lead organizations and incorporated people with disabilities in rigorous user testing and design.

Designate resources to set accessibility goals and track progress: It’s critical to give cross-functional contributors structure and visibility into what they’re working on and how you define success. At Cruise, we have designated a team focused on delivering our wheelchair accessibility vehicle (or WAV) that tracks progress ahead of manufacturing deadlines.

Forethought and cross-functional coordination on accessibility from AV makers will move the transportation ecosystem toward a more equitable, accessible, affordable and sustainable future.

Tweet this.

Ted Drake

Global accessibility leader at Intuit

Everyone has the ability, and responsibility, to include accessibility within their project cycles. We leverage a simple technique for engineers, designers and project managers to improve their customers’ experience. During our regular accessibility and inclusive design workshops, we challenge our developers to use the product without a mouse for 15 minutes a week. This is aligned with our customer-centric approach at Intuit, where we do our best to put ourselves in our customers' shoes. Many make this 15 minutes a part of their Monday morning activities and then bring what they experienced to our team’s daily standup.

To be accessible, people need to know what they are working with, access interactive elements and interact with them. We focus on keyboard accessibility, which is important for everyone who does not use a mouse. This includes those with carpal tunnel syndrome or blindness, use speech recognition, and power users who spend extended time working in your application. Regular keyboard usage by the entire team will drive design specifications that include keyboard interactions, engineers will code for those specifications and your products will work for a much broader spectrum of customers.

Tweet this.

Emmet Connolly

Vice president of product design at Intercom

When you’re designing and building products, it can be hard to anticipate the full range of needs and experiences of everyone who will use it. There’s a great deal of empathy and imagination required, because especially as your product adoption scales, you’re not building for yourself in the vast majority of cases. You’re building for people whose lived experiences you have very little understanding of.

While there are well-defined standards for traditional accessibility, especially for visual UX, we’ve found the best way to ensure you design truly inclusive experiences is by having meaningful conversations with your customers and iterating based on feedback. Strive for human connections as an ongoing part of the development process; customer feedback has to become more than data in a report, it needs to be personal. For example, sound is an often overlooked element of the user experience. A customer on the autism spectrum who also struggled with ADHD brought to our attention that the notification sounds in our product triggered sensory overload. She then worked with us to road-test new sounds, which resulted in multiple new options that serve the needs of our diverse customer base better.

Tweet this.

Gabe Monroy

Chief product officer at DigitalOcean

Thinking about accessibility (or a11y) must be a part of every developer's checklist when starting projects — not an afterthought. That's the best way to form a routine. An afterthought all too quickly becomes "I'll get to it later and then not at all." At DigitalOcean, we preach the POUR principle, or "perceivable," "operable," "understandable" and "robust." Start small by including alt text for images, semantic HTML and language changes. The goal is to rewire your thought process to account for every type of person who might visit your webpage.

Once you have a handle on the small stuff, nailing accessibility more broadly benefits from a design-first approach to product development, where product flows are designed, reviewed and tested with target personas prior to any code being written. This allows user journeys to be mapped against accessibility checklists, and also helps surface cases where accessibility features may be required by law — a trend that is increasing over time. While accessibility is a prime beneficiary of front-loading design and associated customer feedback, this model of product development also leads to better, more customer-centric products overall.

Tweet this.

Debbie Ferguson

Head of accountant segment at Gusto

Building for a set of personas that have a diverse set of experiences and abilities can help to ensure that developers are designing, building and testing for a wide set of people, leading to products that are designed for everyone.

Being thoughtful about these personas allows developers to avoid the trap of creating a product that may only be relevant for a small group of users that are just like themselves. Crafting a broad range of personas helps developers envision and relate to different types of users as early as possible in the design process.

If developers wait until the MVP stage to consider a diverse set of users, it will be too late to create products that are accessible to broader groups of people.

Tweet this.

Carlos Sousa

Director of software engineering at OutSystems

The internet has dramatically democratized access to information; however, there’s still a big chunk of the internet that is unavailable to people with visual, mobility or cognitive impairments. This makes using technology more of a burden than it should be, especially for older people or people with disabilities. It’s everyone’s responsibility to design and craft an internet that is available to all, regardless of our differences. That includes software engineering departments that can ensure that accessibility is an integral part of the design and not an afterthought.

To do that, teams need to treat accessibility just like any other application or page requirements, such as performance, availability or security. One way to do this? During design time, require that engineers build out plans, capacity allocations, staffing and solution designs with a full range of users in mind. Creating requirements for user accessibility at this stage helps ensure that quality software is accessible.

It’s also important to make sure that the process of continuous improvement includes accessibility criteria as regulations and user needs evolve. A simple way to implement this is to ensure sprint planning sessions include in-app feedback about accessibility as a high priority item.

In the end, it’s important to ensure that software engineers design and build with accessibility in mind, giving it the empathy and consideration it deserves, to ensure that we create a more inclusive and fair internet.

Tweet this.

Sommer Panage

Senior manager of software engineering, accessibility at Slack

At Slack, we believe it is important to not just understand our users but work with them directly to design and build the features and experiences they need. This work happens at every stage of the product development cycle. When we begin a project, we strive to understand how other apps in our category are and are not accessible to better understand our customers’ expectations or frustrations. This allows us to think about accessibility during the design and early architecture phases of development. As a project continues, prioritizing accessibility means reflection, experimentation and iteration. There’s often no one right answer, no one right way. We try things, we share them with some of our users, gather feedback and iterate until we improve. By doing this, we not only build a better product, but we also keep accessibility on our minds the whole time. Once a project reaches the public, the work continues. We keep our minds open to feedback, to things we may have missed, to experiences we may not have considered. If changes are needed, we talk about them, scope them and fold them back into our project cycle. So much of the process is about listening, learning and understanding that no feature is ever “done.”

Tweet this.