Forem: Rachel Leggett

Just F*ing Ship It Challenge 2020 - My Project Recap

Rachel Leggett — Mon, 07 Dec 2020 02:59:50 +0000

The Challenge

Each year in October, Women Make holds a month-long, non-competitive hackathon called Just F*ing Ship It. The goal is to build and launch something over the course of a month.

2020 was the third year of the challenge and my first year participating. Here's what I did and what I learned!

What I Built

Validating my Idea

At first, I wanted to do something simple and small, like redesigning this blog. But then I got an idea that I just couldn't get out of my head and bought a domain, as you do. 😂

I spend much of my spare time designing knitting patterns, which I have been doing since 2015. I have learned a lot about knitting pattern design from resources dispersed all across the web during that time.

I had recently had a few conversations with other knitters who wanted to start designing, but didn't know how to start. Those conversations got me thinking that a one-stop resource website could be helpful.

I posted a poll on Instagram asking if folks would be interested in a website that collected resources on how to design knitting and crochet patterns and got enough interest that I decided to go for it.

I bought startdesigningtoday.com (and startdesigning.today for good measure), created a new ConvertKit account, and threw up a quick landing page with a form for interested folks to submit their email address.

I posted about it on Instagram and got some interest right away! Nine aspiring designers signed up for my interest list in the first two days, with a few more trickling in throughout the month.

The Scope

Since the challenge only lasted one month and I work a full-time job, I needed to make sure to scope the project to something I could actually build and ship in a month, while working on it just a few hours a week.

I have big ideas around building a whole Start Designing Today ecosystem (like an email course and community), but for this challenge, I decided to focus on the website. Even if I never get around to building any of the other stuff, I think the website provides a good amount of value on its own.

I wrote out a very brief list of functional requirements for the website:

The website should have resources pages.
Users should be able to search resources.
Users should be able to filter resources by category.
The website should have a blog section with original articles.
The website should show featured articles.
Users should be able to sign up for a newsletter.
Users should be able to submit a resource.

In the end, I decided to reduce the scope even further to ship an MVP in time. I only included these four functional requirements in the website I launched on November 1:

The website should have resources pages.
Users should be able to filter resources by category.
The website should have a blog section with original articles.
Users should be able to sign up for a newsletter.

Screenshots

For larger screenshots, visit the original article on my blog.

Here are some screenshots of the main features of the site, or you can click here to browse it yourself. These screenshots are taken of the desktop site--if you are reading this on your phone, visiting the live site will be a better, responsive experience.

If you aren't interested in the appearance and structure of the site, click here to skip ahead to the technical implementation details! I won't be offended. 😊

I went with an upside-down homepage approach to prioritize newsletter signups. I didn't want to bury the newsletter call to action at the bottom of the page where visitors might not see it.

Below the header, the homepage prompts visitors to select which stage of the design process they are looking for help with. These are the resource categories I mentioned in my functional requirements.

When a user clicks on a resource category, they come to a page with subcategories/topics across the top that they can click to view resources about that topic. Below is an example of a resource page, Submitting to Publishers.

There are also blog, about, and contact pages, but there's nothing particularly interesting and screenshot-worthy going on there. 😂

The Tech and Tools I Used

Front End: Gatsby

I used Gatsby for the front end. I already had some limited experience with Gatsby from building my personal site and customizing this blog, but not really enough to build Start Designing Today.

However, Wes Bos's Gatsby course, which I had been looking forward to for a while, came out around the start of the challenge. The timing was perfect for me to use this project as a tool to practice what I learned.

To be honest, I'm still only about halfway through the course! Once I learned everything I needed for Start Designing Today, I stopped so I could get going on building the site. I'll get back to it sometime soon, I promise!

No-Code Back End: Airtable

I didn't want to build a custom backend for this project, but I didn't need a full CMS either. I decided to go with Airtable, which is a pretty sweet no-code application tool.

I used it to build a simple relational database with just three tables: Parent Categories, Categories, and Links.

I used the gatsby-source-airtable plugin to get the data out of Airtable and into my Gatsby site. This post on building a custom CMS with Airtable and Gatsby was really helpful for getting up and running.

Hosting: Netlify

I use Netlify for hosting whenever I can these days. Since Start Designing Today is a static site, Netlify is perfect for it.

Whenever I add new data to Airtable, I just pop on over to Netlify and trigger a new deploy. And when I update my code and push it to GitHub, a new deploy builds automatically. 😊

Newsletter: ConvertKit

I'm using the free tier of ConvertKit for the newsletter, for now. I'm thinking about doing a pattern design email course in 2021. If I do that, I might upgrade to a paid plan so I can have access to automations.

What I Learned and Other Takeaways

First things first: I learned I don't want to do anything every day for a month if it isn't eating, sleeping, or knitting. 😂 I set out to work on this every day in October, but after about two weeks, I couldn't keep up the pace anymore. I needed breaks and took several, some multiple days long. I'm really glad I went with a limited MVP scope for this project so I could comfortably take breaks and still ship on time without stressing.

I found it incredibly helpful to have a community of people doing this challenge at the same time. I doubt I would have built and shipped this website in a month if it wasn't for the amazing Women Make community.

Announcing the site at the start of the challenge also helped me stay accountable because I knew there were real people excited about it and waiting for it. That helped me avoid the trap of finishing the first 80%, which is usually the most fun part, and then never finishing that last 20% and getting it out the door.

Would I Do it Again?

I had a blast participating in the Just F*ing Ship It challenge this year and I definitely think it will become an annual thing for me, but I probably won't try to take a completely new project from start to MVP launch next year. Even though I did take days off, I was very ready to be done by the end.

Maybe next year I'll tackle that blog redesign, instead. 🤷‍♀️

How It's Going Now

Since launching, I started sending the weekly Start Designing Today newsletter. As of this writing on December 5, 2020, my little email list has grown slightly to 16 subscribers. I have sent four newsletters with open rates between 60% and 85% and no unsubscribes yet!

SEO

A few weeks after launch, I signed up for a free Ahrefs Webmaster Tools account and found out that I had really f*ed up my SEO by accidentally having redirect chains for every page! (This is bad because Google won't index pages that look like they have moved.)

It turns out it's a really bad idea to forget the trailing slash in links and even worse to generate page slugs without trailing slashes. If I referenced a page with a trailing slash, it would redirect to that same page without a trailing slash, and then redirect AGAIN to that page with a trailing slash. D'oh.

I updated how I was generating page URLs in my gatsby-node.js file and generated them with a trailing slash from the start. I also checked all my internal links and added trailing slashes. That seems to have solved the problem.

I referenced this article by Maxime Heckel on SEO mistakes he has made with his Gatsby blog and how to fix them several times throughout the process of debugging that redirect chain issue. It's definitely worth checking out.

Real Results

So far, I have received one real testimonial that the site is helpful! A knitter DMed me on Instagram to tell me that she was designing her first sweater thanks to Start Designing Today! She said "your site is so perfect for finding what I need." I couldn't be happier with that!

What's Next for Start Designing Today

For now, I'm focusing on sending my newsletter consistently, coming up with more topics to write about for the blog, and improving SEO by doing some keyword research and editing copy where it makes sense. I have a couple sites in mind that I would like to compete with for rankings, so I'll be starting there.

In the longer term, I would like to launch an email course to walk folks through the process of designing a pattern, with the goal of having a publication-ready pattern by the end of it.

I also want to explore creating a community for aspiring knit and crochet pattern designers, whether that's something as simple as a Discord server, or something more.

What About You?

Have you launched anything recently? How is it going? I would love to hear about it!

Why You Need to be Doing Manual Accessibility Testing and How to Get Started

Rachel Leggett — Wed, 25 Nov 2020 02:52:52 +0000

How many times have you seen a tweet like this?

Proud to say my website is fully accessible! #a11y

I don't want to diminish the effort it takes to reach a perfect accessibility score on Lighthouse. That is a great first step and feel free to pat yourself on the back about it!

However, the important thing to know is that the work does not stop there. A 100 does not mean your site is fully accessible.

Automated testing can only catch about 40-50% of accessibility issues.

Automated testing can only test for programmatic issues, without usability considerations.
What Can you Do?
- Keyboard Testing for Accessibility
  - Remember Your Sighted Keyboard Users
  - How to Get Started with Keyboard Testing
  - Expected Behavior
- Screen Reader Testing for Accessibility
  - Why You Should Test with a Screen Reader
  - Which Screen Readers to Use and How to Use Them
  - Why You Should Also Test on Mobile (If Possible)

Automated testing can only test for programmatic issues, without usability considerations.

Automated tests only work for those things that can be tested programmatically and objectively, such as the existence of alt tags, whether color contrast ratios are high enough, and the existence of form labels.

However, even these things are subjective.

If alt tags are present for all images, the alt tag test will pass, but that doesn't mean the alt text is actually appropriate for those images.

It is extremely difficult to automatically test color contrast for text with a gradient or photograph background.

The form labels that are present might not be appropriate for the fields they are labeling.

These are just a few examples of the many things that still require a human touch to verify accessibility.

What Can You Do?

Fortunately, there are manual web accessibility testing tools readily available and literally at your fingertips!

If you're just getting started with manual accessibility testing, I recommend focusing on:

Keyboard testing.
Screen reader testing.

Keyboard Testing for Accessibility

One key element of web accessibility is that it should be possible to perform every action using only the keyboard.

Keyboard accessibility affects two types of users:

People who cannot physically use a mouse, or who have difficulty using a mouse. This can be due to a permanent, temporary, or situational disability (e.g. a person who experiences hand tremors, or someone holding a baby in their right arm while navigating using a keyboard with their left).
Blind users who can physically use a mouse, but don't because they can't see where the cursor is located.

Remember Your Sighted Keyboard Users

A common mistake--and one I have made myself--is to forget that there are many sighted (i.e. not blind) people who navigate the web using only their keyboard.

It must be possible for both sighted AND non-sighted users to perform all functions using the keyboard.

While a screen reader will announce the element that has focus to a blind user, a sighted user needs to be able to see where their focus is.

The main thing to keep in mind here is that visible focus styles are key. None of that outline: none; crap (without adding other visible styles)!

Click here to read a great blog post from Deque on how to design useful and usable focus indicators.

How to Get Started with Keyboard Testing

Open up your webpage and try to navigate with your keyboard!

The basics of keyboard navigation are:

Use your TAB key to advance focus from item to item on the page.
Use SHIFT + TAB to go backwards on the page.
Use ENTER to activate interactive elements such as links and buttons.
Use arrow keys to move between radio buttons or checkboxes within a group.
Use SPACE to select or deselect a checkbox.

Expected Behavior

You should be able to navigate to and interact with all focusable elements on the page.

Focusable elements are those that are interactive by default, such as links, buttons, and form fields, as well as anything to which you have added tabindex="0" to add it to the logical focus order.

It is NOT normal to be able to focus on non-interactive elements, so don't worry that your focus skips things like paragraphs, lists, images, etc. Don't manually add anything to the focus order unless absolutely necessary.

For more on keyboard testing and expected behavior, check out this article on keyboard accessibility from WebAIM.

Screen Reader Testing for Accessibility

Screen readers are an assistive technology that allow blind users to interact with computers by announcing the elements on the page to the user and allowing the user to navigate through the page with their keyboard.

Why You Should Test with a Screen Reader

It's important to test with a screen reader to truly get a feel for whether your site is accessible to blind users. You should test for two main things:

Are you able to access and interact with all elements of your site using only a keyboard?
Can you understand the interface from the audio alone?

Keyboard operability can vary when navigating with a screen reader activated. For example, I have seen cases where buttons could be activated with the enter key when tabbing through a site without a screen reader turned on, but that could not be activated when using a screen reader.

Since not everyone navigating your site with a keyboard will be using a screen reader, it is still also important to test this without a screen reader, as described above.

In addition, UI elements that make sense visually might need some tweaking to make them understandable to screen reader users. Some common examples of issues that can pop up include:

error messages that aren't programmatically associated with their fields (but appear next to those fields visually),
radio button groups with some hidden buttons that announce the full number of buttons to screen reader users, including the hidden ones,
and help text that is not programmatically associated with what it is trying to help with.

Which Screen Readers to Use and How to Use Them

The three most popular screen readers on the market today are NVDA, JAWS, and VoiceOver (see the WebAIM Screen Reader User Survey conducted in 2019).

VoiceOver comes with all Apple devices by default, so you'll probably be testing with VoiceOver if you have a Mac laptop or desktop.

For Windows, the most popular choices are NVDA and JAWS. JAWS is paid software, but NVDA is free and open source, so it is a good choice to use for testing.

Click here for guides to getting started with each of these screen readers.

Why You Should Also Test on Mobile (If Possible)

In addition to testing on a laptop or desktop computer, I highly recommend testing your website on a mobile device.

The screen readers available for mobile devices vary slightly from their desktop counterparts. I have run into some challenging cases where functionality works with desktop screen readers, but not using a screen reader on a mobile device.

It is important to test on a real device to find these issues, instead of just testing on a narrow browser window or in a device emulator on your desktop.

For mobile testing, the most popular combinations are iOS with VoiceOver and Android with TalkBack.

Click here for a guide to using VoiceOver on iOS.

Click here for a guide to using TalkBack on Android.

Conclusion

Manual testing is key for ensuring your website is accessible. Automated testing is a great way to get started, but it can only test for about half the potential issues.

Adding keyboard testing and screen reader testing to your workflow can have a huge impact on the accessibility of your websites and web apps. Testing with a screen reader can be frustrating at first, but the more you practice, the easier it will become.

Check out these resources (also linked above) for getting started with keyboard and screen reader testing:

Will you be incorporating manual accessibility testing into your workflow? Let me know on Twitter!

How to Give a Talk Without Being an Expert

Rachel Leggett — Wed, 30 Sep 2020 20:26:03 +0000

I post all my articles on my self-hosted blog first: this post first appeared on DevYarns. You might also be interested in my tweets about accessibility, web dev, and probably cats. 💻

I gave my first conference talk in July 2020, which as of this writing was two months ago. I spoke at WPCampus 2020 Online on how to improve your WordPress site's performance (video and transcript now available!), based on a case study of a non-WordPress web app (written in Python and Flask) I had worked on.

In this post, I will discuss:

why you don't need to be an expert,
my experience submitting to WPCampus,
and how I arrived at my final topic.

You Don't Need to Be an Expert

I'm not even sure experts exist.

I'm a firm believer that the smartest people know what they don't know and know how to ask for help instead of trying to learn everything themselves.

The more I learn about a subject, the more I realize there is to know. Learning something new opens the door to five other new things that build on that knowledge.

Through the process of applying, working with the director to fine-tune my topic, and actually writing and giving my talk, I learned that you don't need to be an expert to give a great talk. In fact, I think it's probably better if you aren't!

What to Be Instead

Be passionate! Be curious! Be willing to ask questions and willing to be wrong.

My Experience Submitting to WPCampus

I've only given one talk (plus taught a few knitting classes and sat on a Meetup panel once), so I'm no expert. 😉

I spent a long time worrying about whether I was smart enough to give a talk, whether my topic ideas were interesting enough, whether my ideas were unique enough, and on and on.

WPCampus has a supportive, inclusive, welcoming community of organizers and attendees. I had attended a couple times in the past so I knew what to expect from the conference, which helped me feel comfortable applying.

As a sidenote, I had actually submitted a talk for their 2019 conference, too, which was not accepted. I attended that year and someone else gave a talk that was on a similar topic to what I had proposed, but was all-around better. Honestly, I would have chosen his talk over mine, too.

My original 2020 topic submission was completely different from what I ended up presenting. Like, not even in the same ballpark. The conference director, Rachel Cherry, reached out to tell me that the organizers would like to have me speak, but they didn't think my topic would work for their conference.

She was really helpful in getting me thinking about other potential topics. She asked me a few questions to get my brain working. What excites me? What have I worked on recently?

I submitted some additional ideas and together we decided on the website performance topic. I ended up writing a talk that was 50% a case study of my web app refactor, and 50% how the attendees can apply what I learned to WordPress.

How I Arrived at my Topic

Here's what I did to come up with my final website performance topic.

1. I looked to my experience.

What had I done or learned recently that stood out in my mind from the rest of my daily work?

I had recently refactored a web app to triple its Lighthouse performance score. I learned a lot about performance optimization along the way.

I knew there were lots of people who already knew everything I had learned. I hoped there might be others out there like me who did not and who could benefit from hearing about what I had done.

2. I thought about what my coworkers had expressed interest in.

One of my colleagues in particular was impressed by my work refactoring the web app. He is one of the most encouraging and enthusiastic people I have worked with. His enthusiasm about the project and his curiosity about what I did helped me along the path to creating a talk on the subject.

I hoped others might be as interested as he was.

3. I thought about questions I wanted answered.

I needed to think about how to make this talk appeal to a WordPress audience. There are a couple concerns when working with WordPress that the app refactor didn't address. This meant I had two questions that needed answering in order to make this applicable to WordPress:

How do you optimize images for performance in WordPress?
How can you mitigate the effects of third-party themes and plugins on performance?

4. I did research to answer those questions.

I did not know the answer to either of those questions when I submitted my talk, but I knew I could do some research and find the answers. It actually wasn't until a week or two before giving my talk that I had the answers, or at least my answers.

I spent some time optimizing a WordPress site I own (arbortwist.com--my knitting pattern company), focusing on the above two questions. I learned a lot, plus it had the added benefit of making my site better!

Looking Ahead

I had a great time speaking and I definitely want to do it again. The next time I'm brainstorming talk ideas, I will follow the framework outlined above and ask myself:

What in my experience has been a bit unique or stood out in some way?
What are my coworkers interested in that I have done?
What questions do I have? What do I want to dig into further?
How can I answer those questions?

I am really curious to hear how others come up with talk ideas. Do you do something differently than me? I would love to hear about it!

Five Ways to Write Better Alt Text

Rachel Leggett — Sun, 27 Sep 2020 20:32:42 +0000

This article was originally published on DevYarns. Head over there if you like this post and want to read others like it.

It's easy to write minimally-compliant alt text. Just stick anything at all in there and automated testing tools will be happy. But if you actually care about providing high-quality experiences for blind users (which you should), writing alt text is a lot more challenging.

Today, I'm sharing five tips that should make it a little easier—with practice—to write effective alt text that actually makes sense.

If you aren't a web developer and just want to know how to write better alt text (e.g. for social media), you can skip over the code samples in this article. The rest of it still applies!

In this article:

Don't say "photo", "image," etc.
Focus on the image's purpose.
Use alt="" for decorative images.
Keep it brief.
Don't repeat yourself.

Don't Say "Photo," "Image," Etc.

One of the most common mistakes I have seen is to start your alt text with something like "an image of". This creates a worse experience for screen reader users because screen readers already announce images as such. For example, VoiceOver for macOS reads the alt text first, followed by the word "image."

Take the following possible alt text for a picture of a cat:

Photo of a brown tabby cat curled up on the couch.

The readout from VoiceOver will be something like, "Photo of a brown tabby cat curled up on the couch, image." While technically correct, announcing both "image" and "photo" is redundant and a worse user experience.

Instead, try something like this:

A brown tabby cat curled up on the couch.

Or, in your HTML:

<img src="myCuteCat.jpg" alt="A brown tabby cat curled up on the couch." />

The readout would then be something like, "A brown tabby cat curled up on the couch, image." Much better, don't you think?

Since there is usually an exception to every rule, I would argue that it might be helpful to identify the type of image something is, when it is important to the meaning. For example, if you are sharing a digital illustration of your cat, it might be appropriate to say so in the alt text, as long as the fact that the image is an illustration is relevant to the point you trying to make.

Focus on the Image's Purpose

When composing alt text, it can be tricky to know what to write! You might think you need to describe literally everything in the image, but that's usually not the case.

Instead, consider what the purpose of the image is, in context.

Take the example of this photo of some knitting and a cup of coffee I tweeted the other day:

This was the content of my tweet:

Today's up early, before work activity is knitting! I finished some short sleeves for a top and now I'm going to wind yarn for a hat.

P.S. I really miss travel. 😭

I added the following alt text to my image:

Two flat pieces of knitting in front of a full coffee mug. The mug is the Vancouver edition of the Starbucks 'You Are Here' collection.

In this case, my intent in sharing the image was to show off my knitting project and to convey that I miss travel. I chose the Vancouver mug that morning because it was from a place I had visited. I described the coffee mug in my alt text because it helped convey that I miss traveling.

Let's consider another potential purpose for this image!

What if this was a promotional photo targetting knitters and advertising the hand-dyed yarn used in the project? The alt text might look something like this:

A stockinette knitting project worked using a mostly pink variegated colorway with blue, darker pink, and purple speckles distributed evenly.

Notice that I didn't even mention the coffee mug because it has nothing to do with the photo's purpose.

Icons

I want to call out icons specifically because I've seen their alt text done wrong many times, specifically when used as links.

Imagine that I have an image of a Twitter logo that I want to use as a link to my Twitter profile. You might think I should do something like this, where the image alt text is "Twitter logo":

<a href="https://twitter.com/rleggos">
  <img src="twitterLogo.png" alt="Twitter logo" />
</a>

However, when a screen reader announces this, the readout will be something like "link, Twitter logo, image." How is a blind user supposed to know where this link goes?

In a case like this, it is best to think about the alt text as link text. If I was making a text link to my Twitter profile, I wouldn't write "Twitter logo". Instead, I might write something like "my Twitter".

So, better alt text might be "my Twitter", as follows:

<a href="https://twitter.com/rleggos">
  <img src="twitterLogo.png" alt="my Twitter" />
</a>

The same principle applies if you are using icon fonts and labeling them with aria-label, but that goes beyond the scope of this article.

Use alt="" for Decorative Images

The header image at the top of this post is a good example of a decorative image. It does not add any meaning to this post and it isn't necessary to understand this content. If it wasn't there, it wouldn't matter.

The best way to handle alt text for decorative images is to include the alt attribute, but leave it blank, as in the following:

<img src="decorativeImageFileName.png" alt="" />

You might think you could just leave off the alt attribute altogether, but that would result in a worse experience for screen reader users. When the alt attribute is missing, most screen readers will read out the name of the image file. Users might be left wondering what they are missing.

Including this alt attribute, but leaving it blank, lets screen readers know that the image is decorative and should be skipped over when reading the page. A screen reader won't tell the user anything about the image at all.

Keep it Brief

There is no technical limitation on the length of alt text. However, the generally accepted purpose of alt text is to provide a short description, so it's best to keep it brief.

Since alt text is meant to be short, screen readers don't allow users to pause alt text and resume it where they left off. This means long alt text descriptions are bad for usability.

There is no consensus for the optimal length of alt text, but a variety of online sources suggest lengths between 80 and 150 characters.

Deque, the creator of axe, one of today's most widely used accessibility testing tools, recommends limiting alt text to about 150 characters. They suggest thinking of it like an old-school 140-character tweet, if you need help conceptualizing that length.

Use aria-describedby If You Need a Longer Description

Sometimes, it might not be possible to fully describe your image in a short alt text description. If this is the case, you can write a longer description elsewhere in the HTML and associate it with the image using aria-describedby.

For a practical example of this, consider this screenshot I included in my WPCampus 2020 Online talk on website performance:

If I'm writing content that includes this screenshot and it's important that folks can read all the text contained in the screenshot, I'm going to need some alternative text. However, I shouldn't just shove everything into the alt attribute on the image because it will be too long. Instead, I might use an unordered list to convey the information and associate it with the image using aria-describedby. Here's what that markup could look like:

<img
  src="performanceScoreScreenshot.png"
  alt="Results of a Lighthouse performance audit."
  aria-describedby="audit-results"
/>

<ul id="audit-results">
  <li>Overall score: 63 out of 100.</li>
  <li>First contentful paint: 3.9 seconds.</li>
  <li>Speed index: 3.9 seconds.</li>
  <li>Largest contentful paint: 5.5 seconds.</li>
  <li>Time to interactive: 5.2 seconds.</li>
  <li>Total blocking time: 170 milliseconds.</li>
  <li>Cumulative layout shift: 0.308.</li>
</ul>

Now, my audit-results list will be associated with my image and screen readers will read that list as an additional description, after announcing the "Results of a Lighthouse performance audit" alt text.

This solution is also visible to sighted users, of course. There are ways to visually hide content while keeping it available to screen readers, such as those described by The A11y Project in their article on hiding content.

However, in this particular case, I would recommend keeping the text description available to visual users. Plenty of users do things like zoom to view content, or use assistive technology to change the color and contrast levels of content to accomodate visual disabilities. To best serve these types of users, whenever you include an image with text on it, it is a great idea to include a text alternative that is visible to sighted users, too.

Important note: You might be tempted to use aria-labelledby instead, but don't! Most screen readers give precedence to aria-labelledby over alt, meaning they will read aria-labelledby instead of the alt text, not in addition to it.

Don't Repeat Yourself

This commonly cited programming advice is good for alt text, too.

Let's revisit my knitting and coffee mug photo tweet from above.

Tweet text:

Today's up early, before work activity is knitting! I finished some short sleeves for a top and now I'm going to wind yarn for a hat.

P.S. I really miss travel. 😭

Alt text:

Two flat pieces of knitting in front of a full coffee mug. The mug is the Vancouver edition of the Starbucks 'You Are Here' collection.

Notice that I did not describe the knitting in the alt text, other than saying that the knitting is flat (as opposed to being worked in the round--a distinction that will make sense to any knitters who might come across my tweet).

My tweet already says the project is a pair of short sleeves so there is no need to repeat that in the alt text. In fact, it would be a worse user experience if a screen reader announced that same information to the user twice.

Conclusion

Remember these five tips the next time you share an image online.

Don't say "photo", "image," etc.
Focus on the image's purpose.
Use alt="" for decorative images.
Keep it brief.
Don't repeat yourself.

Even if you're just tweeting or writing an Instagram caption, not building a website, these tips apply. If we all practice writing quality alt text, we can create a more inclusive web together. ❤️

How to Make Emojis Accessible in HTML

Rachel Leggett — Fri, 25 Sep 2020 21:15:52 +0000

This post originally appeared on my blog, DevYarns, in August 2020. I post all my writing there first. Make sure to subscribe to my DevYarns newsletter for all my latest tips--emails no more than once a week.

Follow me on Twitter for accessibility tips and cats.

When I recently rewrote the bio on my personal website, I added some emojis to add some personality and visual interest.

To make sure screen readers could read the emojis in my bio in a way that made sense, I did the following three things:

I wrapped each emoji in a .
I added role="img" to each .
I added a brief but descriptive aria-label to each .

So, to insert my waving emoji, I used the following code:

<span role="img" aria-label="hand waving">👋</span>

Let's break it down.

The span Element

 is an inline HTML element that can be used to format the inline content it surrounds. Since  doesn't inherently represent any type of content—as opposed to something like , which specifies emphasis—it is the perfect blank canvas for telling a screen reader what it will see inside.

Since  isn't self-closing, we'll have to remember to add a closing  tag after our emoji.

We'll mark up our  to tell screen readers how to interpret it.

The role="img" Attribute

The role HTML attribute defines a user interface element. That is, what type of element should the screen reader tell the user they have encountered?

Here, we use the img role to tell the screen reader that the emoji should be treated as an image.

The aria-label Attribute

The aria-label attribute defines some text that labels the current element. In other words, it tells the screen reader how to describe that element to the user.

It is important to use a descriptive and meaningful label here. I chose "hand waving" for my emoji because it is brief and describes my meaning.

What it Sounds Like When a Screen Reader Reads This

When you put it all together, the screen reader will read your aria-label and identify the role of the content to the user.

Take the following HTML as an example:

<p>
  Hi, I'm Rachel!
  <span role="img" aria-label="hand waving">
    👋
  </span>
</p>

VoiceOver, the screen reader software that comes with macOS, reads that as follows: "Hi, I'm Rachel! Hand waving, image."

What if We Leave Off the Role and/or the Label?

VoiceOver happens to read emojis using their names, so it isn't the worst. With all my extra markup removed, it reads the line as follows: "Hi, I'm Rachel! Waving hand."

However, my goal is to give blind and visually impaired users the best possible experience. I prefer to indicate to the user that this is an image and I have not in fact written "waving hand," which could mean something else. I also don't want to assume that every screen reader interprets emojis without roles and labels the same way.

The Emojipedia page on the waving hand emoji says it is known by five other names, including "goodbye," which is the opposite of my meaning! I don't want to hope the user's screen reader reads the right description that makes sense in the context. Specifying a label guarantees I am conveying what I actually mean.

Forem: Rachel Leggett

Just F*ing Ship It Challenge 2020 - My Project Recap

The Challenge

In This Article

What I Built

Validating my Idea

The Scope

Screenshots

The Tech and Tools I Used

Front End: Gatsby

No-Code Back End: Airtable

Hosting: Netlify

Newsletter: ConvertKit

What I Learned and Other Takeaways

Would I Do it Again?

How It's Going Now

Newsletter

SEO

Real Results

What's Next for Start Designing Today

What About You?

Why You Need to be Doing Manual Accessibility Testing and How to Get Started

In This Article

Automated testing can only test for programmatic issues, without usability considerations.

What Can You Do?

Keyboard Testing for Accessibility

Remember Your Sighted Keyboard Users

How to Get Started with Keyboard Testing

Expected Behavior

Screen Reader Testing for Accessibility

Why You Should Test with a Screen Reader

Which Screen Readers to Use and How to Use Them

Why You Should Also Test on Mobile (If Possible)

Conclusion

How to Give a Talk Without Being an Expert

You Don't Need to Be an Expert

What to Be Instead

My Experience Submitting to WPCampus

How I Arrived at my Topic

1. I looked to my experience.

2. I thought about what my coworkers had expressed interest in.

3. I thought about questions I wanted answered.

4. I did research to answer those questions.

Looking Ahead

Five Ways to Write Better Alt Text

Don't Say "Photo," "Image," Etc.

Focus on the Image's Purpose

Icons

Use alt="" for Decorative Images

Keep it Brief

Use aria-describedby If You Need a Longer Description

Don't Repeat Yourself

Conclusion

Further Reading

How to Make Emojis Accessible in HTML

The span Element

The role="img" Attribute

The aria-label Attribute

What it Sounds Like When a Screen Reader Reads This

What if We Leave Off the Role and/or the Label?

Recommended Reading by a Screen Reader User