The tech industry works hard to break away from monolithic architecture. Yet, we’ve neglected to move away from the idea of the monolithic developer experience.
Whether it’s internal or external, developer experience—sometimes called DX, DevEx, developer enablement, or developer productivity—is the effort to improve the overall user experience a developer has with your product, service, or organisation. DevEx is all about removing friction for developers so they delight in using your product.
For far too long, teams have created a singular brand persona to equal The Developer. Imagine—an able-bodied, neurotypical, cis, white dude, probably in a t-shirt, who has great WiFi and an elaborate tech setup, and loves to solve problems and code. Trying to sell and build only for this profile is downright ablest and exclusionary. If we are building the future, more people have to be involved in creating that future—that’s just good business. Bonus—designing inclusively for developers typically leads to better products for everyone.
In “User Interface Design for programmers” way back in 2001, Joel Spolsky drew the parallel with OXO, a company that designs kitchen tools for people with arthritis. “One in seven people suffer some form of arthritis—that's almost 40 million people in the United States alone. Designing a line of products for just that market niche was likely to succeed. Indeed, [founder Sam] Farber's company, OXO International, became a stunning success. But their market is not just people with arthritis: everybody likes OXO products. They are simply more pleasant to use”.
But, while more and more end-user products are being tested for accessibility, can we say the same for developer tooling? The answer is no, according to independent accessibility specialist Alex Tait:
“Tech is an ablest industry on a very substantial scale”, she told WTF is Cloud Native. “Not only are we not producing accessible content, we’re not producing accessible tools. We’re not even producing accessible content creation tools”, she continued, pointing to Wix and Squarespace, which she says requires a ton of customization to make anything accessible.
With about a billion disabled people worldwide and a huge tech talent gap, these are not edge cases. Ignoring accessibility for developers comes with several risks.
Start with Your Quick A11y Wins
As the numeronym for accessibility in the heading above illustrates, Reema Bhagat, Spotify’s senior product designer, argues that accessibility has to be integrated in any specification or else it’ll be overlooked, “including keyboarding and screen reader details within a design spec has helped solidify that accessibility is part of the experience, rather than something we’ll add retroactively”. This, of course, is the much cheaper way of doing it, rather than having to go back and fix it later.
“Testing out features with product and engineering before they’re released helps ensure that quality and accessibility are shared responsibilities on the team”, Bhagat continued.
Following best practices for front-end design is a great launchpad for any developer-focused design, which in DX is user-centred design:
- Design suites such as Apple, Android and Adobe have built-in accessibility testing so you can flag issues and build correctly and inclusively from the start.
- Start with the WebAIM recommendations.
- Leverage other site-wide and service-wide tools e to test for accessibility.
Just don’t half-ass this. Deque Systems focuses on accessibility tooling and has discovered that many organisations simply use accessibility overlays to try to automatically fix issues. However, that approach only fixes about 8% of accessibility issues, and usually creates more, according to Deque CEO Preety Kumar. “Magic fixes largely worsen web experiences for people with disabilities and hurt the state of digital accessibility overall”, Kumar ponts out.
That doesn’t mean automated tools aren’t helpful. WebAIM, a non-profit dedicated to web accessibility, has found that 97% of the top million websites have low-hanging fruit accessibility issues that could be automatically detected—“in less than a minute in most cases”, Alex Tait explained. She recommends running an accessibility tool—like axe DevTools by Deque and the ARC Toolkit by TPGI—before any code is committed to a pull request, in order to continuously find those easily detectable failures. Accessibility should also be considered in peer reviews.
In fact, a lot of so-called accessibility tools make matters worse. Tait points to the tool AccessiByeBye, which turns off overlays that often interfere with screen readers.
But “you cannot automate a fully accessible solution” because, she told WTF, less than half of accessibility issues are detected by tools, so manual testing has a role to play for the foreseeable future. “You have to take it to that place of actually testing the flows and testing [for example] can somebody who only uses a keyboard get to the checkout on this grocery app”? Or, considering another example, can you write and test code, check it into Git, and see it through the CI/CD pipeline via just audio commands?
People with physical disabilities don’t typically use mice and trackpads, navigating mainly with keyboards or voice commands. Use browser-based tools to experience firsthand some of the challenges developers face.
Pursue what accessibility engineer Mark Steadman dubs a phased approach to accessibility in the development lifecycle, where you kick off with quick wins. You can even anonymously poll your developer community to decide which W3C Web Content Accessibility Guidelines you should prioritise first.
Design strategist Raquel Breternitz offers small things that make your code more accessible and usable:
- Use semantic HTML elements instead of DIVs.
- Prefer HTML and CSS, which always beat out JavaScript.
- Check the UX using only a keyboard—what about just one hand?
- Write semantic code in general, which is cleaner and faster.
It ultimately comes down to simplicity and options, Breternitz told me, because that simplicity gives your users options to use your software. That, in turn, gives more users a sense of accomplishment, which leads to improved developer experience. “So they don’t even have to think about you, they rely on you because you won’t let them down”, she said.
An accessibility strategy can kick off at the individual developer level, but engineering management has to be involved in scaling the mindset shift, Tait argues. Plus, nobody works in silos anymore. There are issues that intersect with the backend and there are design decisions involved, for example, “if you’re missing a visible focus indicator on a button, you need somebody to design one”, she said.
Accessible Design Demands Clearer Communication
The majority of disabled people are found in developing countries that rarely have access to high-speed connections and expensive accessories to help them succeed. Accessibility and inclusion often tie back to code simplicity.
“Including dependencies that are superfluous can literally cost developers on bandwidth. This is a real problem that can prevent access to your library”, according to Suz Hinton, currently senior software engineer at CrowdStrike.
She warns against code bloat, unnecessarily complex and long swaths of code that slow developers—and their download, building and transpiling—down. Software engineer Abrar Sheikh points out in a talk on his lived experience that someone with low vision like him can only zoom in their field of perception to include three to four lines of code at a time, versus a sighted engineer who can perceive about ten lines of code at once. So, he literally can’t work with overly complex code.
This is all amplified in places where connections are expensive, metered, and slow, Hinton points out. Be sure to test out your code on slower computers—with different operating systems including Windows—on slower bandwidth than your usual, as a good reminder to keep code streamlined. “Publishing smaller code footprints helps everyone”, she continued.
A simple example she offers is high-resolution logos—icons and thumbnails can weigh megabytes—which probably aren’t useful once developers are already using your project, and certainly slows down testing and code commits.
Screen readers tend to work linearly, so organisation of your code and docs matters. Also, be considerate of how you note changes. Side-by-side code comparisons are quite useless to blind developers, claims Tuukka Ojala, who prefers + and - signs. He also finds indentation useful because he often reads code through a Braille translator and it helps him map out the code in his head.
“I'm a strong advocate of a clean and consistent coding style for a number of reasons, but mostly because not having one makes my life much more difficult”, Ojala wrote.
User-centred design has to drive any digital transformation. As Breternitz puts it, “We don’t have to just make sure that someone can get there, and can understand it when they do, but we also have to find the ways in which folks are excluded and break those barriers down as well”.
“Through accessibility, you get better software, and you don’t have to go back and redo it all when you get sued [for lack of compliance] or when it turns out that your site isn’t that usable for people regardless of access need or disability. I think, typically, if a website or piece of software is inaccessible, it tends to also be less usable”, she points out. Breternitz gives the example of the design trope of action items or interactions hidden behind a mouse hover—it may be aesthetically pleasing but it’s less likely to get clicked, because humans and screen readers don’t know it is there. Also, these hovers are basically impossible on mobiles.
On the other hand, actions that support accessibility typically enhance both developer and customer usability, as well as “Googleability”. Alt text and extra-descriptive text inside code—like labels and descriptions for forms—are useful to provide extra explanation that encourages self-service and discourages gatekeeping jargon. Copyable code snippets are vastly more useful than code screenshots. As a bonus, text speeds up page load-time with significantly less bandwidth.
Docs Always Matter
Year after year, missing documentation is cited as the main obstacle to consuming APIs, and nearly 60% of developers polled in the 2021 State of APIs report said docs are essential to their API discovery process. Optimising docs for everyone—especially if you’re an open source project—is just good business. Also, if you’re aiming to be a global product, clear, text-based documentation is needed for localization.
According to respondents of the same survey, documentation typically lacks:
- Good examples
- Sample code snippets
- Standardisation across an API program (error codes, endpoints)
- Real-world use cases
Nobody is demanding graphs or overly complex docs. Simplicity and consistency allows your company to integrate with partners and expand your business value faster. Plus, this lets you be a steward for Future You who has to use your code and remember why the heck you even did that.
Accessible or usable design, to Breternitz, means solving problems with clear communication, which usually means designing with the newbie in mind. After all, those who are struggling the most and seeking out help are either junior designers or potential buyers, or early adopters who are new to your product.
“We have this cognitive bias that once we’ve learned something, we can’t imagine what it’s like to not know that thing”, she warns. That hurts your onboarding experience. Describe everything you’re doing in a simple way—especially define the core things your product does. Again this makes it much easier for customers to find you because developers google “what is…?” and “how do I...?” too!
Breternitz also warns of shortcuts such as documentation writers having a predilection to include a massive, explain-all graph in the middle of the content with alt text that is useless, just a copy-paste of the caption. At minimum, there should be proper alt text—if you cannot explain it in words, your graph is too complicated anyway—alongside a written description. This way, the graph is available for visual learners but not necessary for anyone to have to interpret. Don’t forget high contrast if you even need colour at all, and if you’re using videos, closed captioning helps everyone understand better.
“When I force myself to explain these things in a bunch of different ways that can be as clear as possible, of course my design comes out way better and more usable because I’ve done that extra work”, she said. The kerb-cut benefit here is that it supports a better developer experience for everyone.
Whether supporting internal or external developer experience, you have to provide better documentation in many formats to onboard and communicate in different learning styles, including visual and audio. Yes, this costs money, but if your target audience is internal or external developers, then it’s foolish not to invest in that community. You’d do this across a penumbra of social media platforms, why not across that many formats to create real value?
If Everyone Has to Use It, Everyone Should Build It
“We're certainly not welcoming disabled people into the workforce, which is a real problem, because, without the voices and expertise of those with lived experiences on our teams helping to build these products, we’re going against the whole purpose of trying to be inclusive.” — Alex Tait
The best way to bake accessibility right in is by going out of your way to hire disabled developers. As the tech talent gap continues, it just makes sense to keep your hiring pool as broad and inclusive as possible.
In 2011, the U.K.’s Government Digital Service (GDS) implemented a “Digital by Default” strategy. This government-as-a-platform looked to go radically paperless and accessible, on the foundation that if every single citizen at some point has to engage with GDS:
- There are no edge cases or edge users.
- It must offer the same experience across all devices.
- Everyone should be involved in the building and maintenance of it.
This digital inclusion strategy famously extended to hiring of the engineering team, which included visual impairment among other disabilities. It also meant creating accessibility design standards that allow for an API ecosystem of partners that help expand services,for things like health and care. By building simply and accessibly, it’s easier for other teams of any size or means to build on your product offering.
Of course, hiring a more diverse team doesn’t just make it better for those on the team, Google’s people with disabilities program proves it makes better products, including making Google Maps more functional for the 65 million wheelchair users worldwide—plus parents with buggies and travellers toting luggage. By building diverse, inclusive teams that then build accessible, usable software, your organisation can be more productive and purposeful.
Abrar Sheikh, currently a staff software engineer at Uber, in the previously mentioned talk, offers tips for recruiting those who are visually impaired. These tips can be adapted for generally inclusive hiring:
- Ask the candidate if they need extra time.
- Ask if they prefer interviews on whiteboards or computers.
Just remember, as Tait put it, “You also shouldn’t be hiring marginalised people to do a developer role and then expect them to consult on diversity”. Their diverse perspectives will positively impact the work, but they should not be given extra work outside their job scope.
Teams have to pay for wider range user testing and compensate disabled people for their expertise. Tait pointed to how often, when disabled people complain they can’t use a product or tool, customer support simply asks them how to fix it: “If you consult with me for free, you’re doing yourself a favour because maybe I’ll fix my product”, which is just more ableism. Don’t forget to add anything you learn under your (likely new) accessibility section of your documentation.
In lieu of, or in addition to, more diverse hiring and consulting, make sure each project has an accessibility advocate, who is given the time to learn about accessible development practices and DX, talk to your most marginalised internal and external customers, and who feels emboldened to speak up and advocate on their behalf. This role shouldn’t be seen as a bottleneck, but touted as someone who impacts the quality of your product.
Onboard with Accessibility in Mind
Set everyone up for success. Make sure you ask new colleagues (and current ones) if they have everything they need to work as effectively as possible. In this now mostly remote-first world it’s even more important, because you might not be able to see people in their working environment—but remember, not all disabilities are visible. This year has seen some great advancements in hardware, especially by Microsoft, that launched Xbox adaptive controllers and soon will launch Adaptive Accessories for navigation.
“For me as a graphic designer, I felt like one of the biggest limitations was simply how efficiently I could work. Even though I felt like I was doing really good work, I just wasn’t able to earn the same income”, said Mandy, who was born without her right forearm and hand. The “one-size-fits-one” Adaptive Accessories enable people with disabilities “to fully use our bodies in functional ways that just wasn’t possible before”, she says, while the video shows her drawing with a stylus with her left hand while using the Microsoft adaptive button with eight programmable switches with her right elbow.
Limited access to speed doesn’t just affect income, it also affects competitiveness. “With data science, I do a lot of coding and when people realise that I code a lot slower than them, I feel self-conscious.” In the same video mentioned above, Natalie says that, as a quadriplegic, she cannot leverage the multi-button shortcuts her colleagues can.
“I think that the disability community is underserved and we are forced to adapt to the technology rather than the technology be developed to us”, Mandy says. Which is the same across the world—we already wrote about how Microsoft’s director of accessibility David Dame spent two years at a previous job dehydrating as his work’s toilet wasn’t wheelchair accessible.
“For employers I think it’s important to understand that little accommodations can go a long way for somebody who’s disabled”, says Edmund Dunn a full-stack Drupal developer, disabled veteran, and mentor to veterans looking to get into tech, speaking about his experience in the A11yTalks meetup. Following 20 years of service, Dunn cannot sit or stand for a long time without an “inordinate amount of pain”. When he got his first job in tech, he didn’t really know what he needed for his set-up. His doctors recommended a zero-gravity recliner, but then he ended up having neck problems from looking down at a laptop all day. His doctors and the HR department worked together to come up with a solution that had a monitor on one swing arm and a keyboard on another. Accommodating disabled employees isn’t a one-off, and, with 4.7 million disabled veterans in the U.S. alone, that’s a huge talent pool that can be tapped by the tech industry.
When you are trying to hire different kinds of developers, you also need to make technical choices that embrace more people. This could be allowing developer tool choice, such as low-code or visual-coding tools that could be useful for those with dyslexia and dyscalculia. There are newer low-code environments available all the time, which enable all developers to work faster:
Choreo, which uses JVM-based language Ballerina under the covers, is a particularly interesting option for building cloud-native apps, with both visual and text-based code, so developers with different styles can collaborate over the same code base.
Remember to ask new hires, community members, and customers what they need to do their best work. In Sheikh’s talk, he mentions how he needs to be seated farthest from the window as bright sunlight further reduces his eyesight. His manager also makes sure he has access to slide decks ahead of any meetings to run through a screen reader on his own workstation.
Making sure each person has everything they need to work as effectively and comfortably as possible contributes to the kind of psychological safety and culture that cultivates high-performing teams.
Previous article
