In the tech world we are familiar with the concept of the MVP, or the minimum viable product.
The MVP is "a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product" - productplan.com
In practice, the MVP is the most basic version of your app idea. The idea is to make this version as quickly as possible so you can get feedback from your users and start iterating with a new version.
This same concept can be applied to your journey to make your app more accessible.
Introducing the Minimum Accessible Product (MAP)
The MAP is the Minimum Accessible Product. It is the first version of your application which can be considered "minimally usable" for those using assistive technology, such as screen readers and switch controls.
Just like the MVP, its goal is to get an accessible version of your application in the hands of users who use assistive technology, to give feedback and start improving rapidly the accessibility of the app, past this minimum level.
Focusing only on the main user flows of your application, it allows assistive technology users to complete the most important tasks in your app. This does not mean that it was easy to accomplish, or that they didn't struggle a bit on the way, or it didn't take them twice as long as it should have to complete. It just means that completing this task before your MAP was so frustrating that the user left your app to try your competitor's app. After your MAP, the accessibility has improved enough where the user's level of frustration is bearable, and the user may stay.
Exactly what frustrations are we eliminating for users in our MAP?
|Some UI elements were missing labels, so the user had no idea what was present on the screen.
|All UI elements have a clear label, so the user knows what is on the screen.
|Ordering and Grouping
|UI elements weren't ordered or grouped. The focus seemed to be bouncing all over the screen, giving the user whiplash.
|UI elements follow a natural reading order from top left to bottom right, and are grouped based on their content. Scrolling through elements on the screen is organized and easy to understand.
|Dynamic Text Size
|Text didn't adjust to the user's preferred text size, so the user was forced to zoom in and struggled to read.
|Text resizes based on the system settings, making it easier and quicker to read.
|The contrast was so low that it was difficult to read text.
|The contrast meets the minimum recommendations of Apple/Google/WCAG, so most users can read without difficulty.
|Buttons were too small for users to select.
|Buttons meet the minimum size recommendations of Apple/Google/WCAG, so most users can select them without difficulty.
|Some UI elements that allowed interaction didn't describe the possible actions to the user. The user didn't know what to do with this element, and may have gotten stuck.
|All UI elements that allow interaction are marked as "interactable", and setup appropriately, so the user knows what actions are available and how to perform them.
|Errors and Instructions
|When entering information in a form, there were no instructions for the required format, and error messages were vague.
|All text input fields describe the format required, and error messages are specific and helpful.
|Media content (videos and audio) in the application did not have text captions or a script available.
|All pre-recorded media content has text captions or a script available to read.
This list can change depending on the specifics of your application. In general, though, eliminating the frustrations in this list will bring your application to the Minimum Accessible Product level.
MAP v. WCAG
You may be wondering how this MAP fits with the Web Content Accessibility Guidelines (WCAG). There are many similarities, as the idea of the MAP is based off some of the Level A success criteria of WCAG (Level A is the first level of minimum compliance. It continues to Level AA and Level AAA).The main difference is the MAP focuses only on the main user flows of the application, not the application in entirety.An MAP would not check all the boxes for WCAG Level A because there will be screens and actions outside of the main user flows that are not compliant.I encourage you to research WCAG and their success criteria for all levels (A, AA, AAA) as you iterate from your MAP to make your application more and more accessible.
To bring things to a close, remember that the MAP is the Minimum Accessible Product. It is the minimally usable version of your application for those using assistive technology. Similar to an MVP, its goal is to get a minimally accessible version of your app in front of assistive technology users to get their feedback quickly. With this feedback you are able to start iterating into new versions of your application that are more and more accessible.
The MAP focuses on removing frustrations on the main user flows of your application, so users aren't so frustrated that they uninstall your app and try another. Making an app "minimally frustrating" is never the end-goal; There's still a lot of work to do after your MAP to improve the accessibility of your application. The MAP is just the beginning.