Accessibility Testing backed by compliances such as Sec 508, ADA, WCAG 2.0 is on the rise – and it is on the rise for the right reasons – whether it be mandated by federal agencies or by the organization’s drive to becoming more inclusive, the awareness, appreciation and acceptance for accessibility is certainly welcoming to witness.
However, while accessibility can be re-engineered into an existing application, it is not always a straightforward fix. The fix may at times call for re-architecting the application (even for simple things like changing the color scheme to ensure color contrast ratios of the pages and images align with standards), impacting other quality attributes such as usability and user experience (for example the color contrast may be too bright for a normal sighted user, especially if the AAA standard of 7:1 ratios are implemented), performance etc.
As an organization you want to ensure you have struck the right balance across the varied aspects of being inclusive not just for the dis-abled, but also the normally abled, have not compromised on other core quality attributes and have taken care of mandates to ensure compliances both by government and to one’s own satisfaction and gauge. Such a dilemma is easier spelled out than implemented. However it is not impossible. What this calls for is a clear understanding amongst all stakeholders as to what their accessibility charter is, what goals they are trying to achieve and balance with other parameters at hand. The good thing is that the standards themselves offer a variable degree of adoption (e.g. A, AA, AAA for WCAG 2.0) – prepare an accessibility checklist or adoption graph and just as you would plan releases, plan for accessibility implementation of increasing scale over a period of time so the impact on other parameters is also not drastic. At the end of the day, it is important to accept that accessibility is not a standalone attribute. It is a conjunctional attribute that needs to co-exist with other parameters in the product development mix that should gradually get into the mainstream of core Sprint planning, rather than be an after-thought post product implementation. Until the organization moves into that level of maturity, it will need to be weighed against compliances, user experience and cost of quality, to ensure there is maximum coverage for accessibility with minimal adverse impact on other linked parameters. Brainstorming and buy in from stakeholders is the only way to make this happen so as to create a WIN:WIN situation for all.