As a developer, it feels like I spend more time working with forms, menus, and grids on a website than I do using them. The more time I spend working, the easier it is to get bogged down with the way things work in a certain environment.
My development environment is set up with a 1920x1080 resolution, the latest version of Windows, the latest browser updates, and a strong internet connection. It's easy to take these things for granted. However, there's another more important factor that often gets taken for granted - me.
This past winter I attended a talk at CodeMash by Dylan Barrell. He shed light on what developers can do to make the Web more accessible for everyone. It made me realize that I don't spend nearly enough time envisioning my software from the perspective of someone who can't use a mouse or doesn't have good vision. Under Section 508, ADA compliance is also a law. We should be taking great care to make sure we are meeting these requirements. A few of the most important takeaways for me:
1) Place labels and error messages close to your input controls.
Labels and error messages should be as close to your input controls (text boxes, checkboxes, etc.) as possible. For labels, this is how most people are designing forms anyway. But what stuck out for me was error messages.
Validation summaries — areas where you group all of your validation/error messages — should be a no go. When you validate your form, a screen reader will go through and spit out all those messages in order outside of the context of the form controls themselves, and that's of no help to the user. Instead, associate any error messages with the specific control that failed validation. A simple way to do that is to use a tool like aria-labelled by as described below.
2) Use the right tools.
On the subject of error messages, a useful tool to use is the aria-labelledby HTML attribute. Screen readers and other web accessible means use this value to associate a single element or multiple elements (a group label and a specific control label, for example) with a particular control. In the context of error messages as discussed earlier, the error message itself can be associated with a control so that the error message clearly states where the error occurred.
<input type="text" id="Date" aria-labelledby="Error" /> <div id="Error">Please enter a valid date.</div>
3) Make data tables easier to read.
To assist users that are hard of sight, an easy but often overlooked tip is to use zebra striping (faintly striping alternate rows) of data tables.
4) Use big, clickable areas that contrast well.
Extremely small buttons or checkboxes without a wide clickable area can be a struggle for users that do not have the ability to maintain tight mouse precision, or who have difficulty using mobile screens. Wrap the text of radio buttons or checkboxes in a label to make the text clickable as well. Links and action buttons should be easily noticeable on the page, to assist with colorblindness. Dark text on light backgrounds, or light on dark, and links should almost always be underlined.
5) Make content easy to understand.
On the content (for developers, this can include form/feature copy) side of things, choose your vocabulary and writing style carefully. Write as general as you can, be careful with "big" words, don't use obscure idioms, and try to cut down any excess copy that may not be needed. Using a tool like Hemingway can help a lot in making these improvements.
"Please complete all of the necessary form fields below before submitting. Any unnecessary fields can be left blank:" could become "Please fill out the form fields below." Simply by checking the required fields on the page the user will know which fields are necessary or not. Hopefully you have taken great care to know how each form field helps you — our own Anna Yunker discussed this and other great form-building tips in a past blog post.
6) Change section titles.
If you're working with a single-page application, be sure to change the titles of each section element. If possible, they should match the navigation titles you are using for these sections. This will let the user or any accessibility tools know they are switching to a new document.
7) Test for ease of use.
During development, a simple test to check ease of use for your menu or form is to attempt to navigate through on just your keyboard, no mouse. If you find yourself unable to tab through items, you may need to check tabindex attributes or the order of the elements on your page. Tabindex attributes should only be positive values if that something you want to force to the top of the tab order. For example:
<input type="text" id="FirstNameTextBox" /> <input type="text" id="MiddleInitialTextBox" tabindex="2" /> <input type="text" id="LastNameTextBox" />
The above code will be sorted by screen readers and keyboard-only navigation as Middle Initial -> First Name -> Last Name because positive tabindex values are given priority in navigation. For this reason, it's best in most scenarios to not use these values and instead rely on the ordering of the elements themselves.
There are even sites out there that allow you to "scan" through your site to check for accessibility issues, like Webaim. While not always 100 percent accurate, this can help catch any bigger issues you may not have noticed during development.
Build Fully Accessible Sites for Everyone
Hopefully these tips will help you build with a better eye for a fully accessible site like they did for me. If nothing else, they should help you remember that there's a good chance that someone will be coming through your site using a screen reader, or using a high zoom, or some other technology to help them work with their disabilities. Take some time to make sure that these things are made as easy as possible for these users.