Easy Design & Front-End Practices for Improving Accessibility

It’s a widely accepted truth that accessibility on the web is important. Of course, everybody should have equal access to technology! However, when it comes down to it and project timelines and budgets are at stake, it can be more difficult to put this belief into practice.

As technology continues to emerge and best practices continue to evolve, it can also be difficult to keep up–last year’s best practice may have already been discarded in favor of something else. In this post, I’d like to share a few easy ways that we can all improve web accessibility. 

1. Ditch the icon fonts.

The genesis of my post today was actually reading this post on SitePoint and looking at Seren Davies’ deck, “Death to Icon Fonts.” I’ve never been a huge fan of icon fonts. They always felt super hacky to me, and for the past couple of years, I’ve preferred using SVGs (scalable vector graphics) with polyfills for Internet Explorer 8 on projects where IE8 was still supported. Reading Seren’s deck clinched it for me. There’s really no good reason to use icon fonts anymore. Just don’t.

2. Check your contrast.

When doing visual design, make sure that the important elements of your UI contrast with their background so people with visual impairments can use your interface. Honestly, this should be considered a best practice anyway, especially when you consider how lighting impacts device displays. (Ever tried to use your phone at the beach?)

On my most recent project, we used Florian Schulz’s fantastic Sketch Color Contrast Analyzer Sketch plugin. You can’t make it any easier than that! For people who don’t use Sketch, this tool may help. (Disclaimer: I haven’t tried it yet.)

3. Use semantic markup, with ARIA roles where necessary.

Semantic HTML is important, and not just to show off how good you are at front-end code. Using elements the way they ought to be used helps screen readers. I always ask myself, “Is this content, or decoration?” Wherever possible, my position is that content goes in the HTML, and decoration goes in the CSS. (The :before and :after pseudo-elements can be super helpful here). Where you’re forced to use things in a non-standard way, ARIA roles can help. Two good resources:

4. Take a look at the A11Y Project’s checklist.

The Accessibility Project is a community-driven effort to make web accessibility easier. They’re doing a lot of cool things, including their checklist for web accessibility. It offers a number of easily-overlooked ways to improve the accessibility of your site. I’ll be incorporating it into my workflow for sure.

5. Reference the Web Content Accessibility Guidelines

For the average designer or developer, the WCAG can seem like an overwhelming read. It’s difficult to know where to start. Here are two portions of their website that provide good summaries of the guidelines and can serve as jumping-off points for those who wish to dig deeper:

While this article is by no means exhaustive, it shows some easy steps that can go a long way toward addressing common accessibility problems. In many cases, adhering to these guidelines benefits everyone, not just people with disabilities. What other techniques and practices can you share in this area? I’d love to hear more in the comments.

 
Conversation
  • Cole Jackowski says:

    Excellent list. I feel like a doofus for not knowing about the A11Y checklist, so thanks very much for mentioning it.

    As web applications grow richer on the client side, progressive enhancement is key to accessibility. It’s critical to start with a good, core experience for everybody and build features on top of that for people with the technology and/or ability to experience them. I worry especially that irresponsible or lazy use of some client-side frameworks and libraries that generate content programmatically will lead to unparseable, inaccessible websites and web apps.

  • Comments are closed.