Menu
Using third-party code, such as Bootstrap, Google Charts, shopping carts, and the like, to boost your website’s functionality is powerful and often necessary. But it can also introduce some accessibility problems, and those aren’t always easy to fix. Here are some tips on dealing with these issues.
This is the third in our series on testing and improving the accessibility of KPR’s websites. Previous posts focused on how we conducted systematic do-it-yourself accessibility testing and how we fixed the accessibility problems we found. Some of the toughest challenges involved dealing with third-party code. This post presents the main problems related to third-party code and gives some details about how we fixed them.
Continue reading “Web accessibility: challenges with third-party code”
We recently tested the accessibility of KPR’s websites. Here’s an overview of what we found and how we fixed it. Spoiler alert: tests revealed some major web accessibility issues.
We’ve been working on testing and improving the accessibility of KPR’s websites. The first step in this process was conducting systematic do-it-yourself accessibility testing, which we described in an earlier post. This post presents the main problems revealed by the tests and gives some details about how we fixed them.
Continue reading “Web accessibility testing: what we found and how we fixed it”
We recently got serious (finally) about testing and improving the accessibility of KPR’s websites. Here’s the recipe we used for our DIY accessibility testing, somewhat informal but quite effective.
This post is the first of a series focused on our web accessibility initiative. As a company that develops software, including websites, KPR has a responsibility to make sure that those sites and applications are accessible and usable to all users, regardless of disability. And, given the focus of our work on enhancing accessibility for computer users with disabilities, we have an extra imperative to get our web accessibility house in order. We’ve learned a lot through this process and hope that sharing some of those lessons here might help others who want to do something similar.
The first step in the process was to define a procedure, a recipe, that we could use to test the current state of accessibility for all of our websites. This needed to be something we could do ourselves (DIY) in a reasonable amount of time while still yielding good information about accessibility problems. I’ll share our DIY accessibility testing recipe in this post, and we’ll look at the accessibility problems we found and how we fixed them in future posts.
Continue reading “A recipe for DIY web accessibility testing”
