Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with disabilities.
Honesty time: I haven't paid much attention to making the apps I build accessible. Because I don't have a disability, I'm never personally faced with the pains of using in-accessible websites.
No excuses though. Below are 8 things I've done wrong building web apps and 8 solutions going forward. It's by no means an exhaustive list, but it's certainly a step in the right direction.
<input>sVue (and other front-end frameworks) make it really easy to pull in third-party packages for more advanced form control interactions.
I've personally used the following package on more than one project: vue-slider-component.
Turns out, it's impossible to use without a mouse. See for yourself: (click anywhere inside the CodePen window, "tab" to the slider, and try to move it using only your keyboard)
Can't do it right? The slider can't receive "focus" using your keyboard.
Before blindly pulling in a package or building a custom component, make sure it can receive "tab" focus and can be used with a keyboard.
Specific techniques are outside the scope of this article, but here is a good page for reference: Provide Meaning For Non-Standard Interactive Elements
It's important for people using assistive technologies to be able to see what element currently has focus. By default, browsers outline input elements when they are focused.
You can see for yourself in the following CodePen:
Here is a peice of CSS I literally grabbed from my last project. I'm not proud of it:
// Globally remove the annoying outline when a button or input is clicked.
input, textarea, button, button:focus {
outline: none;
}If you are unhappy with the default browser outline visually, there are ways to make it more visually pleasing. If you use TailwindCSS, here's a way you can acheive this:
<input type="text" class="outline-none focus:shadow-outline">Screen readers rely on <title> tags on pages to communicate to the user what page they are on and help them keep track of multiple tabs.
I'm usually pretty good about unique <title>s on blogs and marketing pages, but I've definitely overlooked them in web apps.
Bad
<title>Some App</title>Better
<title>Some App | My Account</title>Best
<title>My Account | Some App</title><input>sIn attempts to make my UI's look more sleek and minimal, I've relied on input placeholder text instead of <label> tags to label input fields.
Bad
<input type="text" name="username" placeholder="Username">Good
<label for="username">Username</label>
<input type="text" name="username" id="username">Assistive technologies rely on <label> tags for communicating input fields to users. Also, the visual contrast between placeholder text and the input background is often too little for people with visual impairments.
<input>s in a <form> tagThis is one that I started doing when I switched to a Vue/ajax approach for most forms.
Because I'm not relying on native form submissions, I would forego adding <form> tag altogether.
Bad
<label for="username">Username</label>
<input type="text" name="username" id="username" v-model="name">
<button @click="logIn">Log In</button>Good
<form @submit="logIn">
<label for="username">Username</label>
<input type="text" name="username" id="username" v-model="name">
<button type="submit">Log In</button>
</form>Assistive technologies look for <form> tags and offer helpful functionality specific to forms.
<div> instead of h1, h2, h3Assistive technologies use heading levels to help establish the structure of a page. This seems obvious for things like page headings but is less obvious for widget/panel headings.
Bad
<div class="text-lg">Create Post</div>Good
<h1 class="text-lg">Create Post</h1><img> tagsI believe this is the #1 most common accessibility mistake, and I'm no exception here.
I try to add them sometimes, but often admittedly don't.
Bad
<img src="/logo.png">Better (but still bad)
<img alt="Logo" src="/logo.png">Best
<img alt="Some App Logo" src="/logo.png">When writing alt attributes, it's helpful to ask yourself: If I couldn't see this image, what info would be helpful to me. This will force you to write helpful, "functional" copy, rather than useless, verbose descriptions.
<a> when I should use <button>For some reason, I've often used <a> tags for button functionality. Particularly if the button is styled like a link.
If your <a> tag isn't a link, it should probably be a button.
Bad
<a href="#" @click.prevent="showModal">Show Modal</a>Good
<button type="button" @click="showModal">Show Modal</button>If the subject of accessibility always felt a bit nebulous to you, then hopefully I've provided some concrete examples for you to up your game with.
If you enjoyed the post, sign up for my email list. I send out a hand-written email every week or so with updates, cool things I'm learning, and easter eggs.
Peace, Caleb
I send out an email every so often about cool stuff I'm working on or launching. If you dig, go ahead and sign up!