Making Accessibility FUN: Practical Tips for Building & QA'ing Accessible Websites, Pt. 1

Hi! This is my first post here at dev.to and I'm excited to start off by sharing something near and dear to my heart: accessibility.

A little about me: I'm no expert in accessibility but I have some experience and feel strongly about making technology more inclusive.

What this post is about: I think that accessibility can sometimes feel overwhelming (just take a look at the official guidelines 😵) and like there are a lot of grey areas. This post is geared towards folks who want some practical and memorable tips to make it easier to build and QA accessible applications.

So what is accessibility?

Accessibility is making your site as usable as possible to the greatest number of people, including folks with any range of:

• Visual impairments
• Hearing impairments
• Mobility impairments
• Cognitive impairments

Why should we care about accessibility?

1. Don't Get Sued

Accessibility is a compliance issue. Websites and mobile applications are legally required in many countries to adhere to certain accessibility standards. Failure to do so can and does result in lawsuits. 😬

2. Be a More Rigorous Engineer

Paying attention to the accessibility of your site helps uncover bugs in your markup and edge cases that real users will likely come across.

But another big reason we should care about accessibility is because we should want to...

3. Be Good Humans

AKA don't be like this guy (just kidding, apparently Guy Fieri is v nice!)

Just because someone is differently abled doesn't mean that they should have a worse experience on your site.

After all, if it's not usable by everyone, it's not usable.

So how do you build and QA Accessibility UIs?

When I think about whether something I'm building is accessible or not, I think of 3 main criteria. Is it:

• Functional
• Understandable
• Navigable

Or if acronyms help you with memorization, is it FUN?

Let's dive into what each of these means and some tips around them.

1. Functional 🔧

• Can the user take the same actions as a user without a visual/hearing/etc. impairment?
• Are they able to have the same experience?

Tips

1. If you're working on a user story with acceptance criteria, go through each acceptance criteria with a screenreader and keyboard navigation.
   • Can you achieve the same behavior via keyboard actions?
2. If you have a tirekick document that you use to QA across browsers and operating systems before a feature launch, add a column for an accessibility check.
3. Use semantic HTML
   • This provides a lot of functionality out of the box because it's telling the browser what this element is supposed to do.

2. Understandable 💡

• Can the user understand the information presented?
• Is there enough textual context for the user without requiring visual or auditory aids?
• Is the HTML structure purposeful or creating unnecessary noise?

Tips

1. Use human-readable aria-labels to provide more context
   • Ex. 'A close button in an overlay'
2. Add descriptive alt tags to images or icons (unless it's redundant)
3. Make sure text is legible for users with partial vision
4. Use semantic HTML to minimize irrelevant noise
   • If you can't use the appropriate HTML for presentation reasons, ex. you need to use a <table> instead of <ul> for a list of items, apply a role attribute with the value of 'presentation', which will allow the screenreader to ignore the underlying structure instead of reading it out.

3. Navigable 📍

• Can a keyboard user navigate to each part of the page?
• Are they able to navigate in the correct order?
• When they hit enter on a link, are they redirected appropriately?
• Does the user know where they are on the page?

Tips

1. Focusable elements should show focus so partially sighted users will know where they are
   • Hint: Don't override the css-outline property with 'none'. This site gives me joy: http://www.outlinenone.com
2. Tab order should follow default content structure so the user isn't disoriented
   • Hint: Use the tab-index attribute carefully or not at all. If you find yourself in a situation where you need to use tab-index to make something tab-able, consider using a more semantic element that is natively tab-able (<a>, <button>, <input>, etc.)
3. No keyboard traps so the user doesn't get lost
   • Ex. If the user is in an overlay they triggered by clicking a button, that button should regain focus once they close the overlay.
4. Use semantic HTML (are you sensing a theme here?)
   • Hint: Don't use an element like a <span> or <div> with a click handler instead of a <button> or <a> because it won't work with a keyboard.

Wrap Up

That's it for now!

This is definitely not an exhaustive list of tips or the only ways that you can increase the accessibility of your site, but it's a starting point. And hopefully these three themes — Functional, Understandable and Navigable — will make it easier to keep accessibility in mind while building and QA'ing your features.

Stay tuned for part 2, where we'll explore how to use various tools to test the accessibility of sites and try it out ourselves!

Thanks for reading ❤️

Comments

[Chris Achard]

Great post! and a very important (and often overlooked) topic. Definitely saving this for the next time I'm doing a site - great list of resources. Thanks!

(Also - great use of gifs 🤪 and great first post!)

[mamumo]

Really looking forward to Part 2! Brilliant work!

[Jan Küster]

Thank you for pushing accessibility as it's underrated, yet an important factor in closing the digital gap.

A great follow-up would also be to provide a deeper insight in potential groups with accessibility needs (motoric impairment, visual impairments, low- and lowest literacy, etc.) and how current standards can help them and where more work is required yet.

[Paul Rumkin]

We definitely need more articles like this. Thanks!

P.S. Animated gifs are very distracting, I think there are a lot of people who just left the page without giving feedback.