4b. Or, work with developers to make sure the code augments the design.

There are outlier cases where the strategy presented in 4a can contribute to a poor user experience. In this case, the solution may lie with your developer(s).

As an example, one of the City of Austin sites I worked on required us to display a list of forms. Each form had an associated downloadable PDF. Our first thought was to use “Download {Form Name}” for each button. However, after looking through the length of the form names, we realized that this format would create huge buttons with multi-line text that would negatively impact our UX.

We decided to instead use “Download” as the visible button name for all of the forms, while also making sure the code would correctly use “Download {Form Name}” for screenreaders. This method supports accessibility, but applies a different approach to make sure the visual design isn’t impacted.

Design for All

Before the beta launch of one of our City of Austin sites, we did usability testing with someone using a screenreader. The way he spoke with our team about the importance of incorporating accessibility into design is now something I think about every time I begin a new project:

“Why would you want to make something that some people can’t use?”