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 […]
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.
There are three key issues that are simple to solve, but easy to miss without testing.
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.
The WAVE tool offers other possible solutions to these issues so you can identify the best solution for your application.
This is the one I found most painful. For federal projects, it is currently required by 508 standards 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.
Many agile teams treat 508 compliance as an afterthought. Teams typically build the product then...