
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](https://web.archive.org/web/20230909190042/https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01). 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](https://twitter.com/ashleemboyer) or [email me](mailto:hello@ashleemboyer.com)!_

## 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.


TypeScript can be a helpful tool for disabled and/or neurodivergent developers.

How TypeScript Can Improve Developer Accessibility


This isn't a long post, as there's not much to say other than "Yes, Deaf People Can Listen to Music". Deafness is a spectrum and doesn't automatically mean someone has zero hearing. Disability (which is what I consider my deafnesss, but not all d/Deaf people do) is a spectrum.

Music and d/Deaf people have existed for the same amount time. We can experience music through sign language interpretation, lipreading, watching musicans perform to the beat, feeling vibrations, and for those of us that use assistive technology like hearing aids or cochlear implants, we can hear some parts of songs. Again, it's a spectrum. So even with assistive technology we still all have different levels of hearing.

Here are some resources you can use for further research:

- [How Do Deaf People Listen To Music? (American Sign Language Vlog) - Rikki Poynter - YouTube](https://youtu.be/nKrHhqOQ5mw)
- [How Do Deaf People Experience Music? - AJ+ - YouTube](https://youtu.be/dwqSuvFzDdI)
- [How Do Deaf People Experience Music - DITSignLanguageSoc - YouTube](https://youtu.be/fvuYTDhi0t0)
- [Deaf 101: How Do Deaf People Listen To Music? - National Deaf Center](https://nationaldeafcenter.org/resource-items/deaf-101-how-do-deaf-people-listen-to-music/)


Music is an art that can be experienced by anyone.

Yes, Deaf People Can Listen to Music

## The Fleegle heel

- **Why I learned this:** The vanilla toe-up sock pattern I generated using [KnittingRecipes.com](https://knittingrecipes.com/) includes instructions for a short-row heel. After a few attempts and not succeeding at this kind of heel, I remembered having done the Fleegle heel before and really liking it's magical simplicity for me. I decided to give this heel another try instead.
- **How I used this:** I'm using this heel style for a pair of socks for my husband.
- **Resource I referenced:** [Fleegle's Blog: Fleegle's Toe-Up No-Flap, No-Hassle Sock Pattern](http://fleeglesblog.blogspot.com/2006/11/leegles-toe-up-no-flap-no-hassle-sock.html)

## Preventing holes in the Fleegle heel

- **Why I learned this:** The resource I linked in the previous section _also_ had an insightful approach to preventing holes in the ankle area of the sock heel. We love a sock without holes!
- **How I used this:** I used this in the same pair of socks.
- **Resource I referenced:** [Fleegle's Blog: No Sock Holes For You](http://fleeglesblog.blogspot.com/2007/09/no-sock-holes-for-you.html)

## Right-lifted increase and left-lifted increase

- **Why I learned this:** These are right- and left-leaning increases that help give a certain shape and direction of texture when used strategically.
- **How I used this:** Also in the same pair of socks.
- **Resources I referenced:** 
  - [Lifted Increases Tutorial: RLI & LLI - Azalea & Rosebud Knits](https://www.azaleaandrosebudknits.com/blog/lifted-increases-tutorial-rli-lli)
  - [Knitting Help - Lifted Increases - VeryPink Knits](https://www.youtube.com/watch?v=VZ01r1hWGks)

## Slip, slip, purl decrease

- **Why I learned this:** This is decrease that leans (good for shaping and direction of texture) and is created from the wrong-side of the sock. It was used in the heel-turn decreases.
- **How I used this:** Same pair of socks!
- **Resource I referenced:** [Knitting Help - Slip, Slip, Purl (SSP) - VeryPink Knits](https://www.youtube.com/watch?v=vmzjBKeyQjY)

Here are a few things I learned August 17th, 2023.

Today I Learned

TIL #3: Fleegle heel, Right-Lifted Increase, Left-Lifted Increase, and Slip Slip Purl


💡 _This post is part of [my Today I Learned (TIL) series](/blog/series/today-i-learned). Each section below describes a thing I learned today and the resources I used to learn it._

## CSS property `grid-auto-rows`

- **Why I learned this:** While working on my website migration to use the Next.js App Router, I noticed that at smaller/zoomed viewports my grids of blog post links have different sized heights. I think grids of card-like elements look nice with equally sized rows and heights, so I Googled "css make rows in a grid same height". That search led me to the `grid-auto-rows` CSS property.
- **How I used this:** All I needed to do in my case for this to work was add `grid-auto-rows: 1fr;` to my CSS class that set `display: grid;`. I figured I would need a `height: 100%;` on the child elements, but I didn't!
- **Resources I referenced:**
  - [Equal height rows in CSS Grid Layout - Matei Stanca](https://ambientimpact.com/web/snippets/equal-height-rows-in-css-grid-layout)
  - [`grid-auto-rows` - MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-rows)
  - [`grid-auto-rows` - CSS-Tricks](https://css-tricks.com/almanac/properties/g/grid-auto-rows/)
  - [CSS `grid-auto-rows` Property - W3Schools](https://www.w3schools.com/cssref/pr_grid-auto-rows.php)
 
## Judy's Magic Cast-on

- **Why I learned this:** I've actually done this cast-on many times, but it's been many months and I couldn't remember. I've always used it for casting on toe-up socks. I'm actually not sure if it's used in other patterns! Maybe finger-up mittens? 😂
- **How I used this:** I finished knitting my friend's baby items so it was time to start a new project. I promised my partner my next project would be a pair of socks for him! I tend to only knit toe-up socks so I needed to recall this fancy cast-on.
- **Resources I referenced:**
  - [Knitting Help - Judy's Magic Cast-On (VeryPink Knits)](https://youtu.be/GV9UaFgZ6Q0)
  - [Knitting Help - Slow Motion Judy's Magic Cast-On (VeryPink Knits)](https://youtu.be/MglfYj7tMiU)


Here are a few things I learned today (August 5th, 2023).

TIL #2: grid-auto-rows CSS property and Judy's Magic Cast-On


💡 _This post is part of [my Today I Learned (TIL) series](/blog/series/today-i-learned). Each section below describes a thing I learned today and the resources I used to learn it._

## Figma Boolean Operations

- **Why I learned this:** I'm currently working on migrating my website to use [the Next.js App Router](https://nextjs.org/docs/app). In this process, I'm cleaning up old code and dependencies that I don't really need. One of those dependencies is [FontAwesome](https://fontawesome.com/). I only used a few of the icons, and I wanted to give creating my own icons a try. I started with basic arrows.
- **How I used this:** I made my arrow Icons out of 3 rectangles, each with the same `border-radius` on every corner. After I placed them in an arrow shape, I selected each rectangle, clicked the boolean operation menu in the top center toolbar, and selected the "Union selection" option. It was a lot easier to do than I thought it would be! Then I coped the new union as SVG, and pasted it into an `.svg` file in my code. Tada! Icon created.
- **Resource I referenced:** [Boolean operations - Figma Help Center](https://help.figma.com/hc/en-us/articles/360039957534-Boolean-operations)

## Knitting Duplicate Stitch

- **Why I learned this:** My friend is having a baby soon, and I'm making a few knit items to gift at the baby shower. She loves all things spooky and fall so I chose the pieces based on that. One of the pieces uses the stranded colorwork technique for its pattern, and the other uses the duplicate stitch. I'd never done duplicate stitch before, but I didn't let that stop me! I'm an experienced knitter so I was ready for the challenge.
- **How I used this:** The piece that I needed the duplicate stitch for is a small black hat with a pumpkin. The pumpkin and its stem are the contrasting colors, so that's where the duplicate stitch was required. IT TURNED OUT SO CUTE. I'll post it under [the projects section of my site](/projects) after it's been gifted.
- **Resources I referenced:**
  - [Knitting Help - Duplicate Stitch - VeryPink Knits](https://www.youtube.com/watch?v=-cfmjyaaAdw)
  - [Knitting Help - Slow Motion Duplicate Stitch - VeryPink Knits](https://www.youtube.com/watch?v=8q5Qx5NEzUU)

## Next.js Absolute Imports

- **Why I learned this:** As I mentioned above, I'm migrating my website to use [the Next.js App Router](https://nextjs.org/docs/app). Since I have cleanup tasks that affect most of the codebase, I decided to create a new project from scratch. I took the opportunity to remind myself how to configure absolute imports.
- **How I used this:** When I added the arrow icon to my fresh project, I wanted to add it to the main `components` folder. It was my first main component, so I had to create the folder. When it came time to import the icon the import statement wasn't very pretty! I knew changes needed to be made in my `tsconfig.json` file, but I couldn't remember it exactly. I did a quick Google and it turns out all I needed to do was set the `compilerOptions.baseUrl` option to `"."`. Easy peasy!
- **Resource I referenced:** [Configuring Absolute Imports and Module Path Aliases - Next.js](https://nextjs.org/docs/app/building-your-application/configuring/absolute-imports-and-module-aliases#absolute-imports)


Here are a few things I learned today (August 4th, 2023).

TIL #1: Figma Boolean Operations, Knitting Duplicate Stitch, & Next.js Absolute Imports


A few months ago I checked out Brené Brown's [_The Gifts of Imperfection_](https://brenebrown.com/book/the-gifts-of-imperfection/) from my local library. I haven't finished it yet, probably because the first few pages hit me in a way I wasn't expecting. I know I will need to be in a safer headspace to finish reading this one. Here are some of the quotes that stood out to me and helped me better understand what I've gone through over the years.

Quote 1:

> One thing that's become very clear to me is that the experience of sharing our vulnerability is not the same for all of us. ... The greatest casualty of trauma--the thing that trauma often takes away from us--is the emotional, and sometimes even physical, safety that is necesary for us to be vulnerable.

Quote 2:

> Dehumanization--the core of racism, sexism, homophobia, transphobia, xenophobia, and all systemic forms of oppression and/or bias--is a form of daily trauma. You only have to witness someone who shares your identity suffering to experience real emotional and physical trauma.
>
> Many of these systemic forms of trauma are so pervasive that asking people to embrace vulnerability and imperfections without taking into consideration their lived experience can be asking them to do something that is not emotionally or even physically safe in all environments.

Quote 3:

> None of us can fully embrace the gifts of vulnerability, courage, and authenticity if any of us are denied those gifts because of who we are or what we've endured. Being imperfect, authentic, and vulnerable is a function of being human--not a privilege afforded to those who can get away with it without being labeled, dimissed, and judged.

A large part of my personal journey of self acceptance has been learning more about trauma, and that it's something that doesn't just affect military veterans, first responders, survivors of physical abuse, etc. It affects most of us at varying degrees. These quotes helped me realize that I've actually been through a significant amount of trauma in my career.

Based on these quotes... I now know how my work in web accessibility is actually traumatic for me.

In my experience, I've had to do more advocacy on behalf of my communities than teaching how to make the web accessible. Most places I've worked believe that accessibility is important, but they tend to only have a surface-level understanding of what accessibility and disability inclusion are. Even in the most accessibility-forward organizations, I've had to advocate for my communities at almost every single step.

There are still countless stigmas, stereotypes, and biases that disabled people are dramatic, making things up, or looking for attention. Not only am I constantly witnessing people from my communities being harmed by accessibility barriers (and experiencing them myself), I'm also constantly in a position where non-disabled people need convinced that something is in fact an accessibility barrier.

It hurts to see what people think of my community, because that's also what they think of me. It's invalidating and dehumanizing. It's personal. It's a fight that's rigged in the favor of the non-disabled people in positions of power. It's why we need people from marginalized backgrounds in positions of power, and why we should accept their life experiences as strong expertise and be paid for it.

I happen to be someone that's very vocal about my identity, experiences, and accessibility needs. I'm not sure when that started because I used to be pretty shy growing up. Now it's sort of involuntary and takes me more work to not be vocal. But I also continue to be vocal because I know there are countless people who can't. I'm very privileged to have the means to speak up.

And this is where the push for storytelling & vulnerability in DEI falls so, so short. The majority of people pushing for it are already in positions of power, where they're more safe from bias and judgement than those around them that aren't in positions of power. They're skipping steps and not following through when they ask others to be vulnerable. The people in power aren't checking if environments are even safe for vulnerability, and they aren't putting systems in place that actually protect folks when they decide to be vulnerable.

So if you're someone in a position of power & push for the people around you to be more vulnerable, stop and seriously check if that's possible for them. Don't take just anyone's word for it either. Really dig and do your research. Listen to what people are saying, and also what they're not saying. Establish trust. Provide anonymous methods of feedback. Consider the possibility that what you're asking folks to do is an impossible choice: be vulnerable when it's entirely unsafe, or potentially lose a job for not doing what someone above them said to do.


Expecting vulnerability is unfair when it's not safe to be vulnerable.

Ashlee M Boyer

Recommended writings

Most recent writings