DEV Community: Kat Tow

Intro to A11y: Where and How

Kat Tow — Fri, 17 Apr 2020 00:07:57 +0000

This is the second article in a 2-part series. Read the first half: A11y 101: What, Who, and Why.

And a few notes before we get started:

a11y is a numeronym for accessibility. These two words will be used interchangeably throughout.
the correct linguistic choice between person-first and identity-first language (e.g., a person with a disability vs. a disabled person) is the choice an individual or community prefers. Since this article covers disability very broadly, it will use both person-first and identity-first language.

The first article covered the what, who, and why of web accessibility. Let's dive into how you can get started, and where to learn more.

What you can do to get started

Web accessibility is not new. The Web Content Accessibility Guidelines (WCAG) were first established in 1999, over 20 years ago. Despite this, accessibility has a reputation for being extraordinarily difficult to implement. It doesn't have to be.

The most important thing to understand when getting started is that you won't go from zero to hero. Websites take time and expertise to design and develop, and the same is true when updating them.

The first step is to identify your website's most critical paths. What do users absolutely need to be able to accomplish on your site? In Domino's case, their most critical path was for users to order a pizza through their website, but their site disabled some users from doing so. Ensuring these critical paths are accessible will reduce your liability. The next step is to continue identifying and improving issues incrementally.

Common problems

For developers and designers new to accessibility, it can be hard to even know what a11y issues to look for. Here are a few of the most common problems:

Readable text

Make sure all your website's text meets minimum contrast thresholds. Additionally, avoid using only color to identify information or tools (e.g., links), and be sure text is resizable.

Text alternatives

Anything essential that isn't text needs a text alternative. Every image that conveys important meaning to the user needs alt text. For example, images of products for sale should have descriptive alt text. Images that don't convey meaning should have empty alt tags. Why? Because without an empty alt tag (alt="") screen readers will announce the entire filename (cute_dogs_102919_prod_final2.jpg). Video and audio need text alternatives as well.

Descriptive and accessible links and buttons

Make sure that all interactive elements contain text or alt text that informs users what that link or button will do. Additionally, all links, buttons, and other interactive elements must be reachable using a keyboard (more on this below).

Label your forms

Forms are typically part of a critical user path. Whether it's a form to sign up or order pizza, forms are critical to most sites. Recent design trends have put some forms in hot water by removing label elements in favor of things like placeholder attributes. Screen readers won't announce placeholders, so be sure every form element has a corresponding label.

Be chill

Check your website for flashing or fast animations and movement (I'm looking at you, auto-playing video banners). This kind of content can cause reactions as severe as seizures, and as common as motion sickness. If the content must stay, be sure you warn users and make it easy to stop playing, and take advantage of the prefers-reduced-motion CSS media query.

Detecting issues

Now you know what to look for, but... do you have to manually audit every single page for all of those issues? Thankfully, you do not; there are several tools to help you streamline and even automate parts of accessibility auditing.

Note: none of these tools are sufficient on their own or together. They will make your audits easier, but some manual testing will always be necessary to ensure your site is accessible.

Linting

Linting is a great way to prevent a11y bugs before they hit production. If you're writing React, you should check out eslint-plugin-jsx-a11y to statically check your JSX elements. Regardless of your stack, you can also use pa11y in the command line to audit an entire site.

Automated tests

In-browser testing automates a lot of checks for you - these tools will find common errors like insufficient color contrast, missing alt text, duplicate landmarks, and more. Two of my favorites are axe, which is available as a Chrome extension and for Android testing, and WAVE, which has a web app, Chrome and Firefox extensions, and API services.

If you're looking to level up, you can also look into adding accessibility checks into your unit, integration, and end-to-end tests. Most popular test runners have accessibility packages or tools you can use to incorporate some automated checks.

Tab testing

Tab testing is manual but fairly low-effort. Open up your site in a browser and start hitting the tab key! (To go backward, hit shift+tab.) You should:

Be able to reach every interactive element on the page (links, buttons, form elements, etc.)
Be able to visually see which element is in focus
The order in which you reach elements should make sense

Take note of any difficulties you experience (missing focus styles are the most common) so that you can investigate and remediate those problems later.

Content analysis

Content analysis is often overlooked in accessibility recommendations. Especially for developers, it can be all too easy to focus on testing and remediating a11y issues that we can fix in code. For cognitive and neurally disabled users, ensuring content accessibility makes a big difference. Most of this process must be manual, like ensuring that link text is descriptive (no more 'Click here' links). Some of it can be assisted - writing editors like Hemmingway (free!) and Grammarly (freemium) can help your team ensure your content itself is more accessible.

Screen reader testing

Screen reader testing can be very intimidating, especially for those just getting started. For anyone new to accessibility, I recommend just choosing one screen reader (SR) software that works on your existing OS. Get comfortable with one tool and with the process of using a screen reader before you go for 'full coverage' SR testing.

The most popular screen reader combinations are:

NVDA + Firefox or Chrome (Windows)
JAWS + Chrome (Windows)
VoiceOver + Safari

If you are testing mobile, you'll use want to use Voiceover on iOS with mobile Safari, or Talkback on Android with mobile Chrome.

All of these screen readers are free except JAWS, which does require an annual license.

As you prepare to start testing, the WebAIM Screen Reader Survey #8 (2019) can help you understand how people use screen readers. And when you do get started, you can use these keyboard shortcut cheatsheets to navigate using your keyboard.

This process may uncover behaviors that confuse you. Some behavior may not be what you were expecting, but is it what disabled users are expecting? The best way to find out is by conducting user testing.

User testing

User testing helps you ensure your project actually works. It's more reliable than any manual or automated tests you can perform. (Note: don't waste your testers time - test and remediate smaller issues first!)

Whether you aren't doing any user testing yet at all or have a robust user research practice, it's important to include users with disabilities. If you need help recruiting disabled users, there are a few companies that can help:

How to learn more

Like any subject in web design and development, there's a lot of deep learning and expertise you can pursue in web accessibility. You may be looking to broaden your understanding (e.g., with Inclusive Design) or deepen your knowledge (e.g., really understanding ARIA).

Personally, I am still learning a ton about accessibility. There's plenty I still don't understand, and a lot I could do to improve my testing practice. Right now, I've integrated linting, in-browser audits, and two screen readers into my regular toolkit. At my job, I'm currently working on adding more a11y to our unit and end-to-end tests.

As you continue to learn about web accessibility, it's important to remember that this isn't the wild west. The Web Content Accessibility Guidelines (WCAG) were established over 20 years ago and was updated as recently as 2018. The documentation can be intimidating to read, but it's important to remember that there are guidelines, expected behavior, and testable practices.

As for resources: the following list is far from complete, but it includes some of my favorite resources that are great for getting started. These have been tremendously helpful in my journey to learn about a11y - I hope they help you too!

If you have any favorite resources I should add, let me know on Twitter!

Intro to A11y: What, Who, and Why

Kat Tow — Mon, 13 Apr 2020 14:06:37 +0000

This is the first article in a 2-part series. The second half will be published next week!

If you're reading this article, you're already passed the first hurdle to web accessibility: recognizing the need for a more accessible web. But no matter if you're a code newbie or a professional developer, just knowing accessibility is important is just the tip of the iceberg. Whether you're a seasoned pro or new to web development, it's important to learn:

What is 'disability' and 'accessibility'?
Who might be affected?
Why does this matter?
How to get started
Where to learn more

This article will cover the what, who, and why of web accessibility.

Plus a few notes before we get started:

a11y is a numeronym for accessibility. These two words will be used interchangeably throughout.
the correct linguistic choice between person-first and identity-first language (e.g., a person with a disability vs. a disabled person) is the choice an individual or community prefers. Since this article covers disability very broadly, it will use both person-first and identity-first language.

What is disability?

What comes to your mind when you think of disability? Most people would think of another person with some kind of physical impairment, such as a wheelchair user. You might even think about disabilities that aren't immediately obvious to outside observers, like deafness or learning disabilities.

Whatever you can think of... you're thinking of attributes or characteristics that people have. In this mental model, needing a wheelchair is a feature of a person. This is known as the "medical model" of disability. This model certainly has valid uses (for instance, in medicine!) but it isn't particularly helpful for designing and developing digital products. In fact, this model can contribute to an attitude that accessibility is an "edge case" that isn't a priority for the development team.

Now, instead of picturing something for the word 'disability', try something different. Imagine a world in which almost everyone you know is blind. Your coworkers are blind, the food service workers are blind, most people are blind. In this world, since most people are blind, almost all written word is in braille! Library books are in braille. Restaurant menus are in braille. Government pamphlets about essential services are in braille. And you don't read braille.

In this world, being blind is not a disadvantage, it's the status quo. And the world around us has been designed by and for people who live in this status quo. You, as a non-braille reader, are at a huge disadvantage. Your impairment is not due to a medical condition but is a symptom of design.

This is known as the "social model" of disability; poor design disables users, and good design enables all users.

Who is this for?

Now that we have a better model of disability, we still need to understand who is disabled by poor web design. Some users rely on assistive technology, while others may use adaptive strategies. Those users rely on different and multiple devices, screen sizes, and methods of input.

It's also important to understand that disability is not always permanent. The social model of disability reminds us that anyone can be disabled by the world and the situation around them. Check the list below - even if you don't consider yourself disabled, how many of the examples below could happen to you?

Examples of disabled users

Your users may be disabled by...

Vision: Cataracts, color blindness, full or partial blindness

Mobility: Broken wrist, repetitive stress injury, spinal cord injury

Speech: Sore throat, noisy location, unable to speak

Hearing: Ear infection, noisy location, deaf or hard of hearing

Cognition: Sleep-deprived, learning disabilities, autism

Neural: Anxiety, depression, PTSD

Why does this matter?

Chances are you've dealt with at least one of those issues before, and you probably will again. Imagine breaking both wrists or arms in a traffic accident - how would you continue to use your computer or mobile phone while in casts?

Anyone can become disabled, even temporarily. And many disabilities are not visible. Whether or not you realize it, you certainly know people who deal with disabilities every day.

According to a 2014 survey from the Social Security Administration (SSA), 85.3 million Americans are living with disabilities. That is over 1 in 4 Americans. This includes people with impairments and restrictions that are not classified as 'severe'. About 55.2 million Americans, or 17.6% of the population, had a severe disability.

Does your development team support IE, with only 2% global usage? Why prioritize those 2% of users over the 17.6% of Americans with severe disabilities?

While not every impairment will impact web and technology use, there is inarguably a significant portion of potential and current users that may be disabled by our choices as web designers and developers.

Finally, if product reach isn't enough of a motivator, consider this: the United States is currently seeing a massive uptick in web accessibility lawsuits. Since initial rulings in 2017, and spurred by the Domino's ruling in 2019, a growing number of companies are facing lawsuits and liability risks from inaccessible websites. Is a lawsuit something your company can afford?

Making the web accessible reduces liability, increases your market, and most importantly, is the right thing to do.

Getting started

If you're ready to start improving your website's accessibility, stay tuned for the second article in this series - A11y 102: Where and How. The second part will cover how to identify and remediate the most common accessibility issues, and where to continue your learning.

Reusable, accessible headings in React with TypeScript

Kat Tow — Wed, 19 Feb 2020 19:23:40 +0000

Making reusable components is one of the best things about React. Developers write less duplicate code, and our sites and apps can have a more consistent UI. This is good!

Making content clear and logical to both screen readers and web parsers is also a good thing. Among other things, that means that heading elements (h1 - h6) need to appear in order. To learn more about why this matters, read Fen Slattery's excellent article on HTML headings.

Both of those things are important, but they don't always work together well. Working with components introduces the risk of disorganized headings. A component may be used in two places, with each page hierarcy demanding different heading levels. And as a project grows in size, a change to a component in one place may have unintended consequences in others.

What might that look like? Something like this:

const Banner = ({ headingText, description }) => (
  <div>
    <h1>{headingText}</h1>
    <p>{description}</p>
  </div>
)

That component could be a problem if you ever want to use it elsewhere in your app. Let's say you use the Banner on one page, and it has your h1. But what about later, when you want to use it halfway down a different page? One where the h1 element already exists? An h2 or h3 might be the right choice in that case. Whether you've got a banner, a card, or any other piece of UI that might need a heading, you should make it flexible.

How do we do that? React magic! Let's make a reusable heading component that can accept props for the heading level it should render. Then we can use our flexible heading component in our Banner.

A reusable JavaScript header

If you search the web for flexible react heading components, you might find something like this:

// a JavaScript flexible heading element
const JsHeading = ({ headingLevel }) => {
  const Heading = headingLevel
  return <Heading>{children}</Heading>
}

// our reusable banner
const Banner = ({ headingText, description }) => (
  <div>
    <JsHeading headingLevel="h2">{headingText}</JsHeading>
    <p>{description}</p>
  </div>
)

That's great... for regular JavaScript. In fact, Suzanne Aitchison has a great post on this as well. If you're not using TypeScript, I'd recommend reading her article. She ends with some valuable ideas on how to prevent unwanted behavior.

But what about TypeScript?

The title of this article is 'Reusable, accessible headings in React with TypeScript' - and the code above won't work in TypeScript. Even if you try adding explicit types, you won't get too far.

You might try casting your input, but I wouldn't recommend it. You'll end up casting to unknown in between and it's just gross. Besides, why cast when you can properly type everything to begin with? But, what types do we need?

You might think we should pass an heading element directly as a prop. I'm afraid we can't do that, Dave. You'll get an error if you try to directly pass an HTMLHeadingElement as a prop. The most flexible type you can pass in is React.ElementType. Let's take a look:

// extend your interface to be sure your heading element can have stuff like a className and children
interface HeadingProps extends React.HTMLAttributes<HTMLHeadingElement> {
  headingLevel: React.ElementType
}

const TsHeading: React.FC<HeadingProps> = ({
  headingLevel,
  children,
  className,
}) => {
  const Heading = headingLevel
  return <Heading className={className}>{children}</Heading>
}

// our reusable banner
const Banner: React.FC<{ headingText: string; description: string }> = ({
  headingText,
  description,
}) => (
  <div>
    <TsHeading headingLevel="h2">{headingText}</TsHeading>
    <p>{description}</p>
  </div>
)

Cool! Great! This works, and it renders just fine. Except... you can now pass in any element to your <Heading /> element.

const Banner: React.FC<{ headingText: string; description: string }> = ({
  headingText,
  description,
}) => (
  <div>
    <TsHeading headingLevel="table">{headingText}</TsHeading>
    <p>{description}</p>
  </div>
)

We can pass in a table and it won't give us an error - in fact, it will render to the page as <table>Whatever text you passed</table>.

Just the headings, please

So what's a safe way to ensure you only pass heading elements to your reusable <Heading />? This one took me a while to get right. I won't bore you with all my trials, tribulations, and failures - here's what I found that works.

// the interface needs to explicitly declare which strings are safe to pass
interface HeadingProps extends React.HTMLAttributes<HTMLHeadingElement> {
  headingLevel: "h1" | "h2" | "h3" | "h4" | "h5" | "h6" | "p"
}

const TsHeading = ({
  headingLevel = "p",
  children,
  className,
}: HeadingProps) => {
  const Heading = ({ ...props }: React.HTMLAttributes<HTMLHeadingElement>) =>
    React.createElement(headingLevel, props, children)

  return <Heading className={className}>{children}</Heading>
}

const Banner: React.FC<{ headingText: string; description: string }> = ({
  headingText,
  description,
}) => (
  <div>
    <TsHeading headingLevel="h2">{headingText}</TsHeading>
    <p>{description}</p>
  </div>
)

So what's going on here? Two things:

we need to explicitly tell the interface which strings (representing html elements) we want to accept. You might notice I've included "p" - this is a fallback, in case you want to use this element without a heading. You can adapt this to match your needs!
Our Heading just got more complex. Because we can't directly pass an HTML heading element to a React component as a prop, we instead need to pass a (valid) string, and use that in React's createElement method. React.createElement is actually how JSX works under the hood, but that's a totally different topic.

And that's it! Now you can use your heading component in any other reusable, composable component. Go forth and create accessible websites!

How often do you test with screen readers?

Kat Tow — Fri, 31 Jan 2020 16:41:00 +0000

Is it part of your deploy checklist? Semi-regular? What's your strategy?

How to navigate learning to code online

Kat Tow — Mon, 20 Jan 2020 21:06:19 +0000

Learning to code is hard. Like, really hard, especially for folks without strong math backgrounds, resources to modern computers, or internet access at home.

So where do you get started? And how do you sort through hundreds of tutorials, posts, and jargon? And why should you listen to me?

I'm a self-taught developer, but not one of those 6-month wunderkind. It took me a couple years to learn what I needed to get my first development job, but I managed to do it. I found time in my 60-hour workweeks, battled mental health issues, and maintained my social life and sanity. And you can too.

Don't be discouraged by those wunderkind. Most of us can't cut back on sleep, family time, or even quit our jobs to learn to code. Be patient, practice solid learning habits, and try to have fun.

This article will list my tips for anyone trying to learn to code online. Let's get started with a few key terms:

Glossary of terms

Frontend: Also referred to as 'client side'. This is the part of a website that users interact with. A frontend developer codes (and sometimes designs) web pages. They typically use languages like HTML, CSS, and JavaScript.
Backend: This is the part of a website that you can't see. The backend stores and manages data. It also provides the 'frontend' logic to access and manipulate that data.
Full stack: The 'full stack' is the combination of front- and backend. Many job postings may refer to this. As web development grows more complicated, it is more difficult to master every part of the 'development stack'.
Pseudocode: It's 'fake code'! Writing pseudocode means writing out what your code should do in regular language. Typically you will turn each line of plain language into actual code. This helps you work through a problem in manageable chunks.
Language: This is code that can be run by a computer. Different languages are work in different environments (e.g., websites, iOS, smart refrigerators). Examples include JavaScript, Ruby, and Python.
Framework: A framework is built on top of a programming language to make certain aspects of it easier. It's always a good idea to learn the programming language a framework is built on before learning the framework. Examples include React and Angular for JavaScript, Ruby on Rails, and Django for Python.

Now, on to the hot takes... 🔥

Define your goal

This is probably the single most important piece of advice I can give. Does it sound like some self-help guru's instagram post? Yes it does. Does it work? Also yes.

There is a reason you want to learn to code. Maybe you want to make more money, or just get a job that doesn't require working on holidays and offers healthcare (if you're in the U.S.). Whatever your reason, ask yourself, "How will that make me feel? How will it make my life better?" That's your real reason. It might be freedom from debt, more time to spend with family, or the knowledge that you've created a tool that will help people.

Ask yourself those questions, and write down your answer. Put it on a sticky note on your desk, set a daily reminder in your calendar, or even write it on your mirror (I actually did this!)

Life is hard, and distractions and obstacles will come up while you're learning to code. And coding is hard; you will get stuck and frustrated. But if you are having a bad day and you see the words you wrote, they will remind you of why you are working so hard. That makes it a lot easier to keep going.

Identify your priorities

There are a ton of resources online to teach code. It can be hard to know which ones are trustworthy, up-to-date, and most of all which ones you will enjoy.

Take some time to figure out what it is you are looking for in a learning resource. Here are some ideas:

Does it need to be free? Or do you have a budget you're willing to spend?
Is accountability important to you? Do you feel comfortable learning on your own, or do you want a community of learners to support you? Or would you benefit from an experienced mentor?
What delivery method do you prefer? Some folks love video walkthroughs and code-alongs, while others prefer just reading. Likewise, do you prefer tutorials or reading through documentation?

One thing I would recommend is to always start with free resources! Make sure you enjoy coding, enjoy the new language or framework you're learning, and enjoy the teacher. Don't over-commit any of your hard-earned cash.

I have another post with some great, free resources!

Learn what to learn

Look back at your goal - chances are, programming is a means to that end. You don't have to become any specific type of developer to make your goal a reality. That's freeing, empowering, and scary - how do you know what you should be studying?

Sometimes people complain about classes they had to take in college that didn't have any impact on their careers. You don't want to waste your time like this when you're learning to code! There are tons of programming languages you could learn, but guessing at which one is best could end up a frustrating waste of time.

Only you can figure out what type of work you will like the best. But once you have figured it out, you'll know which programming languages actually matter to you. If you want to be a data scientist, you'll learn Python or R. If you want to build websites, start with HTML and CSS, then learn JavaScript, and figure out if you like the frontend or backend better.

No matter what you want to do, figure out what your next job should be. Then learn the programming languages it requires.

Find the fundamentals

That last piece of advice I gave you? About finding the language you need and getting started? There is one caveat...

Learn the fundamentals first. Loops, conditionals, variables, data types, and objects - these are an essential part of every programming language. It's important to understand these before you dive in to a framework.

You'll probably learn those fundamentals while you learn your first programming language. But be sure you learn a language first and master the fundamentals, especially before picking up a framework. You'll save yourself a lot of headaches, and be more likely to ace those interview code challenges.

Cut the chatter

There are tons of programming languages and frameworks, dozens of specialties and niches, and a lot to learn even to publish a website. This ties in to the last piece of advice: figure out what you need to learn, and zero in on it. Take it in pieces. Don't try to learn everything all at once. The siren call of becoming a 'full-stack' developer may be appealing, but trying to learn too many disparate things can lead to burnout.

But past making sure you don't get distracted by the latest and greatest framework, remember that it's OK to admit you don't know something! Whether that's how to write an API, how to use CSS Grid, or what the heck a deployment pipeline looks like, remember that nobody knows everything, and everyone was a beginner once.

Make it fun

No matter what you're learning and how you're learning it, make sure you're having fun. This is the best way to ensure you stick with it, and to help you deal with the inevitable setbacks.

The easiest way to keep your learning fun is to center each learning project on something you love! For instance, if I were working through a tutorial that walked through creating a movie search tool, I might want to create a Pokémon search tool. I would write my code with the same structure as the tutorial, but use a different data source and change the variable names.

Taking this approach will help you have fun while you're coding. Plus, your portfolio will end up having a lot more personality!

Use scratch paper

Remember that tests in math class were always easier when you were allowed scratch paper? The same is true when you're coding.

That might mean drawing some boxes for your layout before you start writing CSS. Or it could mean listing out each problem you need to solve (and breaking it down into manageable pieces). For most developers, it also means writing pseudocode. Whether you prefer actual paper, an app, or just your code editor, be sure to map your route before you get started.

Messing up is fine

Let's face it: everyone makes mistakes. Ask any experienced dev you admire (if they deny it, they're probably not someone you should admire). But failure can be demoralizing, especially when you're just getting started.

Especially if you're a career changer, it can be hard to get back in a beginner mindset and let go of the feeling of mastery you had over your old career field.

There isn't any great advice or secret wisdom I can offer to help you get past your frustrations and struggles. Just remember that every failure is an opportunity to learn. Also, read the error messages, they can be helpful! (Seriously, I didn't do that at first because I was too frustrated!)

Know when to take a break

So, you ran into a problem. You're getting an error and you don't know what's wrong! That's OK.

Give yourself time to struggle and try to work through the problem on your own - try stepping away and doing something to relax. It's amazing how much this can help. Take a bath and get those #showerthoughts, cook yourself a nice meal, or exercise. Chances are you'll come back to your computer, sit down, and find a solution much faster.

Remember that a well-rested brain is a smarter brain. Food is fuel, and eating well can help you code well. Coding take a lot of mental energy, but physical aches and pains can create creaky code - get up and move around.

Know when to ask for help

It can be rewarding to figure out a problem on your own, and it can be beneficial to your learning. But sometimes you don't have the context you need, or a problem isn't worth spending a whole day on! If you're really stuck, admit it, and get some help.

You might be able to Google a solution! But if you try a few things that only seem to create more problems, you may need to find a different helpline.
Hit the forums! The right forum depends on what you're learning, but some favorites include Dev.to (try using the #help or #explainlikeimfive tags), CodeNewbie, and freeCodeCamp.org
If you're lucky enough to have real-life friends in your hometown that know code, don't hesitate to ask them! It can be easy to think you'd be a burden or be embarrassed, but they'll just be glad to help! Plus, you'll probably make them feel super smart - always a good friendship move!

Remember that your story is not someone else's story

It's easy to get discouraged when you see blog posts titled, "How I became a full-stack developer and started making 6 figures in only 3 months!!!!!" But it is usually pretty clear that those people had a lot of additional background, resources, and support to make those incredible things happen.

Your story is not like anyone else's. You have unique challenges, constraints, and opportunities. Don't hold yourself to someone else's standards: make your own.

Share your success

Learning to code is hard, and teaching yourself online is even harder. You should be proud of your dedication and hard work! Even 'small' wins are wins, and deserve to be celebrated.

Tweet, post on your Instagram story, or whatever you like best! Let people will celebrate with you. If you get any hate, don't hesitate: smash that block button and keep coding.

Thanks so much for reading this far! No matter where you are on your coding journey, I salute you - keep up the awesome work!

Top free resources for new (and forgetful) devs

Kat Tow — Mon, 20 Jan 2020 19:37:35 +0000

If you're learning to code, this list is for you! If your brain is full of other important things, this list is also for you!

These are some resources that I used in my journey as a self-taught dev, and many of them are tools I still go back and refer to. Every resource on this list is free - none of these require you to spend a penny to get quality content, and none of them are affiliate links.

Getting Started

There are tons of 'learn to code' sites - and most of them will give you the bare bones before asking you to 'upgrade' and for a pretty penny. You don't need to spend a dime.

freeCodeCamp.org is a nonprofit that will teach you everything from HTML and CSS to Node.js, testing, and data science. Yes, seriously, a nonprofit. This was the number one resource I used when I first started. Their web app has interactive coding lessons, where you learn and practice on the same screen. The curriculum includes 'final projects' for each section that will build your portfolio automatically. If you're a new developer, or if you are a back-/front-end dev learning the other side, this is a great resource. Email or integration sign-up required.
CodeNewbie Podcast and Syntax are podcasts. Why podcasts? They're a great way to keep learning while you're commuting or doing laundry, letting you fit more development knowledge into your day. Podcasts can be much more subject to personal taste (Do you like the hosts? Do you prefer interview formats or group chats?) but these are a couple of my favorites. No signup required, unless it is for a podcatching app.
Intro to GitHub is an interactive walkthrough for those new to Git. Or if you've got the basics but forget the details (it me) you can Try Git and find handbooks and cheat sheets. A GitHub account is required.

CSS

CSS... even once you've grasped the basics, CSS can leave some devs scratching their heads. That's OK - these fun tools are here for you.

Flexbox Froggy teaches you flexbox with this precious hoppy friend. No signup required.
Grid Garden is deeply satisfying if you love grids and/or gardens. Even if you don't, you'll learn a ton about the CSS Grid spec. No signup required.

Make it pretty

You've got a website or app, and maybe some good responsive layouts... but it's missing that pizazz and you can't spend hundreds of dollars on professional photography and graphic design.

Unsplash has a huge database of totally free professional photography - just credit the creator! No signup required.
FontAwesome is not just a font anymore. Icon fonts are not a great choice, but you can still access hundreds of free icons as downloadable SVGs. In a digital ocean swimming with paid icon sets that don't have everything you need, this is a valid choice - for prototyping or production. No signup required.

JavaScript

Before you learn a framework, it's a good idea to get the basics down.

freecodecamp.org is once again a great tool - whether you want to jump to the JavaScript section of the tutorials or practice coding exercises. Email or integration sign-up required.
JavaScript30 is an awesome, totally free 30-day JavaScript course - but of course you can take it at your own pace, or just do the exercises where you want extra practice. Plus, most exercises end up with a small project you can add to your portfolio. Email sign-up required.
Brian Leroux's WTFJS video is not a top-tier learning resource, but it is a lot of fun. No signup required.

Accessibility

This is probably my favorite thing to talk about, especially if you catch me IRL. I could write a post just full of accessibility (or a11y) resources (hmm... maybe I should! Let me know in the comments!) but here's just a few favorites.

Inclusive Design Principles is a collection of high-level principles for creating broadly inclusive designs. Read this before you even start coding that new project! No signup required.
Deque's Accessibility Heuristics offers a clear framework for evaluating your designs for accessibility. Email signup required.
The A11y Project is a community-driven resource to help make web accessibility more understandable. No signup required.

Computer Science

If you've started writing some code, you've probably realized just how little you actually understand. This is an essential part of every dev journey. If you want to learn the basics of computer science without having to spend a ton of cash on a college course, you're in luck.

CS50 is Harvard University's free, totally online course on edX. You can enroll for free (you'll be asked if you want to pay for a certificate, but you can skip it and just take the course!) The course is made up of recorded lectures (they're really good ones) plus smaller, more focused videos on each topic covered. Plus, the course includes optional homework/projects that you can submit and have tested. Email signup required.
BaseCS is an adorable, illustrated collection of articles on comp sci essentials. If you prefer, you can also watch videos or listen to the podcast! No signup required.

Those are just a few of my favorite tools for new developers and forgetful ones (like me!). If you have any FREE favorites, please share them in the comments!