Sunrise in the fog

    Accessibility

    With website accessibility becoming a topic that is coming to the forefront of concerns we as developers face, it's important to know how to make sure that we're able to properly test and build with it in mind. It's an important subject we get right - messing it up opens clients up for lawsuits, and also excludes users from using our site. 

    It's a complicated subject, and often not glamorous, which leads to us not always giving it the attention it deserves. Which leads to this post - what are some good tools and tips to help us develop with accessibility in mind?

    Tools

    Wave Chrome Extension: this is a nifty extension that when run builds an audit of a page. It's fairly in depth, showing errors for color contrast, missing alt tags, inputs with missing labels, etc.

    Google Lighthouse: this one is also fairly solid, though it mostly hits only high level issues. Most of them are also taken care of in wave, but it's still nice to run as a way to get an overall view of where a page is at.

    Tips

    While the above tools are good, it's important to note that they don't test for interactive elements on our site (like tabbing order) for example. So how can we test for these?

    First, like previously mentioned, tabbing through a site. The first part of this is normally something we do right without even thinking, it's taken care of just by ordering our elements in order of where they are in the page (top to bottom, left to right). The second part, not quite so much. When we interact with something (say, opening an inline cart), we need to make sure to reset focus. If our inline cart isn't directly after our trigger (which it often isn't), then if we don't reset the focus users may have to tab through half the site to get to the inline cart. The same often happens with quick-shop modals. And, if that's how our keyboard navigation works, that's likely how a screen reader would work. So we need to test keyboard navigation and interacting with the site to make sure our focus is always set to where it should be after our interactions.

    Second, we often default to divs as our tag of choice when we don't know what to use. The problem with this is, if we make a div clickable, screen readers won't see these as being interactive. There can also be issues with keyboard navigation on them (divs aren't naturally focusable). So, how can we deal with this? I've seen a few instances where the solution was to play with aria roles, but instead of that, I believe the easiest solution is to just make our interactive element something the browser will interpret as being naturally interactive, like a button. 

    Third - how we determine sizing, especially for fonts. Often times, we use pixel values. But suppose a user has their browser set to a higher base font size? Then we aren't respecting their settings, and potentially make it hard for them to read the text on the site. So, a better solution is to use rems. The rem unit is going to default to 1 rem being equal to what ever setting the user has as their base (usually 16px for most browsers). But should we limit this to just font size? No! If we enlarge text, but not letter spacing or line height, then our text all starts to overlap, making it even more unreadable. The answer here is that we start using rems as our go to unit, so that our site is always going to fit together based on whatever the user has as their default. To test? We need to start adjusting our default size during development and QA. 

    Four, we need to get back to using default HTML elements whenever possible. I know it's visually pleasant to have a totally custom dropdown or accordion, but when we reinvent the wheel the only thing we can do is confuse the browser. If it already has a native element for something, then that's what it knows the best and is optimized for. Rebuilding only adds room for accessibility issues, so we should stay away from those custom drop-downs, and rely on native functionality OR use a different design pattern (checkboxes, as a possible example to go instead of a select).

    While this doesn't cover everything, it does call out the frequent offenders that I see most often. If we can start tackling these issues, we'll find our websites often will work a lot smoother, and when we respect and follow native HTML functionality, many bugs we'd normally find will be less frequent in our code (use what works, and it'll work right?). But more important, we'll start making our sites more inclusive and available for all. And while it takes practice, there's no reason to NOT make our sites better.