Could Accessibility Be Our New 4th Amigo?
How to make shifting left with accessibility easier and more inclusive.
We hear it all the time, ‘does anyone have a checklist for a11y because as a QA I have been asked to implement it’.
Note: (a11y is short for accessibility: a+11 letters+y )
Whilst this is a valid question, and we can indeed have some kind of QA checklist (usually compiled from the last person who asked the question and didn’t get a response)
Accessibility should be much more than this. A checklist implies it’s something we tick off towards the end of the project, and then guess what, as we approach the deadline and we maybe have to do a risk-based analysis on what we could do without, accessibility is usually the first thing to go, I know, very sad!
It doesn’t have to be this way though. Accessibility shouldn’t be a checklist, it should be a mindset.
It should be part of our conversations when we start a project. It should just be part of our normal everyday language when we talk about requirements and acceptance criteria. It should be considered when we write BDDs and agree on what should and should not be developed and subsequently tested.
This is why accessibility should be our 4th amigo!
When we enter our usual 3 amigo conversations about tickets, we all agree it is important to have at least 3 people in there. A Product/ Business/ design person, a developer and a QA/ Automation person (depending on the make-up of your team). This is because these conversations require the unique perspectives of all of these people to ensure all bases have been covered when writing our ACs.
This is just as important when considering a11y.
A designer can make something more inclusive just by the way they design it. Page flow is the best example of this, and is of the utmost importance to accessibility. Creating something a user can navigate quickly and easily should be a top priority. For example, there is no point in making all of your products on your website accessible if the user can’t easily navigate to the cart to make the purchase.
A developer can make sure all of the correct attributes, roles and alt tags are added and thought of for different programming languages. A good example is debating whether or not an image is truly informative or decorative. Every image needs to be discussed this way by all parties in the 3 amigo session. If an image is agreed to be informative, what are the right words to really convey the meaning of the image that we can add in the alt tag?
A QA can look at it from several users' POVs and help to cover even more inclusive scenarios. This list is not exhaustive. It will be rare that we create something for just one set of people, for example the hearing impaired, because that person could also have mobility problems.
We also have to take into account that not all disabilities will be permanent, some may be temporary like broken fingers, or situational like wanting to watch a video in public without headphones or speakers so captions will be invaluable to them even though they do not have a hearing impairment. Accessibility is about really thinking about people, a wide variety of people, and how we can make lives a little easier, just by having more inclusive software.
These conversations should open up not only about the physical content and how it is presented to the user but also have wider conversations about the nuances of inclusivity for each aspect of what is being developed.
Being inclusive is not a checklist, it’s taking every element of what we are developing and asking ourselves: can this be used by ALL of the relevant senses?
In other words, would it get the seal of approval from our ‘4th amigo’?
