I need to preface this reflection by addressing one major flaw in my idea, something that may prove a warning to potential app designers: a project like this is time consuming. Each area of disability that your app may address is as important as every other, and having a fully-featured and usable app that doesn’t leave people out is a difficult task. That said, it is absolutely important. There is no reason a population should be left out of public history’s efforts to interpret their world.
With that said, my reflection.
Starting: I’ve been working on this idea for the better part of the term, and the second hardest part of the whole process was knowing where to start. There are a lot of design methodologies out there, but as my resource listing in my final project document shows, there are few that are actually relevant or worthwhile to a project of this nature. A lot of reading for a project like this is futile, simply reading a basic document that offers no rationale or backing to the reasons for its lessons, and even more frustrating, lessons and design tips that are actually counter-productive. In one case, a design tip offered suggested that app colors tailored to the color-blind should be black and white, ignoring the wide range of forms of color-blindness.
Expanding my research, I looked at actual apps I use each day to determine if they were actually usable by the disabled. Zero had legitimate features for the visually impaired (blindness, color-blindness, visual acuity issues), several had voice commands but offered no list of commands, none had image alt text or transcripts of text (except games, all of which have subtitles). It did not provide any hope but it did offer encouragement.
Identifying the needs: the assessment of needs for the app was a very thorough process and largely focused on two areas: features that help and features that hinder. Breaking down disability into primary areas, feature assessment was an A/B process: for low sight users, for example, what helps is a voiceover feature and what doesn’t is un-tagged, captionless photos. The needs, once broken out, made the itemization of features less difficult.
Identifying the who: after taking a scientific approach to the app needs, it was important to look into the human side. Looking at what disabled users want and need, determining the form and nature of focus groups, and determining what level of input they would have, was a careful process. On one hand, responsive design requires user input, but on the other hand, this was input prior to actual design and programming. Visioning may be a good word for this part of the process, but a more precise term would be laying the groundwork.
Creating metrics for success: before design, it was also important to be aware of what a successful app would do. Knowing the basic features, finding a basis for what a successful app would do was easy: it would offer as many people as possible access to interpretative histories of the target area. That leads to another metric for success: how does the app respond to the needs of diverse disabled populations? A well-programmed app would need almost no after-the-fact input to improve usability, or, at the most, additions of disability areas that do not fundamentally alter the design of the app.
Tools created for implementation: As the final document details, having a process is important, but having checkboxes is even more so. It is one thing to include addressing the disabled population in your design process, but entirely another to ensure they are included as an actual design goal. Furthermore, having a sample flowchart that shows the practical ease of sketching out the end product is a great starting point for designers, even if the flowchart only shows opening features of the app.
Final reflection: throughout this process I have become increasingly aware of my own limitations and what would help or hinder me in using an app. Early on, I had determined that triggering the app’s tour features when in proximity to a tour site was important, but as I myself reflected on my difficulties reaching locations in major tourist areas, it became more important to have clear and detailed lists of these sites. Early on, it did not occur to me that having a voice command feature needed to be featured as equal to the other features, but instead was a bonus: I can’t speak, however, so why would a voice command be an extra added bonus? Finally, speaking and scrolling speed of assisted touring features like voiceover and transcripting was something I did not consider.
As I’ve stated, with 33% of the LGBTQ population having some form of disability, it is important that community-related apps are accessible. And not just accessible, but assistive and adaptable. Utilizing these three principles, Accessibility, Assistability, and Adaptability, the underlying process of creating the app became one that was mission-oriented rather than goal-oriented. It isn’t enough that an app be working toward a goal of being open to all, it should also be working toward the mission of making disability a common and regular concern of the programming community. Disabled people should have access to history, and apps in general, and it is vital that the process be done in a considerate and meaningful way.
