Minimum Viable Product vs Accessability

This post covers my thoughts about including extra information in a website/app, such as wheelchair access. Such things should be included but with reduced resources how do you handle it. This post is written as much for my benefit as anyone else. I have been reading a great deal from Peter Gasston and his writing about thinking resonates here.


The current situation is that I have a solid demonstration website with most of the features required in place but with a few omissions. Most notably there is no route finder. Included is a tube only and full suburban version of the map. These two version have a different set of interchange symbols to deal with the fact these two maps have different sized stations. These stations then require different positions for text labels. In both maps name labels could need to move again to show disabled information, creating four possible locations for the text. The zone boxes that surround some station text could also have to occupy one of four positions. 

This bulking out of code and features is a resistance to further progress. It was also increasing the size of the page to the point where it would have reduced performance on mobile devices. These features had grown so rapidly in a large part due to feedback from various backers and I had tried to implement as many as possible as quickly as I could. 

Now I am developing an app and it needs to be streamlined to work yet I want all the current interactivity and possibly more. Adding all of these features to begin with is completely opposite to the Minimum Viable Product (MVP) principle. The focus of MVP is to develop the minimum product which can then start generating feedback. This feedback dictates which features you prioritize adding. For a more in-depth discussion see this lean start up page

This method is particularly valuable to small teams and they don’t get much smaller than my team of one. The issue is that the majority of users will not be requesting disabled access information. For this reason it would be easy to neglect the accessibility question. 

However I have come to a few principles of development to balance these two.

The first three points are reasons to not get caught up in accessibility details and as long as the fourth is also observed then I see this as a reasonable logic to advance with.

What does this mean for the development of my App?

Following thinking I have loosely grouped all the features I would ‘like’ to include into rough groups of importance. The app is being developed around these points in the order that makes most sense to code. It will be considered out of development when everything useful and above is included.