How TypeScript Can Improve Developer Accessibility

If you’ve been on tech twitter in the past week, you might’ve seen a TypeScript debate that seemingly came out of nowhere. Well, it came from news that Turbo 8 is dropping TypeScript. There has been all kinds of commentary on this news, but there’s one that’s almost always left out in discussions about developer tooling: developer accessibility.

Not enough people in software think of developer productivity as effectively being the same thing as developer accessibility. So let’s talk about it! Prepare to go through some of the features of TypeScript that can be especially helpful for disabled and/or neurodivergent developers. I’m listing them in alphabetical order.

If you think something is missing below or want to share the accessibility benefits you experience with TypeScript, send me a tweet or email me!

Code editor tools (code completion, hover tooltips, etc.)

The code editor tools that come with TypeScript are my favorite part of TypeScript. Code completion is probably the top one for me. I can be very easily distracted some days (ADHD) or I might be mentally tired from fighting through distractions. Code completion ends up being a tiny helpful distraction. It keeps me on task and gives me all the options I have at hand as I type. I don’t I have to remember every single detail of whatever code I’m working with. TypeScript does it for me and gives me little reminders. It’s also a lot less typing, which my hands and brain are very grateful for on high pain days.

The hover tooltips that appear on top of code are also helpful for reducing cognitive overload and increasing productivity. It reduces the scope of understanding a codebase at a high level, rather than having to memorize so many small details and staying on top of changes to them. For example: It’s not important to memorize every possible property of an object that fits under your business logic. Those can change easily at any time and without you knowing if you work on a larger team. It’s impossible to keep track of everything yourself.

Maintainable, built-in documentation

I’ve worked on all sorts of projects in my career already. From brand-new to several years old, from small to medium sized teams - they all go through the same problems in different flavors. One big problem every development team faces is documentation maintenance. I personally love writing documentation, and I still think making it maintainable is the hardest part.

It can’t just be about one person’s process or system for maintaining documentation, because we all think and work differently. Finding a balance across a team’s differing working styles is incredibly important for healthy collaboration. I’ve found that coupling different types of tasks together with the main task you already have the hang of is fairly successful.

For example: It can be easier to remember to update documentation when it’s a co-located code comment vs. when it’s in a separate Markdown file. This is because it’s right next to where you’re already working. It’s less time than figuring out where the existing documentation might be, or trying to decide where to put new documentation.

What’s even better is that TypeScript is functional co-located documentation. When you make a change to a type or interface (which is already part of the code writing process), the documentation is getting updated at the same time because the types are both code and documentation. You may need to update some neighboring code comments as well, but there’s still less steps involved in keeping your codebase’s documentation up to date.

Immediate feedback

TypeScript provides feedback on your code at compile time, meaning you don’t always have to wait until you run your code to see if it doesn’t work. If you’re writing code that needs to be tested in a browser, switching from your code editor to your browser to do so is a mental context switch.

These moments can carry large risk for distraction depending on your ability to focus at the time. They can also be exhausting after a while if you have to fight your brain each time to force it to stay focused. Since TypeScript can help reduce the occurrence of some runtime errors before you even leave your code editor, that means less of these context-switching moments, so less risk for distractions and less energy wasted on what’s likely common and minor issues.

Immediate feedback also reduces the cognitive load needed to figure out why a likely common runtime error happened. Who wants to spend time debugging typos or digging into source code to figure out why you couldn’t access a property on an object that doesn’t actually exist on it? Don’t get me wrong, reading code can interesting and insightful. But if I’m trying to write code efficiently, I don’t want to read other code that much. Working smarter (not harder) means making computers do the heavy lifting for us wherever possible. 😉

Onboarding

Onboarding to a new codebase regardless of its age or size is no small task. The questions that come to mind in the process are endless, and that can get overwhelming and discouraging fast. It’s also very time consuming, and it can be scary building up the confidence to ask questions to your peers when you’re new and getting to know them.

What tooling does it use? What tooling does it not use that you might be accustomed to relying on? What standards does it follow? Where is the documentation (if any)? Who do you ask questions to? Where can you learn the context of various decisions? What areas are people too afraid to change? Does it use camel case or snake case? What ESLint rules does it have (if any) and why? How do different areas connect to the business logic? What is the business logic? Is this particular business logic still relevant? Why is this code here if it doesn’t look like it’s used? Does the person that wrote this still work here? Why does the UI do this? Who asked for this feature? Where is this function defined? How was this data computed before it was passed to this function? …

With TypeScript working as built-in documentation and also having helpful code editor tools for jumping to definitions or showing additional information through hover tooltips, there’s decreased cognitive load needed for navigating a codebase. You don’t have to guess where to find documentation or definitions. You also don’t always have to leave the current file you’re in. And when you start writing code, you’re given suggestions of what’s possible for you to do as you write. You don’t have to pause, leave the current file or section of code, or remember what you were doing and where.

TypeScript helps you start writing code that does something more quickly, which is beneficial for the contributors or consumers of a codebase. But this isn’t just about the developers that build a product. Developers that are using a software product are going to keep using it if it helps them do their jobs quickly and successfully. Onboarding developers as users is an important facet of building software as a product.