Inclusion and Accessibility(a11y)
Along with Parimala Hariprasad, I was selected to co-present the workshop titled "Designing for Inclusiveness – Workshop on Accessibility" at EuroSTAR 2019.
I had, in the year 2015 attended EuroSTAR as a Test Lab Apprentice and had aspired to speak in any of the future events. Due to certain shortcomings, we both could not make it this year. So I am sharing a few points here as an introduction to learning accessibility(a11y).
Preparation for the workshop began by defining a11y, inclusion, and exclusion to ourselves.
We began learning about a11y by understanding the definition of inclusion and by identifying what is excluded when designing the software for a11y requirements. It was then, did I realize that there is no absolute inclusion and exclusion and that there is partial inclusion when addressing a11y requirements. In firms that don't only work on a11y, it is usually defined by referring to a context that we currently are in considering the project phase, planning, time and budget.
If you are not an exclusive a11y firm, then chances are that a11y features take a back seat until there is a whistleblower(in the form of a real user sometimes) who questions you about the missing feature. We need to know that at times it requires the whistleblower to get out of the complaint zone, one that they are accustomed to, to even start talking about non-adherence to the web accessibility guidelines.
My role as a tester:
We testers do the same work not out of self-interest but rightly so to protect the firm from being prosecuted for not following the a11y guidelines. When a tester logs a bug to address a11y issues, do not ask them to change or lower the priority to P4 or P5 by marking the bug as an 'aesthetic issue' cause it could cost you more than fixing it now and in this build.
Inclusion doesn't mean making an application or a device feature-rich for all the users but providing the necessary hardware tools and software features to those who may need different sets of tools to operate the same software.
If you have tried to use the TalkBack feature, screen readers, speech to text feature, or screen magnifiers as a user with no special needs then you realize how sensible a user needs to be to design and use these features.
Time and again a11y is misunderstood for turning the device, or app to the blind mode and calling it the solution. As many accessibility researchers share, a11y is not only for blind users and turning the phone to blind mode is not the solution for all types of users. Address a11y as a feature and not as an 'issue'. It is not an issue but a requirement and a feature implementation for real users and building for accessibility start by identifying the needs of a real user. Lest we forget, that user can be you after a certain time.
When designing and testing for accessibility as a designer, tester, or as a programmer we come across many hurdles including:
a) time because some even today think that a11y bugs are not P1 bugs but rather wait until it becomes Priority 1 bug, a11y is sometimes missed or not planned for in the
b) planning phase it is mainly missed in planning because of the
c) cost incurred but in actual is the 'budget' which is unplanned for addressing a11y.
To help understand what lack of access means to a real user, consider the analogy of a high-raised building with stairs and no elevator or no accessible entrance for wheelchair users. If these features are accounted for and considered right from the project planning phase, then the cost to implement the same becomes a part of the plan (time and budget allocation too). And most importantly we wouldn't need 'n' number of apps to perform the same function (but with this add-on feature) if we did account for it in the app.
Liaise with the product owner when you want to convey the need for change in design or a newly introduced feature.
Work first hand with the real users to first understand the problem, design the requirements, implement, when testing (User Acceptance Testing) and then release.
Do this before you kick off the a11y life cycle which needs to be built in parallel and built into the product plan.
I had, in the year 2015 attended EuroSTAR as a Test Lab Apprentice and had aspired to speak in any of the future events. Due to certain shortcomings, we both could not make it this year. So I am sharing a few points here as an introduction to learning accessibility(a11y).
Preparation for the workshop began by defining a11y, inclusion, and exclusion to ourselves.
We began learning about a11y by understanding the definition of inclusion and by identifying what is excluded when designing the software for a11y requirements. It was then, did I realize that there is no absolute inclusion and exclusion and that there is partial inclusion when addressing a11y requirements. In firms that don't only work on a11y, it is usually defined by referring to a context that we currently are in considering the project phase, planning, time and budget.
If you are not an exclusive a11y firm, then chances are that a11y features take a back seat until there is a whistleblower(in the form of a real user sometimes) who questions you about the missing feature. We need to know that at times it requires the whistleblower to get out of the complaint zone, one that they are accustomed to, to even start talking about non-adherence to the web accessibility guidelines.
My role as a tester:
We testers do the same work not out of self-interest but rightly so to protect the firm from being prosecuted for not following the a11y guidelines. When a tester logs a bug to address a11y issues, do not ask them to change or lower the priority to P4 or P5 by marking the bug as an 'aesthetic issue' cause it could cost you more than fixing it now and in this build.
Inclusion doesn't mean making an application or a device feature-rich for all the users but providing the necessary hardware tools and software features to those who may need different sets of tools to operate the same software.
If you have tried to use the TalkBack feature, screen readers, speech to text feature, or screen magnifiers as a user with no special needs then you realize how sensible a user needs to be to design and use these features.
Time and again a11y is misunderstood for turning the device, or app to the blind mode and calling it the solution. As many accessibility researchers share, a11y is not only for blind users and turning the phone to blind mode is not the solution for all types of users. Address a11y as a feature and not as an 'issue'. It is not an issue but a requirement and a feature implementation for real users and building for accessibility start by identifying the needs of a real user. Lest we forget, that user can be you after a certain time.
When designing and testing for accessibility as a designer, tester, or as a programmer we come across many hurdles including:
a) time because some even today think that a11y bugs are not P1 bugs but rather wait until it becomes Priority 1 bug, a11y is sometimes missed or not planned for in the
b) planning phase it is mainly missed in planning because of the
c) cost incurred but in actual is the 'budget' which is unplanned for addressing a11y.
To help understand what lack of access means to a real user, consider the analogy of a high-raised building with stairs and no elevator or no accessible entrance for wheelchair users. If these features are accounted for and considered right from the project planning phase, then the cost to implement the same becomes a part of the plan (time and budget allocation too). And most importantly we wouldn't need 'n' number of apps to perform the same function (but with this add-on feature) if we did account for it in the app.
The reusability of software seems improbable in this time for app developers and the onus to not rebuild but resue lies with the product owners.What can I do as a designer, tester, or a programmer? Who can help us cross these hurdles?
Liaise with the product owner when you want to convey the need for change in design or a newly introduced feature.
Work first hand with the real users to first understand the problem, design the requirements, implement, when testing (User Acceptance Testing) and then release.
Do this before you kick off the a11y life cycle which needs to be built in parallel and built into the product plan.
- Capture the deliverables for a11y in a living document.
- Work thoroughly on what is agreed and approved in the plan as a deliverable.
- Work on remarks and suggestions that are not approved and place them in the plan.
- Make a note of what is stalled to be implemented until a later date.
KNOW THIS
- State clearly what is the definition of 'Inclusion' in your terms at the start of a project and convey it to others to gain an understanding of other perspectives.
- Redefine the definition as and when needed.
- Allow real users to be with you when you test the feature, design.
- Capture this definition on inclusion in the Project Plan which is available for all in the team to read.
- Clearly, state the conditions that are excluded from the plan and the reason for the omission.
- If inclusion is partial, then state the same to be on the safer side with the implementation planned and signed-off.
- Join a11y groups and chat with a11y leaders from time to time to understand the new additions or omissions in recent times with respect to accessibility and accessibility guidelines.
- Become a contributor to a11y groups.
- Volunteer at a11y conferences to learn with the real users.
- Invite real users to join you when you talk about inclusion and exclusion wrt a11y.
Comments