Helping to build and release the open-source Accessibility Theme Builder project has been a fun, challenging, collaborative and innovative journey. The project provides tooling to promote accessibility, making it easier to build and maintain products which are usable by as many people as possible.
This blog post highlights the journey we took to build and open source the Accessibility Theme Builder project. Our hope is that as you read about our journey, it will spark some thoughts about how you might take a similar journey--or journeys--related to your areas of expertise and therefore promote increased innovation, especially around accessibility and inclusion.
Our journey can be divided into four phases: ideation, patents, code, and community. It is important to note that these phases are not serial, but we think it is helpful to discuss them in this order.
Ideation
First, ideation is the brainstorming phase in which you get together and talk about your ideas, sort of like throwing things on the wall to see what sticks. In this phase, you are always thinking from the perspective of one or more personas, trying to put yourself in their place to understand pain points and real needs and about how you might address those pain points and needs.
In our case, a co-worker—a designer but not a developer—had already written a prototype of the Accessibility Theme Builder application; however, the prototype itself was just written to get some ideas across but did not meet all the needs of our personas (designers, developers, administrators, etc.).
For example, we knew that the tool needed to be as easy to use and share as possible by multiple designers and developers, so we decided that it needed to be hosted as a web application.
We also knew that it needed to be usable by administrators or other personas in potentially non-interactive ways, such as in toolchains by devops engineers; therefore, we decided to provide the bulk of the accessibility logic in an SDK (Software Development Kit). We chose Typescript as our language of choice so that it could be called inside a browser and not just server-side.
While the prototype established a very intuitive interface for users, it was not easy to learn the code structure or to maintain it. This would make long-term support difficult. So, we chose to re-implement the interface using ReactJS, breaking the code into easily digestible components that can be extended over time. One of the first extension points that we defined was for storage, allowing for server-side or local persistence. We also anticipated that the tool would need to be extended to serve more populations facing accessibility issues and, with this in mind, architected and documented the code accordingly.
And once this tool was eventually built, what would be its fate? We were a small team that was not built for long-term support. Plus, this tool has the potential to help not just our end users but the end users of any application looking to be accessible and inclusive. So, rather than looking toward an internal support team or inner sourcing the code, we looked, for the first time in our company's history, to release the code as open source.
Patents
Ideation naturally flows into patent ideas. When you take time to consider various personas and do this in a collaborative way, patents can naturally come from that activity. And protecting the intellectual property of our company (and yours) is very important. In addition, patents are important in open source because they can assist with ensuring that a project does not infringe an existing patent. So, we were able to file several patent applications because of our ideation activities.
Developers have a natural tendency to rush ahead with the coding, but pausing for research helped not only the patent process but also gave us assurance that we were not reinventing the wheel or creating something too specific when a more general, reusable solution would be better. More general solutions may be slightly harder to implement, but often can be easier and typically result in less and more elegant code. The benefits of reuse often outweigh the cost, and the result is a more elegant design which is less likely to have to change later.
In general, spending the time to consider what is patentable and writing up patent applications has several advantages:
- prevents you from re-inventing the wheel
- encourages generalization and promotes reuse
- forces you to spend more time on design
And yes, working on patents also has the added benefit in that our company, like many, rewards us monetarily for patent submissions.
Code
As a developer, writing code is what we enjoy, but it was important that we work well together as a team in an agile way.
Before open sourcing Theme Builder, we needed to write the code. So, we created two GitHub repos:
- one repo for the SDK
- one for the ReactJS UI application
To manage the project, we used GitHub issues and a Kanban project board in the application repo for a combined view of both development efforts.
Once the structure and process were in place, the task of rewriting and refactoring the prototype could begin. To complete the code in time for a hackathon we were hosting, our team went into full-court press mode. Daily scrums were scheduled to track the rapid pace of development and to coordinate SDK and UI dependencies, since both were being developed in parallel.
Documentation of the tool was also an important deliverable for the hackathon. After all, the hackers needed to be able to quickly grasp the accessibility concepts and application design, so they could either use or extend the Theme Builder for their project. We used GitHub pages and MkDocs to create and display the docs for the users. We also used GitHub actions to create a workflow that automatically published any updates to the Markdown doc files. You can view our current documentation in our GitHub repo.
Community
After we decided to open source the code, our possibilities felt endless. Along with possibilities was a lot of extra preparation on our part to do an open-source release, which ran parallel to our development efforts. We needed to envision how this tool could thrive without our team's focus. It is important to spend time thinking about and planning for the eventual community that you hope will grow around your project. Because there are so many communities out there vying for what is often pro-bono participation, the barriers to entry for YOUR community need to be as low as possible.
The first hurdle we crossed was to select the license that would govern the community. Our solution was created in a sizable financial products company, so we thought it made sense to reach out to our community of business partners and other companies in the financial sector who face similar challenges. We chose a license that was friendly to companies with intellectual property concerns and a low tolerance for risk.
After we identified the types of developers that we hoped to involve, we needed to spread the word about our project to attract their attention. We were already part of the FINOS consortium, so we advertised our effort amongst our fellow members and people who follow FINOS news. But awareness isn't often enough to drive interest.
One approach that we considered early on was to sponsor a hackathon. Friendly competition, a feeling of doing good, and a little monetary incentive would, we thought, bring eyes and more importantly, focus and ideas to our project. We were able to partner with other co-sponsors and a hackathon management team to create a hackathon that attracted 79 teams with participants from 27 countries. The hackathon provided education sessions and workshops available for all participants. As the hackathon concluded, we invited all participants, who now have quite an understanding of our application and its potential, to participate in our community. Our community is open to all who have a passion for accessibility and inclusive technology, please consider joining!
Conclusion
Innovation is important, fun, and satisfying. Few people like to be overwhelmed with too much process, but too little process hinders innovation.
We hope that you have enjoyed hearing about our journey, and we encourage you to consider these categories in your areas of expertise: ideation, patents, code, and community. We believe that you will find, like us, that it will spark and ignite a free flow of innovation and make your project journeys increasingly productive and satisfying.
Authors' note: Since the writing of this blog post, the Accessibility Theme Builder project was accepted by FINOS as an incubating project.
