3 Tips for Addressing Accessibility with Your Ruby Web App

A week ago, I got back from my first RubyConf, a three-day event bringing together Ruby developers from around the nation. On day two of the conference, I did my first lightening talk ever on a Ruby adjacent topic covering Accessibility issues and what we can do as developers to make web applications more accessible to users with disabilities.

At Excella, I work on a modernization project for the United States Citizenship and Immigration Services where accessibility compliance is required under Section 508 of the Rehabilitation Act of 1973. As part of our definition of done, my team strives to make sure the user experience is 508 compliant and that we are testing functionality as we build it.

Beyond the legal requirement, I argued that as developers, we want to create applications that are functional and usable by all our users. Yukihiro Matsumoto — the author of Ruby — created the language with goal of making developers happy. As members of the Ruby community, we try to pay that forward by staying open and empathetic to the needs of our user. And by keeping accessibility needs in mind from the beginning, we can reduce the burden of trying to incorporate these measures later. Here is a brief overview of the three quick and dirty tips I offered to take care of many accessibility issues you might find in a web application.

Tip #1: Manually Test Your Application

There are three key issues that are simple to solve, but easy to miss without testing.

1. Include a skip link: Websites or applications with repetitive links at the top of the page should include a skip link allowing users to skip the repetitive links and go straight to the main content should they choose to.

2. Look for keyboard traps: This compliance issue occurs when you are tabbing through the site and are no longer able to find where you are. Test by putting your mouse away and navigating through the site with just your keyboard. Solutions for keyboard traps can vary, but make sure you identify them. You could convert elements that are not triggering focus into links or include a tab-index of 1 to capture keyboard attention.

3. Test for a loss of focus: This happens when the visual cue such as an outline on an element is not visible to users. This outline is usually a default browser behavior, but overriding CSS can remove it. For those using the keyboard, it is key to keep these in place so they know where they are within the site.

Tip #2: Use an Automated Testing Tool

There are many tools available for testing. On our project, we use 508 specific tools in Internet Explorer and Firefox. For quick evaluation on the go, we use the WAVE Chrome Extension tool. This tools provides a lot of feedback and offers suggestions on how to fix those issues. For instance, contrast issues arise when the ratio between foreground text color and background color is less than 4.5:1. This is an accessibility issue for those with limited vision or who are colorblind. The tool tags the problem giving you a score of pass or fail as well as feedback on the contrast ratio. The tool also provides a mechanism for identifying a darker or lighter hex value for either the foreground or background color, helping the developer easily identify a compliant alternative.

The WAVE tool will identify missing html attributes that can make our applications more accessible to screen readers. Alt tags on images, for tags on labels, title attributes on elements that don’t need a label – these details are necessary for accessibility.

• Alt: Keep it short and meaningful. Relay the information that appears in the image.
• Title: Keep it short and meaningful. Any information included in a title attribute must also be available on the page.
• For: Applied to the label and identical to the id of the input you’ve labeled.

The WAVE tool offers other possible solutions to these issues so you can identify the best solution for your application.

Tip #3: Turn Off CSS

This is the one I found most painful. For federal projects, it is currently required by 508 s­­­tandards that the content of the site be logically organized without the benefit of a style sheet. This can be a frustrating requirement for developers, especially if you are showing or hiding content using CSS. It is a good practice to run through your application with CSS turned off to understand how information appears to users who may turn off CSS for accessibility reasons.

Accessibility is a complex issue, one that is constantly changing and adapting to the technologies we use. I recommend additional reading at through the World Wide Web Consortium (W3C) or the GSA’s resource on 508 Compliance. As developers, we can keep these issues in mind to develop better products with functionality to serve all our users.