My project is an app proposal/framework for an LGBTQ tour app that incorporates accessibility features to model that idea that accessibility is important in interpretive media that deals with the LGBTQ community.
NB: Presented below is my practically-final framework document but, as you might notice, no prototype. Why would a nearly-finished project come without the prototype? Well, long story short: the technology. But also the work in finalizing a working document takes quite a bit of time! So you will all see the prototype or sketches soon and for now my foundational document.
Proposal: a methodology and best practices for creating an accessible LGBTQ history app
Need and purpose: as a high percentage of LGBTQ people are disabled and the disabled are often otherwise unserved by mobile apps, making a habit of having universal, accessible design in these sorts of apps is imperative.
Discussion: Around a third of LGBTQ Americans are disabled, a percentage larger than the general non-LGBTQ population. In this statistic, a need emerges, and in the context of apps in the area of history and interpretation this need is acute. As a largely detail-heavy, often visual method, historic interpretation is an area in which the disabled population is likely to be left out.
Considerations made when creating a mobile app generally focus on making it as accessible to the general population as possible with as little extraneous detail as can be managed. Unfortunately, many of these extraneous details happen to be related to accessibility. Knowing that there are so many LGBTQ users that are disabled, however, it’s important to be aware of what is left out and what needs to be near-mandatory in any interpretive app. Unpacking the issue, the areas in which accessibility in an app, especially interpretive app, can be summed up in the following areas (not a comprehensive list):
Visual: limited vision, blindness, colorblindness, visual processing issues.
Auditory: limited hearing, deafness which can be determined by a Hearing Test, auditory processing issues.
Tactile: discomfort with vibration.
Cognitive: sensory sensitivity.
Mobility: inability to access interpretive sites, difficulty accessing sites, limited range of motion in hands.
The wide range of disabilities that can impact an interpretive mobile app may seem daunting at first and deciding upon your audience may make it tempting to start with a process that aims to make the app accessible after the fact. For example, the interface may be presented in a way that is engineered to be streamlined but artistically appealing, however, in these considerations the needs of the visually disabled are left at the wayside. Take a look at your favorite app right now. Does the app present on first glance an option for the blind like screen reading or voice commands? Is the color scheme usable for the colorblind? Are there unnecessary scrolling parts or transitions that might be difficult to process for some?
A framework for accessible app UI: in order to explore the process of creating an accessible interpretive app I began to consider the creation of an interpretive tour app focused on LGBTQ history in the Washington, DC area. The process was broken down into the following parts:
- Establishing the app idea and general functionality and initial layout
- Planning functionality and layout to incorporate base accessibility functions
- Sketching out both a layout and a flowchart demarcating the accessibility areas
- Focus testing the proposal with those with disabilities
- Applying focus test suggestions, then testing them with a second focus group
- Beginning work on the overall app
As one can see the first two steps are essentially the same but with one important aspect attached, the need to go back to the drawing board, as it were, included promptly after the initial planning. This is not an attempt to increase workload, but rather it is a method of acknowledging existing oversights in the UI process: generally, even the most attentive and aware will forget functionality that serves particular populations.
For the purposes of the proposed interpretive app, the core considerations align with a brief checklist:
_ Is opening the app easy for everyone (no unnecessary buttons, sounds, text, scrolling)
_ Does the app have methods for access beyond button push (voice commands, button input from external devices)
_ Is the app visually appealing without being inaccessible (color scheme fits the colorblind, fonts are bold and clearly identified)
_ Is the functionality capable of presenting information accessibly (various options for information presentation)
_ Is it fun
The process begins by filtering every decision through basic rules of design for accessibility. This effort is important to begin at the visioning stage of app development and can be summed up in a basic (but not comprehensive) way as such:
- The app should be navigable by voice command, screen tap, or external input (if possible)
- Buttons and other visual elements should not blend together, this includes in the case of being indistinct to those with colorblindness
- Any text should have a voice component and any voice component should have a transcript
- Alerts and notifications in-app should be gently tactile and on-screen in a noticeable way
- Customization of sensible functions like vibration and voice narration should be logical and simple
- Users should not be forced to use functions that are potentially not usable for them (for example, voice command functionality)
The next part of the process, implementation, is followed by another set of steps and consideration for use in the focus group testing:
- Is the focus group representative of the populations impacted by design elements?
- Is the app tested both live and for basic functionality?
- Are there scripts for specific live and functionality tests that can determine if all focus populations can access a specific function?
- How are the focus group suggestions to be assessed?
Finally, implementation of the suggestions from the focus groups should follow the following considerations:
- What is missing?
- Where in live testing is there the most difficulty?
- What functions are difficult or an obstruction?
- What functions are unnecessary for the app?
From there, app design should proceed.
Resources:
Material Design, Accessibility
UX Collective, How to make an app accessible?
Apple, Human Interface Guidelines – Accessibility
Android Developers, Accessibility Overview
Overall, this is an interesting and important topic and set of issues you are working on. I think the checklist you provided in this write up is a rather useful way to operationalize accessibility for the app. My one comment on the checklist, is that it might be good to add something in there about the quality of the material presented in the app and the ability for users with varied abilities to engage with and get the intended messages or effects of using the app.
You have presented a lot of good information for how to go about working toward this app. So all that work is great. Given the limited amount of time in the semester, a key thing for the rest of the project is going to be zeroing in on what deliverables you can get to as a final outcome. I think getting to steps 3 and 4 or your total of six steps would be a great point to get to where you would have something at a point where you could really show and talk through the results and outcomes of the work and thinking you have been doing on this.
One other thought, in reading your checklists and guidance in this post, it strikes me that you also have the makings of a great set of material to use for reviewing history apps. That is, doing a review of a few different apps and identifying how they are and are not accessible could itself be a neat future direction for the line of work you are starting here.