Menu
The RESNA/RehabWeek 2019 Conference featured 3 packed days of sharing among people in the assistive technology field. Here are a few highlights from my experiences there this year.
This year’s RESNA conference was part of RehabWeek 2019
Continue reading “Highlights from the 2019 RESNA Conference”
2018 was an unusual, fun, and interesting year for Koester Performance Research. Here are some highlights of KPR’s work in the past year.
Wishing you all a Happy New Year! In the spirit of a new year’s energy, I took a look at KPR’s activities in the past year. 2018 was unusual, in that we’ve intentionally not been engaged in a large funded project, in order to leave some space and see what might take shape. One overarching goal this year was to share more of what we’ve learned and developed with the wider world. To that end, we revamped the KPR website, incorporated a blog, and set up new systems for communicating with people who are interested in what we’re doing. It’s still a work in progress, but has been enjoyable and seems useful so far. We also continued research, development, and service work within assistive technology. Read on for a few specific highlights.
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”
