DEV Community: Viktor Köves

Anyone Can Make Software Now. But When Does A Side Project Become Production Ready?

Viktor Köves — Thu, 28 May 2026 18:50:28 +0000

Author's note: In the spirit of fairly critiquing AI and practicing a suggestion I end the article with, this article and the accompanying illustration were created entirely without AI assistance.

Agentic coding AI is here, and it’s transforming the software industry. But with agentic coding out now for over a year, has it felt like the software industry has really transformed? From my from vantage point, although there are some really cool projects that have been built only because of new agentic coding tools, it generally feels like we’re awash in a sea of software slop. Tim Kadlec wrote a great article, “Losing Focus”, that really resonated with me, especially this quote:

“I don’t think the quality of software has increased all that much in in the past 12 months. I think maybe the amount of software has, but it’s very, very hard to find software that’s reliable.” - Max Scoening, Head of Product at Notion

I’ve been hearing loads of stories and murmurs about AI from the people I know in tech, and I think there’s a lot being lost in the binary divide that a lot of people seem to fall into - either AI is bad and can do nothing right, or AI is the new future of engineering, and every company should have all their code written by AI today.

I want to posit that right now we’re in the messy middle. An era of hype and grifters that want to sell you an AI fantasy that hasn’t been reached, which obscures the real present - powerful AI tools that can speed up professional developers, but can lure non-developers into shipping products that aren’t nearly ready for prime-time.

My Background

But first, if you don’t know me, let me explain why you should listen to my perspective. I’ve been working professionally in software (specifically web development, focused on the frontend), for over ten years. In that time I’ve worked at a non-profit, a for-profit, led a small startup, freelanced, and have led a number of open-source volunteer teams at Chi Hack Night, including right now working on ElectrifyChicago.net.

I have a lot of experience with AI. I started with Gemini chat for coding help years ago now, have used a number of AI code review tools, and have been using Claude Code for over a year. So I am absolutely not coming into this conversation as a skeptic - I use AI day-to-day in my work, and I know that it can be powerful, but that it can also make terrible code that would never pass even a basic review, whether because it's full of duplication, is hiding bugs, or any number of other issues. Before we get to that, though, let’s start with the positive side of all these agentic coding tools.

The Good - The Personal Software Revolution Has Arrived

Agentic coding has come with some real upside. When simple software becomes incredibly fast and cheap to produce means you can make bespoke, personal applications, to solve problems that are so specific that it wouldn’t justify a firm spending resources on making it. The Verge’s David Pierce has covered this really well, and termed this moment, the personal software revolution, in “You can make an app for that”.

When anyone can make bespoke software, you can make an application just because the existing software ecosystem doesn’t solve your exact problems. For me, that looked like creating my own bulk image compression tool, because I had accidentally photographed a whole vacation in a jpg high quality format that left me with 5 gigabytes of images from just a two day trip. When I looked for existing compression solutions, however, they all removed the EXIF data that’s key to backing up images (especially as a photographer) since it contains the time that the image was actually taken. Without the EXIF data, all the images would show as being “created” the moment that they were converted, and I’d have none of camera settings that were used for each image!

Before agentic coding tools, I definitely wouldn’t have dedicated the hours and hours of time that it would have taken me to look into how to do image compression client-side, set up a UI, and more. But with Claude, I just explained what I wanted and got a basic starting point, and then integrated and refined the site until it did exactly what I wanted.

However, this actually reveals something critical about using AI coding tools - you have to have a clear product vision. I was only able to build the bulk image tool that I was looking for because I had a very specific, narrow, product need, and knew exactly how I wanted it to look and behave. Without that vision, Claude could build something, but nothing close to the tool I built, and it wouldn’t be nearly as useful. I had really strong opinions on how I wanted the loading state to be handled, how I wanted the UI to look, and extra features (like a four image preview to test quality settings before committing to a 500 file conversion) that Claude wouldn’t ever have come up with. Put another way, Claude alone would have built something usable but not something great.

One last point on that image compression tool example - my use of Claude here didn’t require technical expertise (I didn’t look at the code very much at all) but that is only because the tool itself is small, discrete, in an isolated codebase, and I don’t need to maintain or update it. If I was trying to expand this tool to be a paid product, let's say, I’d want to think really carefully about the engineering decisions and the architecture to make sure it was ready for future growth.

In the open source world, Claude has also had some huge benefits, but in that realm I’ve already personally started to see the downsides. I’ve seen friends take existing open data and build really cool tools, like my friend Michael McLean and his Chicago Crash Dashboard. On the other hand, with Electrify Chicago, we’ve had a few collaborators open completely AI generated pull requests that they likely hadn’t even reviewed, which I then had to send back with a ton of feedback, because Claude wasn’t reusing variables or architecting code in a reusable way. On the more positive side, we have a lot of Python scripts that do really basic data analysis and computation on building data for Electrify Chicago, and agentic coding tools can do a great job at handling improvements to those jobs. Simply tell Claude “I’d like to calculate the buildings that didn’t report each year by ward, make sure to add unit tests”, point it at the current files, and it can generally make a pretty sound script, which would have taken a contributor a while to make. It still can require a good bit of steering to make sure the code is well isolated and not overly verbose, though.

The Bad & The Ugly - Same Shovelware, Prettier Skin

Now let’s talk about the slop, the shovelware, or whatever you want to call the glut of AI generated software. I want to recount a few stories that I think tell the story of the dangerous moment that we’re in, with software being shipped by people who don’t understand the risks of what they’re doing.

On the most extreme end, inexperienced practitioners can use AI tools without even basic guard-rails, resulting in scenarios like happened to car rental company PocketOS just a month ago. Their whole database was wiped out by an AI agent (Claude-powered AI agent’s confession after deleting a firm’s entire database: ‘I violated every principle I was given’ - The Guardian). As PocketOS’ founder Jeremy Crane puts it:

The AI industry is “building AI-agent integrations into production infrastructure faster than it’s building the safety architecture to make those integrations safe”.

I think there are actually two problems with this story - Crane frames the issue as Claude not following rules, but that fundamentally misunderstands how LLM based agents work - today’s AI agents do not follow rules, they ingest rules as suggestions. As someone who works with Claude day-to-day, the number of times it just ignores an explicit request is too many to count. The real issue, by my reading, is entrusting dangerous engineering capabilities (production database access) to non-engineers, who don’t know the safeguards necessary to properly protect customer data. It should take multiple intentional steps to access a writable copy of production data, and backups should be happening at such a high frequency that even a large deletion should be recoverable with only minor loss. In this case, however, Claude also deleted the backups, making the business fall back on a three month old backup. If that level of system failure happens in a lot of companies, I'd be willing to bet that the executive responsible for that oversight would be fired.

The paradox is that non-engineers can now build applications that look like production technologies, but when you dig under the hood, they are a sloppy mess. Like an amateur electrician who knows enough to get a light to turn on, but not enough to calculate power draws and run the right gauge of cable, you might not notice at first that the work is bad. Then, a few weeks, months, or years later - the temperature in your house runs a little high, you plug in a few too many devices, and the bad workmanship results in a catastrophic fire.

Funny enough, bad code made in bulk isn’t actually new, and we’ve had a term for it - shovelware. Shovelware was coined in the 90s for software that was all about quantity, not quality - like re-bundling DOOM levels to sell on CDs at a flea market. I think our current AI moment is very similar. Everyone’s showing off AI apps they made very quickly, but you spend more than a few minutes with them, and they are nonsensical and full of bugs, because they lacked care and thoughtfulness. That part isn’t the fault of AI - quick sloppy projects are always like that, no matter who (or what) writes the code. Ad agencies often make throwaway sites for marketing launches that might be similarly frail and not maintainable. But the catch is the quality of the code only doesn’t matter *if the software itself isn’t the product.*

If you are a restaurant with a hastily made static menu website that has security or performance issues, that's not really a huge problem. Your site doesn’t store any user data (and so isn’t a likely target for cyber-attacks or DDOS attacks), and the menu itself isn’t the business. You can literally afford downtime! On the other hand, that same restaurant would never tolerate downtime in their payment system. For a company making payment software, the software **is* the product*, and so uptime, security, and maintainability are as vital (if not even more so) than just having a working product.

That’s the tricky thing with AI - it is tempting to say that the code doesn’t matter, but the instant the code has to be updated or maintained (even by agents), it's important. I don’t care that my one off bulk image compressor has clean code because it works and I will probably never touch it again. If it has a big issue, I’ll throw it away and rewrite it all! But if you are building production software for a software business, only evaluating the output means that you may be hiding tech debt or bugs that you don’t understand, and future work by people or agents might stumble and fall into an ever growing pile of spaghetti code.

There’s another factor to consider too - AI builds upon the existing paradigms within a code base. If you are hands off and start an AI project and never look at the code, and it has bad practices, the AI will never stop and tell you to refactor. Even worse, it’ll see the sloppy patterns in your code and copy them. Like a house built out of rotten planks, but covered in shiny paint, it might look good at first blush, but when you try building a second story on top (out of even more rotten planks, potentially), the house is bound collapse.

In the real world, that might look like a database structure that isn’t optimized that will take hours or days of downtime to migrate, locking in out of date packages that have security vulnerabilities or aren't being updated, or duplicating code so that later updates become much more costly. Don’t be fooled - even if humans never have to look at the code the code still matters. AI tools make mistakes just like people do, and we created code review processes to catch code issues from developers, as well as QA to validate functionality, and AI tools need the same.

The Very Bad - AI Incentives & Token Maxxing

As I was writing this, I watched a video that I thought was worth mentioning - a clip from Linus Tech Tips’ podcast, the WAN show, “Amazon Employees Are Faking Their AI Usage”. In this part of the show, they discuss a recently covered phenomenon at Amazon, where developers are being pushed so hard to use AI (including with a token leaderboard), that they ended up creating bots to consume AI tokens (see also Amazon employees are doing fake tasks because they're forced to use more AI and show it - Digital Trends). Here’s an excerpt from the article:

“According to a new Financial Times report, Amazon employees are using the company’s internal AI tool called ‘MeshClaw’ for unnecessary tasks simply to inflate their AI usage scores and appear more aligned with the company’s growing AI-first culture.”

As a developer, this doesn’t surprise me. Developers are smart people tasked with automating problems and being efficient with their time, and although most can definitely see a benefit from using AI, that benefit doesn’t scale infinitely. If you want your organization to use AI to grow faster or ship features faster, you have to use metrics that actually measure what you care about, are grounded in data, and can’t be so easily gamed. Amazon could have, for example, suggested developers use AI more to ship features 10% faster - a goal that’s much more measurable and harder to game, and then could examine AI usage to see if it’s helping meet those targets. You could also set general daily usage targets, like setting goals around expecting engineers to try using AI on every task, and making sure that AI usage hits some baseline. But ultimately, AI usage isn’t the goal of any organization, and incentivizing crude metrics like this will lead to crude outcomes that don't benefit customers.

It’s also worth mentioning that wasting tokens like this and using AI frivolously isn’t free - both directly in financial terms, and indirectly in costs to our grid, our water supply, and our planet more broadly. There’s not a lot of great data on AI emissions and energy uses, but carbon credit company CNaught, in their article How Much Carbon Does AI Actually Use? And Why It's So Hard to Find Out, had this interesting call-out:

“Software engineer Simon Couch recently analyzed his own Claude Code usage and found that a median coding agent session consumed approximately 41 Wh (138 times more than a typical chat query). On a typical workday running multiple coding agents simultaneously, his estimated energy consumption reached 1,300 Wh, equivalent to roughly 4,400 chat queries.”

They also point out that smarter models consume more energy and have higher emissions, noting:

“The newest ‘reasoning’ models like OpenAI's o1 series… can use 50-100x more energy than standard queries. A research paper… found that ‘smarter’ LLMs produce up to 50x more carbon emissions than simpler models”

I think AI’s environmental impact has been pretty heavily discussed, but I think that missed in that conversation is that AI is just like any use of computers, from hosting a website to browsing Netflix. Running computers requires energy and creates emissions, and we should use it judiciously to achieve valuable goals. You can use an expensive AI model to build a website that helps reveal hidden oil and gas emissions, or to track novel diseases, or you can use it to burn tokens to go up on an internal Amazon leaderboard. Even if these had equivalent emissions, I think they are clearly ethically distinct.

Side Note - The AI Cost Hazard

One aside I wanted to mention - one of the other murmurs I have been hearing about is the potential increase in AI costs, like in the article You're about to feel the AI money squeeze from Hayden Field at The Verge.

A lot of large companies have been blowing through AI budgets, with Uber noting that they burned through their coding tools budget in four months (Uber Burns Its 2026 AI Budget In Four Months On Claude Code - Forbes), and Microsoft discontinuing Claude code licensing and pivoting to their own GitHub Copilot. These changes come without any dramatic increase in token costs, and there's a lot of reason to expect that as AI companies seek to move into profitability as they look towards IPOs, they will raise token costs to make sure that they aren't losing money on any of their customers.

I don't think I can speak definitely on this issue, however. AI tools have evolved extremely rapidly, with distillation leading to smaller, leaner, models that can run locally, and it's quite possible that a new player or new model will appear that offers a better middle-ground on cost and performance.

So What Do We Do?

So what’s a safe approach to using AI? It's actually pretty simple - hire professionals to use AI with safeguards, and treat it like a tool with benefits, drawbacks, and costs. Don't treat it like an infallible magic machine that can solve all your business' problems.

First, AI does not eliminate the need for a clear and precise product vision. If you want to build a copy of something that already exists (like the classic demo of a basic snake game) AI will do great. But if you want to solve a novel problem for your specific customers, you need to have research and a clear product vision to guide you. Otherwise, as the old software adage goes, garbage in garbage out.

Second, if you can’t evaluate the code, in a professional environment, you shouldn’t ship the product. It’s one thing if you vibe coded your personal website (you’re not storing user data, and you’re not charging money for it), but a production application is a whole different can of worms. I heard a story from a friend that someone non-technical they knew had vibe coded an application, and said:

“I’ve built out my whole application, but I don’t know how any of it works.” - Anonymous founder

To me, a non-technical founder building their whole app with AI means they haven't built a product, they’ve built a liability. If you do not understand the underlying pieces of the application you are shipping, you don’t even know what you don’t know - you likely don’t have the technical expertise to consider or validate the security, accessibility, or scaling concerns of a production application, and if it blows up it may well leave you with a huge lawsuit and legal liability when you lose customer’s money or their sensitive data.

Third, and perhaps most controversially - I think every engineer should practice coding without AI. I’ve noticed my muscle memory for different techniques and functions slipping away as I rely on AI tools more, but my coding expertise and knowledge is still valuable. I need to know the different JavaScript array functions and the CSS display properties to evaluate code, even if not to write it whole cloth, but just like an unused muscle rapidly atrophies - so do our unused skills.

We’re in a complicated moment right now, and I think as an industry and as a society we’re still figuring out the norms and best practices around agentic coding. With AI, anyone can code - but just like anyone can do electrical work, that doesn’t mean anyone should. You don’t want your business to be the house that burns down.

Anyone Can Make Software Now. So Why's It Mostly Dangerous Crap?

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

“I don’t think the quality of software has increased all that much in in the past 12 months. I think maybe the amount of software has, but it’s very, very hard to find software that’s reliable.” - Max Scoening, Head of Product at Notion

My Background

The Good - The Personal Software Revolution Has Arrived

The Bad & The Ugly - Same Shovelware, Prettier Skin

The AI industry is “building AI-agent integrations into production infrastructure faster than it’s building the safety architecture to make those integrations safe”.

The Very Bad - AI Incentives & Token Maxxing

“According to a new Financial Times report, Amazon employees are using the company’s internal AI tool called ‘MeshClaw’ for unnecessary tasks simply to inflate their AI usage scores and appear more aligned with the company’s growing AI-first culture.”

“Software engineer Simon Couch recently analyzed his own Claude Code usage and found that a median coding agent session consumed approximately 41 Wh (138 times more than a typical chat query). On a typical workday running multiple coding agents simultaneously, his estimated energy consumption reached 1,300 Wh, equivalent to roughly 4,400 chat queries.”

They also point out that smarter models consume more energy and have higher emissions, noting:

“The newest ‘reasoning’ models like OpenAI's o1 series… can use 50-100x more energy than standard queries. A research paper… found that ‘smarter’ LLMs produce up to 50x more carbon emissions than simpler models”

Side Note - The AI Cost Hazard

So What Do We Do?

“I’ve built out my whole application, but I don’t know how any of it works.” - Anonymous founder

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!

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

DEV Community: Viktor Köves

Anyone Can Make Software Now. But When Does A Side Project Become Production Ready?

My Background

The Good - The Personal Software Revolution Has Arrived

The Bad & The Ugly - Same Shovelware, Prettier Skin

The Very Bad - AI Incentives & Token Maxxing

Side Note - The AI Cost Hazard

So What Do We Do?

Anyone Can Make Software Now. So Why's It Mostly Dangerous Crap?

My Background

The Good - The Personal Software Revolution Has Arrived

The Bad & The Ugly - Same Shovelware, Prettier Skin

The Very Bad - AI Incentives & Token Maxxing

Side Note - The AI Cost Hazard

So What Do We Do?

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

Table of Contents

The Fundamental Principles

Text Alternatives

Contrast

Making Accessible Images

Readable Text

Alternative (Alt) Text

Adding Alternative Text on Social Media

Making Accessible Videos

Contrast in Videos

Captioning Videos

Caption Examples from “The Queen's Gambit”

Caption Example 1 - Music & Sound

Caption Example 2 - Designating Speakers

Caption Example 3 - Sound Effects

Captioning Videos for Social Media

YouTube, Vimeo, and Other Video Platforms

Instagram, Twitter, and Other Non-Video Platforms

Transcripts

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

The Homepage - Starting Our Order

Building Our Burrito

How Could We Fix These Issues?

How Could We Have Prevented This?

What Do You Wish You Knew About Accessibility?

Creating Accessible Forms: The Basics

A Faulty Form Example

What's Wrong With This Form

Fixing the Faulty Form

Inputs Aren't Properly Labeled (Text)

Inputs Aren't Properly Labeled (Radio Buttons)

Form Submission

Fields Not Marked Required

The Fixed Accessible Form

How I Gave My Personal Site An Accessibility Makeover

Background

My Process

Some Example Failures

Color Contrast on Homepage Links

Social Media Links Not Having Content

What I Missed

The Accessible Developer's Starter Kit

Auditing Tools

Warning! ⚠️

HTML_CodeSniffer

Chrome DevTools' Lighthouse

Accessibility Insights for Web

Contrast Ratio

Accessibility Tools

NVDA and ChromeVox

ZoomText