Software engineering teams as well as end users are equally informed lately on the need for WCAG compliance and what it takes to accomplish the same. However, while planning for a WCAG testing effort especially from a compliance standpoint it is best to keep a few things in mind and level set expectations of stakeholders and end users so they know the life cycle of what it takes for a signoff.
VPAT – Voluntary Product Accessibility Template is a very popular deliverable that maps to the requirements of Sec 508 and WCAG guidelines. This is a one that product teams, governance bodies and users have come to expect as a deliverable at the end of any accessibility compliance testing effort, especially WCAG compliance testing. However, the important aspect to keep in mind here is unless accessibility has already been engineered in, if this is the first time the team is taking on WCAG testing, there’s a high chance that there would be a lot of bugs and a VPAT will duly fail.
The good thing with VPAT is that it is not just a pass/fail set of clauses – it has three possible outcomes that the application can be rated on, including, “supports”, “does not support”, “supports with exceptions”. So, if there are issues the product team decides to live with, while a portion of the feature may support accessibility, the rest can be called out as “supports with exceptions”. Using this requires mature handling so that the overall report is not inundated with this outcome. The best way to plan for a WCAG compliance effort is to start with one round of testing. This should be followed by an engineering and product team triage of the defects/results from this first test effort. The triaged and agreed upon set of defects need to be fixed and regressed. It is at the end of the regression cycle that if all looks good, should the test team go ahead for a VPAT creation. At the core, this is quite similar to a regular test cycle, but since this is a non-functional attribute some teams may expect the VPAT compliance report to be generated even at the end of the first cycle. This is something the test team should push back on, unless accessibility has been strongly engineered in the product from the get go. In the ideal scenario, just as how quality is engineered upfront, if the teams can be educated on what it takes to implement accessibility and the same can be designed and developed upfront, then test can even sign off on a WCAG compliance testing effort at the end of one cycle. Until the efforts mature to reach this stage, an iterative cycle is needed for the WCAG testing and compliance sign off.