Month: October 2024

When it comes to writing code that supports accessibility, there can be multiple ways to solve a problem. The industry has worked hard to standardize interactions so that component types function the same across environments. But, it avoids being dictatorial in how to remediate a given problem by only providing generic code samples.

Likewise, when we conduct accessibility audits, we will face user experiences that do not make sense to us. Nevertheless, the client is invested in these experiences. Perhaps the client has limited bandwidth to do remediation. The complete and proper resolution can be more than the client can get done in a reasonable amount of time. Yet, we want to help them achieve an accessible solution sooner.

In these cases it isn’t always appropriate to tell a client they need to completely change their code. Sometimes the solution is a small modification. Let’s examine a recent situation I encountered. A modification can fix the problem, even if the ideal remediation is a code change.

My client presented a website with some filters at the top of a table. The client initially coded the filters as multiple buttons per the design team’s layouts. Each button filtered the table in a different way, and only one filter can be used at a time. You can also have no filter applied. Upon examination, these buttons were properly constructed, but missed a state attribute and aren’t grouped.

I can justifiably tell the client to remove the buttons. They should replace them with radio button elements instead. Then, restyle them to look like a button grouping with one pressed. For no filters, we’d offer up a “Unfiltered” choice. And this will certainly fix things. In the long run, I want the client to follow this plan. It’s the most complete solution.

This change means the client needs to dig into their JavaScript. They must find the code related to the filters. Then, update it to respond to radio buttons instead of button elements. The client’s front end team will need to write new CSS and HTML. But remember they have limited resources, and we need them to fix things as soon as possible.

How do we help the client meet their goals?

There is another perfectly valid way to fix the problem. I can coach the client to add the aria role of “group” to the wrapping container. They should also add aria-pressed to the active filter button. This informs assistive technology that these items are related. It also fixes the state issue where we don’t know which filter is active. This solution takes roughly 10 minutes to fix, where the full remediation to proper radio buttons will take significantly longer.

The simpler recommendation may allow the client to fix more issues with the resources they have. Every step is a move towards better accessibility. Take the time needed with your clients to understand their current situation and needs before writing your recommendations. Don’t be afraid of offering up a “quick fix” for a client, as long as it actually fixes things.