To Build Accessible Tech, You Must Be Adaptable

If you’ve ever seen a wheelchair lift tacked onto a building like an afterthought, you know that adding accessibility after something is already built doesn’t achieve the desired effect.

In tech, adding accessibility at the end of a project can have similarly uninspiring results — and often involves a lot of work.

That’s why for tech leaders, and especially those working on applications for governments and utilities, it’s hugely important to approach accessibility as both a starting point and an end goal. It ensures outcomes that serve the entire population and gives developers and designers the kind of constraints that can yield inspiring creativity.

What Is Accessibility?

Accessibility in a govtech context has two components: the technical side, addressed by Section 508 guidelines and Web Content Accessibility Guidelines (WCAG), and the less regulated side, which involves building technology that’s both accessible and highly usable.

Technical Accessibility

Federal government websites are required to comply with Section 508 guidelines. These guidelines, and those laid out by WCAG, set measurable standards for web properties.

Some federal accessibility requirements for websites include labeling hyperlinks to indicate where they lead (i.e., not, “click here”), using high-contrast colors for people with impairments like color-blindness, and making content available in multiple formats — for instance, audio content must also have a non-audio component.

Taken together, these technical accessibility standards ensure that everyone can get to the information included on a website.

Accessibility as Usability

Usability standards are less regulated but no less important. They determine whether a person can really use a website in practice, going beyond technical requirements.

These are a few of the guidelines that we consider to be a best practice:

• Don’t use flashy images or unnecessary videos. Many people access websites from their smartphones. Large image and video files eat up a lot of data and take longer to load, meaning sites that incorporate them might be out of reach for users with limited data plans without a trip to the library.
• Write content at a sixth-grade reading level. Your audiences will be diverse in age, English fluency, and reading ability. Sometimes families who speak English as a foreign language will have younger generations help navigate websites to acquire necessary information for the whole family. Keeping vocabulary simple helps fluent children translate easily.
• Reinforce text with icons when possible and appropriate. Using meaningful imagery like icons supports scannability for all users, and it especially helps clarify content for people who have lower literacy skills.

In a diverse city, technology should meet both the technical standards for accessibility and additional guidelines for usability. If it doesn’t, cities risk alienating large portions of their audience.

Accessibility as a Starting Point

When developers approach a project with the intention of building something that is universally accessible and usable, that “restriction” can actually spur a lot of creativity.

To use our hometown as an example, Chicago recently developed public space along the Chicago River. The Chicago Riverwalk is set down from the street and features both stairs and ramps — and even seating, greenery, and attractive lighting — leading from street level to the bank. Because space was designed to be accessible to everyone, the ramps are highly functional: people on bikes, pushing strollers or using walkers or wheelchairs all benefit.

In tech, starting with the goal of building something accessible is a challenge — but it can be a fun challenge. To achieve that goal, it’s important to do two things:

1. Make sure designers have constraints up front. Understand all the possible limitations of your audience (in govtech, this can take a lot of research to understand the full scope of your constituents) and how to accommodate those limitations.
2. Test early and often. Get actual users to interact with your designs. Adapt technology and update constraints as you identify scenarios you didn’t initially consider (trust us, there will be things you didn’t consider).

Updating your constraints as you test is a good thing. It’s much more effective than waiting until you’ve built something in its entirety to realize that you forgot, say, to make a web property workable for keyboard-only users, which is how some people with vision impairments access websites.

Accessibility as a Moving Target

As much as it can spur creativity, working with constraints may also be frustrating. That’s why it’s important to make sure that developers have a big-picture understanding of what they’re building and why.

It’s also important to understand that accessibility is not a static state, mostly because the technology we use is not static. You could build every page of a website to be visible to screen readers, for example, but if a browser changes its screen-reader technology, you may have to adjust your code. Building a site that is easy to modify will make it adaptable to new technologies and new standards of accessibility, ensuring a positive experience for everyone as times change.

Our Experience: Accessibility in Payment Kiosks

When our team set out to develop payment kiosks for local governments and utilities, we were excited at the prospect of improving access on such a fundamental level. For one thing, kiosks on their own are a tool to make paying bills and debts easier. They provide a 24/7 option of cash payment to constituents who can’t visit a payment center during the workday or who don’t have credit cards to pay online.

To make the software as accessible as the hardware, we went through a few iterations. When we were developing our kiosk 2.0 platform, we brought in researchers from Purdue University to conduct usability testing.

Their insights helped us formalize several key principles:

1. Keep instructions clear. Use icons, high-contrast visuals, and clear, simple sentences for people with low literacy skills or vision impairments.
2. Use consistent action buttons. Buttons that use the same colors and are placed in the same location (from one screen to the next) help people learn the system as they go.
3. Show users their progress. Progress bars help people understand how far they are in the process, and when they are almost done.
4. Confirm successful transactions. Validation screens let people know for sure that their payments have been accepted. This is especially important for first-time kiosk users who are unfamiliar with the process.
5. Reinforce text with images. Where possible, our user interface includes commonly used icons. This makes directions familiar and intuitive for customers.

These guidelines make for a better user experience for everyone.

Our Takeaways

We’ve learned that creativity, consistency, and adaptability are key to building accessible technology.

It’s important to understand user challenges up front, and be creative and thoughtful in solving for them. Create standards for yourself that both meet and exceed legal accessibility guidelines, and then be consistent in how you apply them throughout your build. Be ready to evolve and adapt your product as technology advances, and as you learn more from your users about what they really need.

By staying in tune with your users, and firm on your standards, you can create technology that’s truly useful to diverse audiences.