Requirements Gathering meets Accessibility Needs


“We are all only ever temporarily Not Disabled”

Life as a Business Analyst during the requirements gathering phase is always an interesting time. You are the one person who must remain impartial to choices, neutral to a solution and unemotional to the pain points stakeholders may have. You must also don many hats and adopt many points of view; one day you are a marketeer, then a payment processor or even a member of the onboarding department. Being sure also to never forget the many governing factors concerning your project, such as company compliance guidelines, government legislation and of course, budget constraints.   

Like most of the world we live in as Business Analysts the above was not something I learned overnight, it was an iterative process. With each project I learn something new, with each company something new again and it would be foolish of me to ever think that this process will end. Being an analyst is a lifelong commitment to change.

Enter a new project, a new challenge and a new learning. 

I have recently been working on a Government project, my first experience with a Public Sector client. The project itself was to be a 6-week Discovery phase looking to establish the AS-IS of a current system, and present back to the client, options for a future solution. I approached much of this work in the same way I always have; I engaged in workshops, held interviews, conducted shadowing sessions and so on. 

The main difference to a private sector client was the checklist of areas that we had to consider as part of our work to meet with the Government framework for Digital Projects. The framework ensures all work carried out by different companies remains uniform, but most importantly represents the needs and wants of the entire population, after all we are designing systems that could be used by any person who lives in the UK. 

One of the bullet points in this checklist was for accessibility needs. Accessibility is something I am guilty of having never given enough consideration to during requirements elicitation. Until now I have never thought about putting myself in the position of someone with additional needs and shame on me, as 1 in 5 people in the UK are affected by a disability that leads to Web Accessibility requirements. So, I decided to seize this learning opportunity and ensure I was skilled up going forwards. I was then very fortunate to find the Home Office were holding an ‘Introduction to Access Needs’ workshop as part of a practice run for a European Conference covering the same topic. 

The workshop was extremely informative and well structured. As well as covering the requirement for accessibility needs, we also learned about the different types of need and were able to experiment with apparatus that replicated a specific disability and use some of the tools designed to provide the assistance required.  

The ethics behind accessibility is possibly not something you have considered before. I think many would categorise an accessibility tool as something that; ‘makes life easier’, for a disabled user. However, what we should be taking into account when designing new digital platforms is how to make sure that every single user has the same experience. This is actually a very key point as we are not even specifically talking about disabilities here.

Have you considered mobile users vs web? IOS vs Windows? Online vs Offline? These are all possible different users of your system and all deserve the same experience. It may well be that a lot of these points are non-functional requirements that come later in the development, but if you make sure you are considering them at the start, you can save yourself a lot of time and effort in the future.

So now we have the right mindset when thinking about accessibility and disabilities. A key quote from the workshop, “We are all only ever temporarily not disabled”. Over half the population over the age of 65 experience a disability of some sort, so it will happen one day if we are lucky enough to reach a mature age.

So, what disabilities do we need to consider? Some examples include visual impairment, colour blindness, impaired hearing, dyslexia, dementia, autism, loss of limbs, mobility issues and the list goes on. Within these groups there is also a wide spectrum to consider. It is not simply 20/20 vision or blindness but a whole world in between. Another key takeaway from this session was the introduction of temporary disabilities. Maybe you have a broken arm for 6 weeks or even just find yourself in a loud space; have you ever used subtitles because it is too loud to hear? If the answer is yes, then you have also experienced a temporary user access need.

“For something to be accessible someone needs to be able to complete the task they are trying to achieve without encountering a barrier or issue.” So, what are the characteristics to consider to ensure that we meet this brief when designing a digital service:

  • Perceivable
  • Understandable
  • Operable and 
  • Robust.

The first two points are focusing around information. The user must be able to perceive the information they need, that means it should be available to one of their senses be it sight, hearing or touch. You should not isolate one group from accessing information available to another, for example if information is displayed as text then a screen reader should be able to convert it to speech. When we think about understandable, we must consider those who struggle to process text, let’s take dyslexia as an example. We should keep copy brief and to the point and avoid alienating language and using large bodies of text which could be overwhelming for the user. 

The second two points focus on usability of the system. It must be operable, if someone is using a keyboard or even no keyboard for example, they can still do everything that someone using a mouse can do. This includes being able to navigate the website, use forms to provide information and use controls such as buttons. The service should also be robust so that technology being utilised by a user works as it should every time, such as a screen reader.

Requirements Gathering meets Accessibility Needs

All of the above must be in place to help a user achieve the goal of completing their task. More information on these principles can be found at The World Wide Web Consortium (W3C) is an international community where Member organisations led by Director Tim Berners-Lee, work together to develop Web standards. W3C's mission is to lead the Web to its full potential.

Luckily there are many different considerations we can make during the design that can help us reach our goal of an achieving an equal experience for all. We have come a long way from simply making text size larger on screens and the expanding the list of devices available to help users interact with online services which is refreshingly. There is also now a wealth of information including helpful articles to assist you in asking the right questions and optimising online platforms to deliver a positive and equal experience to all users, I have included some of these links below:

If you want to ensure that your website is inclusive to all users, you can test it using to see how it currently rates in terms of access needs. You may be surprised to find that your site is alongside some of the most popular websites that are still underperforming in this area. A poor accessibility press article can have hugely negative effects on a company’s reputation as evidenced in this article about Domino’s pizza here.

As a Business Analyst, I hope you have found this article helpful or it has at least made you think a little more deeply around a potentially throw away term or design after thought. You may want to ensure that during your next requirements gathering session you ask the question or even go out and meet some of the people affected by a badly designed system first-hand. It is really important to understand our end users and their needs to help deliver the best possible solution for all and to support a more inclusive society where others are sometimes needlessly left behind. 

Author: Jake Horton, Business Analyst

Experienced (SC Cleared) Business Analyst with a demonstrated history of working in the financial services, FINTech and Public Sectors. Delivering Business change, Specialising in Process Improvement and Incremental Delivery. Have experience in various Scrum Roles including SM and PO.

Organically trained after a transition from Instrumentation & Controls technician with ExxonMobil to a Business Analyst whilst helping them with process optimisation activities on their Fawley Refinery.

I now live in London and have worked with a Fin Tech before joining 6point6's Tech Consultancy firm to help grow out their BA function.

Like this article:
  29 members liked this article


Charlene H. posted on Wednesday, October 16, 2019 10:04 AM
Jake - Great article! I am a BA working for New York State government for 27 years, and I feel that I have to preach this daily; people still look at me like I have 3 heads and agencies tell me "we've never done that before, so why do we have to do it now?"
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC