Years ago, I didn’t understand what designing websites for accessibility really meant. I thought that accessibility guidelines would only benefit a few users, that they would introduce unsatisfying design limitations, and that following them would take more time and money.
By adopting the right mindset, I realized the truth. Now, when I work on improving accessibility in projects like the American Alliance of Museums redesign, I know how to reframe my old misconceptions into guiding principles.
Accessibility guidelines benefit everyone regardless of ability
Accessibility improvements lift usability for all users. Here are some other things that happen when you build a site with an accessibility mindset:
- Search engine rankings are improved.
- Your site is future-proofed (or at least future-anticipating) as web standards evolve.
- It’s easier for users of all abilities to access your site during circumstances of limited ability (e.g., when they’re distracted or unable to use sound).
- People of all abilities can access your website in ways that are most comfortable for them.
Accessible sites don’t have to be ugly
The majority of accessibility features do not have a visual impact on your site. There can be aesthetic limits you’ll have to consider, such as maintaining decent contrast between text and backgrounds, enabling text to be resized, allowing for focus styles, and denoting meaning through more than color.
These limits don’t have to stifle your creativity. Think of it like designing “mobile-first” for phones: This helps make your site easy and intuitive for everyone, regardless of their abilities.
When you internalize these guidelines, you can make aesthetic choices that are both beautiful and usable. Here’s an overview of WCAG guidelines to start you off.
Website accessibility features don’t necessarily increase scope
Accessibility audits take a little upfront investment. Our a11y consultant on AAM, Sina Bahram of Prime Access Consulting, reviewed our design comps, followed by several hours of code audits as features entered QA.
From that initial learning, we produced patterns and documentation that we could reference during QA for future features. We were able to apply what we learned not just to this project but to all projects at Alley. We’ve referenced and shared these standards as we developed new features for unrelated projects. This ends up saving us time, as we won’t need to revisit work to improve or add accessibility features.
When meeting accessibility guidelines is part of delivering “quality” code — one of Alley’s three core values — it’s not extra work. It’s a baseline mindset for approaching or reviewing a feature. We internalize these standards just like the latest Javascript techniques, and they become interwoven in our work. The time we spent establishing these standards and documentation has paid off in many projects since.
You need to test your site in a screen reader
Auditing features with Sina using an actual screen reader was particularly valuable because it gave context to why accessibility is critical. Developing an accessible site without testing in a screen reader is like developing a responsive site without testing on a phone.
Every screen reader is different, and because the software can be expensive, users tend to upgrade it less frequently. Accordingly, written guidelines about screen readers may not be applicable to many users yet—or to any, if the software itself has changed. Testing with real screen-reader software is the best way to know how your site performs in terms of accessibility.
I’d heard many axioms about accessibility that ended up being incorrect — for instance, even something as simple as always giving every image on your site an alt text description wasn’t quite right. I learned it’s actually preferable to have an alt attribute with an empty string when an image is decorative. I didn’t appreciate these quirks until I saw the tools in action.
Though it’s not the tool with the widest adoption among non-sighted users, you can use the VoiceOver screen reader on macOS and iOS for free to get an idea of how accessible your project is.
There is never a point when website accessibility work is “finished”
While we’ve taken great steps to make aam-us.org accessible, it’s an ongoing project. Just as any website needs updates and maintenance, you can always do more to update and maintain your site’s accessibility.
Even if your site isn’t fully accessible, you can take steps today to improve it — and you don’t have to be a developer to do so. A lot of the elements of an accessible website are up to the editors who create the site’s content, not just the developers who create the framework. You don’t need the budget for a full redesign to implement practices to make your content more accessible.
- Always write descriptions (alt text) for contextual images. A guideline for a good description is “How would you describe this to someone on the phone?”
- Use lists (ordered or unordered) to organize groups of content (like this one!).
- Break up your content with headings.
- When you use headings, make sure they’re hierarchical. In a blog post, never use a heading higher than an H2 (as H1 will be used by your post title). If a heading is under the H2, make sure it is an H3. Don’t use levels of headings just to denote the size of your header.
- When linking to content, describe the content you are linking to within the link. For example, don’t do this.
Click here to read more accessibility tips at WebAIM.com.
Do this instead.
WebAIM is a great resource for more tips on making web content accessible.
Website accessibility doesn’t have to be scary, hard, or overwhelming. Do you have questions about how accessible your current website is or how you might bring an accessibility mindset to your next web project? Let us know at info@alley.co.