DEV Community: Viktor Köves

User Testing for Better Websites - A Case Study with Decarb My State

Viktor Köves — Wed, 07 Jun 2023 12:39:19 +0000

If you've worked in software development or design for a while, you have very likely heard about the value of user testing, but you may not have had the opportunity to take advantage of user testing much in your work yet. I want to show you some user testing we did for DecarbMyState.com, and how it helped make sure our climate site was both easy to use but also left our users with the positive emotional impact we were striving for.

Why We Ran User Testing

Let's start with some background: at Chi Hack Night back in December 2022 we had been working on a climate site for several months and wanted to make sure that it achieved all of our goals. For us these were:

Have the site be functional and easy to use
Help users understand their state's emissions and sources
Making users feel optimistic about climate solutions

By the time we were considering user testing we had a very functional site with a lot of useful information and a pretty polished UI, so we were hoping user testing would validate those opinions and show we were meeting our goals. Instead, our user testing surprised us by revealing some huge gaps in our site.

Our User Test Setup

To create our user testing setup, we wanted to simulate how we felt most people would approach our site, which was starting from the homepage without any specific context or background information on our site. This was meant to match the experience if someone, say, saw a sticker with our URL on it and chose to visit the site.

To try and imitate this type of interaction, we gave users some basic instructions describing our user interview, including asking them to think out loud and letting them know we wouldn't answer any questions, but offered no information about our site or any specific tasks. We also specifically made sure to recruit folks who were coming to their first Chi Hack Night, and thus had never heard about our project before. By telling our testers very little about the site and setting no specific goals for them (since Decarb My State is an informational site) we hoped to get a better understanding of how easy our site was to use, what users were taking away from the site, and how the site made them feel.

The Actual Tests

We ran four user tests with our first version of the site, and we learned a lot right away. First and foremost, we learned that a shocking 50% (two of four) of testers never got to our largest page - the state details page. To provide more context, Decarb My State has a homepage with a map that
links to our largest pages, which provide details on every single state, including breakdowns of where their emissions come from by category and very specific solutions to each category of emissions. In the header we have our Take Action page (which we link at the end of each state's details page) and some supplemental pages like our About page and FAQ, but that one half of users essentially only experienced the least important pages on our website.

Improving Navigation Clarity

This was a huge miss, but it turns out there was a very simple explanation. Here's what the Decarb My State homepage looked like if you hovered over the state of Illinois on the map:

The users in our tests were hovering over a state they were interested in, and then saw some emissions statistics. This gave them a misconception about our site, that the map UI was a data visualization, and not a navigation tool. Users see maps with data tooltips all the time across the web, and with no other prompting, they thought hovering was the only available interaction.

We made the decision that a simple wording change to add an action verb to the tooltip would help users understand the map navigation UI. Here's what it looked like after our change:

There are a few different changes here that we stacked to make sure users understood the map was more interactive, since this was their entry point to our core state pages:

We updated the heading above to say "Choose your state", making it clear (if users read it) the map was actually a call to action (with "choose" implying clicking)
We added the phrase "View Details" below the tooltip
We underlined the "View Details" text to add to the feeling that the user was interfacing with a link. Although this text itself isn't technically a link, the tooltip ignores pointer events, so clicking it will click through to the hovered state below it.

We ran some user tests after this change and found, as hoped, users immediately understood the homepage map was a navigation tool and navigated to the state details page that we had invested most of our time in.

Encouraging Optimism With Our Wording

Our second big opportunity for improvement came from some of the questions we asked to close out our
user interviews. For our site, we asked the following questions after each session was done:

What takeaways do you have from this site?
How did this website make you feel?
On a scale of 1 to 10, how likely are you to take any of the actions you saw on the website? Why?
What would you need to increase this number?

We saw positive results on most of the points, but saw a wide disparity on point #2. Although some of our users felt optimistic (often including those who never saw the state details pages and only saw the Take Action page), many actually said they felt more pessimistic worried after seeing the state details page than they had before. There were a few factors playing into this, including seeing low progress on some of our state specific sector charts (like % of cars on the road that are electric), but there was one big one - the last section of the state details page.

For Decarb My State, we break down emissions into four sections: buildings, transport, power, and other. Decarb My State is a very narrowly focused site that in particular is pitching the merits of clean electrification (moving fossil fuel uses to electricity, then creating clean electricity via
renewables) but this means that although we have a lot to say in the first three sections, the last section is not really related to the main pitch of our site. To that end, here's what our "Other" section used to look like before:

This text was fine from a factual perspective, since it correctly communicates what the other category includes and a few potential solutions, but it completely fails from an emotional perspective, which is crucial especially for the second to last section on a page. Our intent was
to communicate to our users that we were aware that the "Other" section was a significant proportion of emissions and provide some ideas while avoiding having to go into too much detail. However, our test users actually saw our lack of more action items as a sign this section was just not fixable because we didn't have as much to say on it, and we didn't explain why.

To that end, we spent a lot of time thinking through how we could tweak this section, to make sure our users would understand both that there were solutions but also why we wouldn't go into more detail about this set of emissions. To this end, we ended up changing this section like so:

Similar to last time, there's a confluence of changes here to make sure we fully address the
problem we saw in user testing. In particular:

We added more solutions to give people more of a sense of the existing ideas to address these emissions
We added a note at the end of this section explaining why we weren't going into as much detail on this section, which was because it isn't related to clean electrification and requires a variety of smaller solutions rather than large but easy to explain infrastructure swaps
We increased emphasis on the solutions by adding emojis and increasing font size, so we were certain users saw the proposals and not just a short section listing the emissions sources.

In our following rounds of user testing we consistently found users coming away from our site more optimistic, matching our goals and indicating the changes to the "Other" section had the intended effect.

Closing Thoughts

We made lots of other tweaks to Decarb My State, including a next year goal for progress graphs, clearer graph labels, and splitting apart our Take Action page into clear Renter and Homeowner sections, but these two changes were the most major, and they reflected knowledge we gained directly
from user testing and we would very likely never have gotten otherwise. Like a lot of user testing, it was extremely difficult to watch users struggle to use our site or have it make them feel pessimistic, but that challenge really inspired and motivated us to make our site better, and in
hindsight the new changes absolutely seem like no-brainers. Decarb My State is incalculably better for the changes that we made as a result of this user testing.

To close, I want to first give a thank you to one of the largest voices in this space, Steve Krug. His books, including “Don't Make Me Think”, were fundamental in showing me the value of user testing as well as how to run a good user test, and they contain timeless wisdom that is independent of tech stack or really applies to any application or product, whether on the web or not.

I also want to give a huge thank you both to all of the hard-working folks who have contributed to Decarb My State (including making these changes) and those who volunteered to test our site. Decarb My State is a project coming out of the excellent Chi Hack Night, a local group that has created many instrumental sites to solve Chicago's biggest problems.

How To Make Accessible Content - From Videos, Social Media, and Blog Posts

Viktor Köves — Thu, 14 Jan 2021 01:44:30 +0000

Accessibility isn't just for websites - it's critical for all of your content. Let's walk through some of the most fundamental accessibility principles and how they apply to content like social media posts or articles!

The Fundamental Principles
1. Text Alternatives
2. Contrast
Making Accessible Images
1. Readable Text
2. Alternative (Alt) Text
Making Accessible Videos
1. Contrast in Videos
2. Captioning Videos
3. Captioning Videos for Social Media
4. Transcripts

The Fundamental Principles

Text Alternatives

For any type of content you create, you want to make sure there is some kind of text alternative for users who can't engage with your content in the way you may have initially planned. For example, if you're uploading a podcast or audio clip, it's important to provide a transcript. That way, your audience can engage with your content even if they are deaf, hard of hearing, or just don't want to listen to your content.

Contrast

Whether it's the text in an article, some writing in an image, or even social media icons, you always want to make sure that your foreground and background content are compliant with the WCAG contrast requirements, which you can check using a tool like contrast-ratio.com or with contrast checkers built into your browser or image editor. Now let's actually dive into how these principles apply to a few different types of content.

Making Accessible Images

Readable Text

If you're making images with text in them, you have to ensure any text in your images is compliant with the WCAG contrast guidelines. This is more complex in images than in a basic website, since your text could very well not be on a single color background. In this case, you should sample several spots near your text to ensure that it always has sufficient contrast to the background. Let's take a look at an example.

Let's say we're making a marketing image for a real estate company. We might start with something like this:

You don't need to be an accessibility expert to look at that image and think, "that text is hard to read!" With accessibility tools, though, we can dig into how a contrast failure is specifically the issue here. If we use a color picker tool in an image editor or browser, we can grab the color at one part of the image and compare it to our text color to see if the text is contrast compliant. Let's start with a place that should have decent contrast - the dark brownish gray garage door.

Indeed, if we put the color code of the text and the garage door into contrast-ratio, we can see it's got great contrast!

That doesn't mean we're in the clear yet, though. As our intuition might tell us, there are points in this image where the background is far brighter, and that's going to cause contrast issues with our white text.

If we sample the color of the reflection of the white garage door frame (directly to the left of the letter "T"), we get a drastically different result:

This explains why the image looks unreadable! Although in some places our text is in front of a dark background and is contrast compliant, there are several points in the image where the text is blending into the background.

So how might we fix this? A simple semi-transparent black background will do the trick! Here's my basic correction:

If we now sample that low-contrast area from before (the reflection of the white garage door frame to the left of the "T"), we get a new and improved result:

That's some fantastic contrast! Just by adding a semi-transparent black layer, we darkened the main image enough so that our text has sufficient contrast everywhere, making it fully readable.

Keep in mind, though, that our intuition should not be our only guide here - the original image is a pretty egregious example, but there may well be images that look readable to someone with full color vision, but contrast checks fail. This indicates that users with certain forms of color blindness might have a hard time reading your text - so adjust your colors accordingly!

Alternative (Alt) Text

Of course, it's critical to ensure that text in our images is readable, but this does not do much good for blind users, who will be interacting with your images through a screen reader. To ensure that all of your audience can get the full intent of your images, make sure you use alternative text (alt text for short) to describe your image and any text it contains. If you're a developer making a website from scratch, you can do this with the alt attribute on an img tag, like so:

<img alt="My superb alt text" src="...">

In most content systems like Wordpress, alt text is a separate field that you can provide when you're uploading images. If you do a quick Google search for the system you use and "alt text", it should come up!

To give a specific example, what might be a good alt text for our image above? You might think that the following alt text would be sufficient:

The House of Your Dreams is Available Now!

But this doesn't communicate the image in the background, or the intent that image has! If, for example, the real estate firm serves a specific neighborhood (let's call it Gardenwood) and this house is from that neighborhood, we might want the following alt text:

An idyllic two-story Gardenwood house - The House of Your Dreams is Available Now!

This alt text is a lot better, since it actually describes the background image, and not just the text we've placed on top of it. Of course, if that text is also adjacent to this image (like in the description of an Instagram post), the text becomes redundant, and we can just describe the image.

Keep in mind that alt text is very much context-dependent, as the same image could be totally decorative (which means it should have no alt text) or be critical to understanding your content. I'd encourage you to read WebAIM's article on alt text, which goes into great detail on that subject!

Adding Alternative Text on Social Media

Unfortunately, it can be a bit more difficult to add alt text to images being posted to social media, and their interfaces can change pretty often. Instead of laying out how to do this here, I'll point you to some common social media sites' guides on the subject, and encourage you to do some research to find out! Most social media platforms should explain how to add alt text in their help centers.

Here's a few social media platforms' guides to adding alt text:

Keep in mind that most sites claim they automatically add alt text, and although this is technically true, the alt text is often pretty terrible. I was inspecting some Instagram alt text, and it will usually pull out the text in the image and maybe determine that the photo contains a person. This auto-generated alt text also may switch up the order of your text, making it really confusing! So my main guidance is to always add alt text yourself. You as the creator are going to have the best idea of an image's intent and what it's trying to convey, and no amount of AI can replace that.

Making Accessible Videos

Contrast in Videos

Videos are, fundamentally, moving images, so the principles I gave above for ensuring text that in images is readable also applies to video! If you have text in your videos (which is pretty common for marketing videos), you'll want to make sure that your text is contrast compliant and thus easy to read.

Captioning Videos

Of course, videos are not just moving images - they also feature audio! This ties into one of the most important things when it comes to making accessible video content - captioning. Captioning videos is critical for ensuring that your audience can fully experience your videos, even if they can't hear the video. This doesn't just mean deaf or hard-of-hearing folks either - lots of people watch videos without audio in certain situations!

I know that most folks are aware of captioning, but I wanted to mention that there's a whole lot of expertise that goes into writing great captions, much more than I can cover in this broader article. In particular, I want to highlight this fantastic article on captioning from meryl.net, which dives really deep into the art of making great captions. For the purpose of this broader content-related article, I'll just be covering the basics.

First, add captions to all your videos! If you're not adding captions, you're locking out not only a huge community of deaf and hard-of-hearing users, but also folks who might be trying to watch your videos in public, like someone watching a video on a train. Lots of social media sites now also auto-play videos with the sound off and captions on - so having good, accurate captions can bring in more views!

Second, make sure your captions are clear and comprehensive. If your video has multiple speakers, you want to make sure the captions clearly communicate who is speaking using the caption text or position. You also want to make sure to include elements that aren't speech, like sound effects. If, for example, you're captioning a comedy show, it's really important that you caption when the audience laughs - and maybe even how much! Otherwise, you're losing a lot of the background texture of a video that hearing users take for granted. Let's dive into some examples to learn more about how can we make make excellent captions.

Caption Examples from “The Queen's Gambit”

Caption Example 1 - Music & Sound

This first example is great because it showcases the importance of adding captions for music. The segment before this shot was a montage with a musical backing, and the music fading to silence is important in setting the tone for the scene to come. Like I've mentioned before, captions aren't just for dialog!

Caption Example 2 - Designating Speakers

This example is interesting because it showcases the importance of clearly communicating who is speaking in captions. For those who haven't seen the show, Benny is the character from our first example, while Beth is the protagonist shown in this shot walking out of a building. Here, by starting the caption with "[Benny]", the caption is telling us that Benny is speaking off-screen, rather than Beth, who you'd assume to be speaking.

One extra tidbit here from the meryl.net captions article I brought up before is that it's important for captions to provide equivalent information to what a hearing listener would know. If, for instance, this is the first time we hear Benny speak, we actually shouldn't know that Benny is speaking - we don't have the information to know that! In this case, that wouldn't have a huge impact, but meryl.net cites an example of a character crying off camera - not knowing who is crying is an important part of the suspense, and we want to preserve that for all our audience members!

Caption Example 3 - Sound Effects

This last image is a fantastic example of the importance of captioning sound effects. If you've seen the show, you know that the click of the chess clock is a huge part of the soundscape of the show, especially in quick blitz games like this one. The characters know the game has started because of the first click of the chess clock, so it's important that we also communicate that information in captions! Unfortunately, the rest of this scene doesn't caption each click of the button, which I find to be a bit of an odd choice - especially since there's nobody speaking, and it's an important part of the tension of the scene.

Captioning Videos for Social Media

YouTube, Vimeo, and Other Video Platforms

YouTube and Vimeo are two of the main video sharing platforms, but I would expect that almost any site where users exclusively share video is going to have some form of captioning functionality baked in. With YouTube, you can upload captions from caption files (which is what a professional captioner might provide you with), manually make captions yourself, automatically sync a transcript of a video to make captions, and correct YouTube's auto-captions.

Of course, manually captioning a video yourself is the best bet, but YouTube's automated captions can serve as a good starting point if your audio was recorded in fairly high quality without too much background noise. I'd emphasize, though, automated captions should always be just a starting point - even if they got every word perfectly (which they likely won't), automated captioning systems don't understand speaker changes or grammar, so you'll need to correct those. To learn more, check out the YouTube Help's section on captions and translation, which gives detailed instructions on how you can add captions with the methods I mentioned above.

If you're adding captions on Vimeo, check out the Vimeo Help Center's page on captions and subtitles. Vimeo doesn't have as many tools for helping you generate captions, but it does support caption file uploads.

Instagram, Twitter, and Other Non-Video Platforms

Unfortunately, platforms that aren't as video-focused don't have a great system for building out captions. Instead of the YouTube or Vimeo closed captioning style (which means captions are optional and not baked into the video), these platforms will typically require open captions. This means you should add your captions into your video using a video editor, following all of the typical suggestions around captions. The big benefit to open captions, though, is that you can guarantee the captions are readable, well spaced, and well positioned, since you have full control over them.

Transcripts

As WebAIM's article on captions notes, transcripts are also a helpful alternative for multimedia content, including videos. Why might someone prefer a transcript? To quote that article:

Screen reader users also may also prefer a transcript over real-time audio, since most proficient screen reader users set their assistive technology to read at a rate much faster than natural human speech.

When making transcripts, keep in mind that you should be providing all of the information contained in your video - audio and visual. Here's an example where a transcript that only includes audio might be really confusing:

Speaker: And we're really excited about the price of our widget!

[audience cheers]

Speaker: Isn't that great?!

This transcript is missing some crucial information and makes it hard to tell why the audience is cheering, which would be obvious in the original video. Take a look at an improved transcript, which makes it clear why the audience is cheering:

Speaker: And we're really excited about the price of our widget!

[with a loud swoosh, presentation fades in to show "Starting at $9.99"]

[audience cheers]

Speaker: Isn't that great?!

I am by no means a captioning or transcript expert, though, and if your company makes a lot of video content, hiring a firm to create captions and transcripts for your videos is probably a good idea - they'll have a lot of expertise built up over years of work that you likely won't be able to pick up in just a few hours of research.

This article ended up being a little longer than I planned, but I loved digging into all of the different types of content and how you can ensure that they're accessible to a wide variety of audiences. This is by no means a definitive guide, but I hope that it can get you started on the right path towards making your content more accessible!

This article was originally published on my website. Have an accessibility topic you want to learn more about? Leave a comment!

Chipotle's Ordering Experience is Inaccessible - Here's How to Fix It

Viktor Köves — Mon, 07 Sep 2020 01:51:17 +0000

Recently, I was ordering some delivery from Chipotle, and out of curiosity I tried to tab through the menu, only to discover that I couldn't! Here's some of the issues that make the Chipotle ordering experience inaccessible, and how you can prevent them in your own project.

A quick note before we start: I wrote this article in September of 2020, and Chipotle may well have fixed these issues by the time you're reading this - I certainly hope so! This article is a review of the issues with their site at the time I wrote it, and I hope that by publishing some issues I've found in an actual production website I can show developers what some common accessibility issues are and how to fix them.

The Homepage - Starting Our Order

Let's start at the homepage. Let's say I am a user who is only using a keyboard and I want to order a burrito. Great, it's on the homepage! Let me just press Tab to get over there:

If you can't watch the video above, I tried focusing the order button, but after focus moved naturally through several items in the header, it just jumped to a single terms link after the Order button, and then down to the footer! No matter how I try tabbing around the page, I absolutely cannot focus on either the "Order Now" button or a specific food item.

So why might this be? Unless they are using tabindex="-1" (which removes an element from tab order), the only way this could be is if the site wasn't using semantic HTML. Let's take a look at the "Order Now" button using the Chrome DevTools:

"/>

Oh dear, that "Order Now" button is just a <div>! Thanks to the powers of JavaScript, we can make a <div> interactive, but that doesn't mean we should. There's a lot of inherent functionality that comes with the HTML <button> element, and one of them is that it's tabbable by default and clearly interactive to screen readers. Since this is just a <div>, though, we can't tab to it and a screen reader won't identify this element as a button!

What about the "Burrito" button, is it the same situation there?

wrapped around an "/>

Well sheesh, it looks like it is! Here we've got an <img> element wrapped in a <div> that likely has some JavaScript hooked up to make it interactive. Once again, this doesn't get added to the tab order and isn't clearly interactive to screen readers, so if you're not using a mouse, there's no way for you to even start ordering food from Chipotle! That's a giant accessibility issue if I've ever seen one. 😬

Building Our Burrito

For the purpose of continuing to examine this site, let's say your friend wanted to help you out and linked you directly to the page to build your burrito. Can we place an order from this point forward?

Well, let's start by trying to pick our meat by tabbing into the meat options and see what happens:

Oh dear. In the video, I started in the browser's URL bar, and the only two elements I could focus on were the Chipotle logo and the "Return to Menu" link! Not only could I not focus on any of the protein options, I also couldn't access the links to sign in or view my cart.

Based on our previous experiences on the homepage, I have a feeling why this might be the case, but let's inspect the "Chicken" card with Chrome's DevTools:

elements"/>

And unfortunately, my gut feeling was right - this clickable "Chicken" card is once again just a series of <div> elements, so it's not tabbable and not marked as interactive for screen readers!

To be clear, these are not the only issues on this page. There are issues varying from <img> elements not having alt tags to the page not using headings at all to organize the content. The main issue to me, however, is the complete inability for users who cannot or do not use a mouse to interact with the site, as this completely blocks a huge portion of users from using the site!

How Could We Fix These Issues?

Luckily, fixing these issues is pretty straightforward, and comes down to a few simple steps.

Change interactive elements to be <button> or <a> elements
Test keyboard interaction to ensure that you have clear focus styles
Test with a screen reader to ensure that content is clear

For the first step, we want to make sure that any elements the user can click that redirects them (either to a different page or an anchor on the same page) uses a anchor tag (<a>). This is also simpler to do than using JavaScript for navigation!

If the clickable element is not used for navigation and does something on the same page (like adding a burrito to our cart), we should use a <button>, which makes it clear that the element is interactive and does not perform navigation.

Testing keyboard interaction is fairly simple - try unplugging your mouse and make sure you can use your site using only your keyboard! You should be able to use the Tab key to navigate between interactive elements, and use the Enter or Space key to activate buttons. If you can't reach an interactive element with your keyboard, it's probably not using the right HTML element.

As for ensuring that the content is clear for screen readers, in this case I would suggest adding an empty alt tag (alt="") to all the images of food and ingredients. An empty alt tag marks images as decorative, which is appropriate here, since there's already text below the images indicating what the option is. There's no point saying something like "Photo of a meaty delicious burrito" right before the "Burrito" text!

There are, of course, further accessibility fixes and enhancements we could make to these pages, such as adding headings (so a screen reader user can easily jump to ingredients they care about), fixing modals not trapping focus, and more. These fixes would probably get the site to a point where users just using a keyboard can at least place an order, even if the experience isn't great.

How Could We Have Prevented This?

Accessibility conversations often focus on remediation - bringing inaccessible sites closer towards accessibility. While this is very important, it's also important to consider how you can have a process that ensures accessibility from the very beginning. There are a lot of strategies you can employ, but I'd mainly recommend the following:

Design with people with disabilities - The best way to avoid inaccessible products is to make sure you have a diverse group of people in the room when you're designing! If your designers have a disability of some kind, they'll bring their perspectives and experiences with them in designing a product that'll work for them.
Use inclusive design principles - Microsoft's Inclusive Design page is a great starting point for this, but designing with inclusion and accessibility in mind can really help make sure your product works for everyone. When you explicitly ask questions like "How do users who use a screen reader interact with our product?", you can make sure your engineers consider those scenarios and build for them.
Test with people with disabilities - There are a wide variety of different disabilities folks have, and one of the best ways to make a product accessible is to actually ask those folks to test your product! This also helps to ensure that your product isn't just usable, but actually works really well for users with disabilities. After all, accessibility isn't just a checklist of dos and don'ts - it's a way of ensuring all people can use our products and have a great experience.
Test for accessibility yourself - using automated tools and assistive technology, you can often emulate the experience of a person with disabilities. My article on accessibility testing tools can be a helpful starting point for this.

I hope you enjoyed this article, and that it helps you spot accessibility issues before they get out to your users. If there's an accessibility related topic you would like me to cover or if you have any feedback, leave a comment!

What Do You Wish You Knew About Accessibility?

Viktor Köves — Thu, 28 May 2020 23:57:03 +0000

What do you want to learn about accessibility? I'm going to be working on some new posts, so leave a comment if there's an accessibility topic you want to see me cover - whether's it's a primer on what accessibility is or something really specific, like making an accessible calendar component!

Even if I don't get to writing about the topic you are curious about, you might inspire someone else to write about it.

Creating Accessible Forms: The Basics

Viktor Köves — Sun, 05 Apr 2020 18:27:12 +0000

Forms are one of the biggest ways users interact with websites, and as part of
creating an accessible website, we need to know how to make accessible forms.
In this post I'll show you the fundamentals of how to make a basic form
accessible.

A Faulty Form Example

Let's walk through a pretty common example - a signup form. Here's an example of a signup form that I see around the web:

Now before we continue, can you poke around in this form and see what's wrong with it?

What's Wrong With This Form

From manual testing and some automated tools, you might have noticed a few issues with this form. Here are the main ones:

The inputs aren't properly labeled, making it unclear what each field is to screen reader users
The form's submit button isn't focusable, because it's a <div>. This means keyboard users cannot submit the form
The form has no submit action, so pressing Enter won't submit the form. This makes the form harder to use for keyboard users, on top of issue 2.
None of the fields are marked required in the HTML, which makes it harder for screen reader users to hear what fields need to be filled out

Fixing the Faulty Form

Now that we know what some of the form issues are let's see how we could fix them, issue by issue.

Inputs Aren't Properly Labeled (Text)

First up, the largest issue with this form: the inputs aren't properly labeled!

Before we get into how we can fix this issue, you might be wondering: how could I have caught this issue? There are two answers to that question.

First, you could use a screen reader to go through the form, which would let you hear that a screen reader can't tell what the <input> is for. With ChromeVox, I just hear "edit text" for the email input and "radio button unselected" for the plan radio buttons, which is a huge red flag!

Another you could find this issue is using an accessibility checker like HTML_Codesniffer or Google Chrome's Lighthouse. If you want to learn more about these tools and others like them, check out my previous article on accessibility tools.

Lastly, a good tool to spot check the accessibility of a specific input element is the Accessibility pane in Chrome DevTools, which you can learn about at Google's Page on the DevTools Accessibility pane. Here's a screenshot of what I saw in the Accessibility pane:

Notice how the Accessibility pane shows the name as just "", which shows that the field is not labelled in any way. So how do we fix it?

First, let's take a look at the code at relevant code for the email input:

<div class="label">Email*</div>
<input type="text">

The proper way to mark up this input is to use a <label> instead of a <div> for our "Email" text and add a for attribute to the new <label> that will point to the ID of the input, like so:

<label for="email" class="label">Email*</label>
<input id="email" type="text">

Now if I use a screen reader I properly hear that the input is meant to be an email, and inspecting the element tree with the Accessibility pane shows this as well:

Inputs Aren't Properly Labeled (Radio Buttons)

The previous technique of properly using a <label> with the for attribute mapped to the id of our input field solves part of our problem for radio buttons, but not all of it. Why do I say that?

Even if we properly label our radio button, the label would only be "Free" which does not communicate that this is a selection of plans. To fix this, we can wrap the radio button options in a <fieldset> element and make our "Plan" text a <legend> element, like so:

  <fieldset class="label">
    <legend>Plan*</legend>
    <input id="plan-free" type="radio" name="plan">
    <label for="plan-free">Free</label>

    <input id="plan-pro" type="radio" name="plan">
    <label for="plan-pro">Pro</label>
  </fieldset>

This ensures that screen reader users get informed that the "Free" and "Pro" inputs are related in a group of fields related to picking your plan. Here's a screenshot of the Accessibility pane with these fixes:

Notice that the Accessibility Tree shows that our "Free" input is in a "Plan" group, confirming that we've setup our <fieldset> correctly.

Form Submission

Now to tackle the submit button issue. There's a lot of ways that you could spot this issue, including using your site with a keyboard, but looking at the HTML should also be a big clue that something is off. Here's the HTML for the submit button in the original inaccessible form demo:

<div id="sign-up" class="button">
  Sign Up
</div>

Since this is a clickable element, it definitely should not be a div! This element choice is what makes the form not submittable by keyboard. A simple
way to fix this is to change the div element to a button with type="submit", like so:

<button type="submit" id="sign-up" class="button">
  Sign Up
</button>

Making this button of type submit also fixes the general form submission. Now,
if we press Enter in any of the form inputs, the Javascript associated with the
submit button will trigger.

Fields Not Marked Required

Last but certainly not least is the form's inputs not being marked required for screen readers. This is very simple to fix, just by adding the required attribute to our required input fields. This ensures screen reader users will hear which input field is required or optional.

For our email input, for example, the fixed input looks like so:

<input id="email" type="text" required>

The Fixed Accessible Form

Now that we have addressed all of the accessibility issues we found with the form, let's take a look a look at the final, accessible form:

Now, we can easily use this form with just our keyboard or a screen reader.

If you want to learn more about accessibility, like what tools you can use to get started testing for accessibility, check out my other-articles. Is there an accessibility related topic you want to learn more about? Comment on this article with your ideas, or tweet at me!

How I Gave My Personal Site An Accessibility Makeover

Viktor Köves — Sun, 23 Feb 2020 16:08:32 +0000

These days, accessibility is one of my biggest passions and something that I am proud to know a lot about, but it wasn't always this way. This is how I went about fixing my old, inaccessible, personal site and making it fully accessible and WCAG compliant.

Background

I started building out my personal website in October of 2016 and at that point I had no accessibility knowledge at all. I hadn't even really heard of accessibility in terms of the web! Unsurprisingly, because I lacked the knowledge to make an accessible website, the first version of viktorkoves.com was a mess. It was riddled with trivial issues that I could have easily caught, had I known better.

Come December of 2018, however, I knew a whole lot about website accessibility and I wanted to make sure that my personal website would showcase my newfound knowledge and skills. Especially as a developer who specialized in web accessibility, it felt paramount that my website works for everyone.

To do that, I set out to audit my website and make it fully WCAG 2.1 AA accessible. (Not familar with WCAG? Don't worry, I'll be writing about that soon!)

My Process

So how did I go about making an inaccessible website that I built years ago into something that was fully accessible and that I could be proud to show off? My process can be distilled into the following steps:

Run automated tests to discover "simple" issues
Manually test screen reader and keyboard usage
Fix discovered issues
Repeat!

To start any accessibility remediation, you have to know the issues you are trying to fix. I used some automated tools, like HTML_CodeSniffer, to find any simple accessibility failures. This included things like my gallery page not having any alt tags on the images and my homepage skipping from a level 1 heading (<h1>) to a level 4 heading (<h4>).

If you're not sure what tools you should use to test your site's accessibility, check out my previous article on accessibility tools.

Automated tools found a good number of issues, but they only cover part of what makes a site accessible. I then proceeded to test my site using just my keyboard, and then tested it with a screen reader. I discovered that the main functionality of my portfolio page was completely inaccessible to users who were limited to the keyboard, as some of my links only showed up on hover of the portfolio images. I also realized that my gallery overlay system did not make it clear what buttons did to screen readers.

If you are curious what all of the issues were that I found in testing my website, you can view them in my WCAG 2.1 AA GitHub milestone.

Some Example Failures

Color Contrast on Homepage Links

One of the first failures I saw was a contrast issue on my homepage, which I documented in GitHub issue #6 on my personal site's repository. Here's a screenshot of the failure from HTML_Codesniffer:

At first glance, this red on black text does not look like it's very low contrast - and to some folks it might be perfectly sufficient! However, if you look at this screenshot in greyscale, you can see the problem:

For users who have color-blindness, this pair of colors is very hard to discern, making this text really hard to read! This is because although the colors are fairly different by hue they are not far apart in brightness.

Luckily, this issue was very easy to fix. HTML_CodeSniffer suggested a new red color that was a bit brighter, and switching my links over to that resolved this failure and made those links a lot easier to read for everyone.

Social Media Links Not Having Content

Another accessibility issue HTML_CodeSniffer found is the social media links in my footer not having content, which I notated in GitHub issue #6 on my personal site's repository. Here's a screenshot of that failure from HTML_CodeSniffer:

Reading through the text of the error, this might seem a little confusing. What does it mean by saying the anchor element has "no link content"? It's an image!

In this case, what this was actually indicating was that I had used a <div> with a background image for my social media icons, and that was causing a very big accessibility problem. This is because although <img> tags have an alt attribute that you can use to specify text that a screen reader user will hear to represent the image, you can't do that with a <div> element!

This meant that on my personal site, if a screen reader user tabbed down to the footer, they would hear... nothing. After all, there was nothing in the link to explain what it was!

There are two ways I could have fixed this issue:

Switch to an <img> element and use an alt tag to describe the image
Use an alternate way of labelling the links, like an aria-label

Although the first solution is preferable and makes your HTML more semantic, I
was using SVGs for my social media icons and was planning to move them into a spritesheet, which would have been very difficult to do with an <img> element. Since I knew I needed to use a background image, I ended up taking the latter approach.

Here's what the faulty code was before:

<a href="https://www.linkedin.com/in/viktorkoves">
    <div class="linkedin"></div>
</a>

And here is the corrected, accessible version:

<a href="https://www.linkedin.com/in/viktorkoves"
  aria-label="Viktor on LinkedIn">
    <div class="linkedin"></div>
</a>

The difference here is only the aria-label on the <a> tag, which now provides content for screen reader users - ensuring that when they navigate to my footer, they get a proper idea of where this link goes.

What I Missed

Despite my best efforts, using automated tools and a screen reader as a sighted user is only a best guess at what users might really need.

I was very appreciative when someone reached out to me on LinkedIn and told me that they had a hard time navigating my portfolio page because I hadn't used headers to break apart the page. This is something I had completely missed in my testing! I was looking so much at automated auditing tools and full-on accessibility "failures" that I missed a huge piece of usability improvement. In this moment, I should have taken the advice that I gave in a previous article:

Remember that automated auditing tools are a starting point to learning about whether a site is accessible, but they aren't fool-proof. There are lots of things that are really important to accessibility like tab order and keyboard interactivity that an automated tool is going to have a very hard time testing, if it can test it at all.

I think it is important to remember that no matter how hard we might try to accommodate everyone's accessibility needs, we are just making our best guesses and we are likely to miss something. This is why frameworks like inclusive design are so critical - our users are ultimately the true determination of whether we really made a fully accessible site.

Is there an accessibility related topic you want to learn more about? Comment or tweet at me!

Note: This post was originally published on my personal site.

The Accessible Developer's Starter Kit

Viktor Köves — Sun, 16 Feb 2020 21:36:13 +0000

Whether you are just starting out learning about web accessibility or you are an experienced developer well aware of accessibility, I want to help. This post will show you some of the tools that I have been using for the past few years to find and fix accessibility issues.

Auditing Tools

Warning! ⚠️

Remember that automated auditing tools are a starting point to learning about whether a site is accessible, but they aren't fool-proof. There are lots of things that are really important to accessibility like tab order and keyboard interactivity that an automated tool is going to have a very hard time testing, if it can test it at all.

The only sure fire way to find out if your site is fully accessible is to test it with a wide variety of users with disabilities, hire professional auditors, or both!

HTML_CodeSniffer

HTML_Codesniffer is one of my favorite tools for doing a quick accessibility check on a page as it is super fast, can target multiple accessibility standards, and makes it really easy to filter between errors, warnings, and notices. I actually learned about it from an auditor who used it as a starting point for finding more simple failures like contrast that would take a long time to do manually.

Here's a screenshot showing it finding a contrast failure I put on my homepage:

HTML_Codesniffer is also surprisingly simple to install, since it's a "bookmarklet" that just requires you to make a bookmark with some javascript code. Try it at the HTML_Codesniffer website!

Chrome DevTools' Lighthouse

If you are interested in website performance, you have probably heard about Lighthouse, an auditing tool built into Google Chrome's DevTools. You might already know that it can audit a website and make recommendations for performance and web best practices, but it's also great as a quick accessibility auditor!

Lighthouse does a number of automated accessibility checks, and also lists out checks you should do manually to properly confirm your sites accessibility. It gives you an overall score on accessibility from 1 to 100, which can help you get a good overall sense of if your site is mostly accessible or really inaccessible, which can be hard to determine with other tools.

Check it out in Google Chrome's DevTools, and learn more about it at the Chrome Lighthouse page.

Accessibility Insights for Web

Accessibility Insights for Web is a Chrome extension built by Microsoft. It helps you look at headings, tab order, and color contrast in more intuitive ways than just a list of failures. You can use a visualizer for tab order (called "Tab Stops") that will number the tab order as you hit the tab key, making it really obvious if something is out of place. It can also show you all of the headings on your page, which can help you catch bad heading order or tell you if you don't have enough headings breaking up your content.

Lastly, its color tool lets you make your entire website greyscale, which can help you find not only color-contrast misses but also if you have content that requires color for its meaning - like fields that only indicate they are errored by turning red. I can't recommend this tool strongly enough.

Install it or learn more at the Accessibility Insights for Web Chrome Web Store page.

Contrast Ratio

Sometimes you just need a tool that tells you if two colors are WCAG contrast compliant, and Contrast Ratio does just that. You input two colors, and it will tell you whether the pairing is WCAG AAA compliant, AA compliant, AA compliant at certain sizes, or not compliant. It's one of my most used tools when I am designing a site!

Try it out at contrast-ratio.com.

Accessibility Tools

When working on web accessibility, you don't want to just use your tools to tell you if something is accessible or not - you want to try out accessibility tools that your users actually use to see if they are working as you expect!

Using a screen reader or other accessibility tools is going to give you so more information about the experience your actual users have than any tool can provide you, and it can also catch issues that automated tools might miss, especially in more dynamic interfaces.

NVDA and ChromeVox

NVDA and ChromeVox are both screen readers, and I have used both of them to audit pages and to test if our screen reader users were getting the content we were trying to communicate via properties like aria-live.

ChromeVox is my day-to-day screen reader, as it's a Chrome extension that is easy to install and works on Linux (which is pretty rare). However, it's no longer maintained and can handle certain aria tags incorrectly.

NVDA, on the other hand, is a free screen reader for Windows, and it's my screen reader of choice when I want to test on a Windows machine. It's more popular and more maintained than ChromeVox.

Download NVDA or learn more at the NVDA homepage. Install or learn more about ChromeVox at ChromeVox's Chrome Web Store page.

ZoomText

ZoomText is a tool that I actually heard about thanks to a user with low vision, who used it to change the color scheme of websites and to magnify the screen beyond the browser limit of about 500%.

It's really useful for making sure that your website properly handles different color schemes and for finding accessibility issues you might not find otherwise, like your links relying on color differences that are lost with a custom color scheme.

Download it or learn more at ZoomText's homepage.

Have suggestions for a tool that you love that I should try out? Tweet at me!