Software-as-a-Service (SaaS) solutions are quite popular in these cloud-first times. Centrally (in the cloud) hosted subscription based software solutions span over whole spectrum of modern software – content management systems, online shopping, online banking, online insurance, even online design tools, low-code and no-code solutions of all kinds and so on. Concept is far from new and started in the 1960s with mainframe computers and when cloud hosting started to go mainstream so did all possible online services that can run in it.
As we (should) know – accessibility as a software solution is quite limited by its core. If you do not fall for the “single line of code makes you WCAG compliant” overlays (please don’t) then you probably did your own research and verified that automatic tools can only get us so far. About 30 to 40 percent of WCAG can currently be tested (!) automatically, and if we play with statistics we can say that about 50-60 percent of all common accessibility errors can be detected automatically (due to the fact that some errors occur less than others). I will again mention that automatic tools only detect failures (sometimes also falsely, so please beware), but they often can not tell that site is passing. So at the end of the day we really need to check everything manually to be certain.
Accessibility-as-a-Service must include manual, human based, testing
As mentioned earlier – automatic testing alone can only be used with human supervision. At least for now, before major players join their powers and really dedicate their resources to decipher contexts, intentions and content providers goals. So I really think that Accessibility-as-a-Service has to scope beyond software and has to include human services to be efficient.
I’ll try to brainstorm a bit and describe how I would do it without investigating how others are trying to do it already. Just my thoughts.
- Customer defines audit test – it can be all URLs that are in the sitemap or just top 1000 most popular sites from their analytics. Providers pricing will probably have this number as a factor, so customer will most certainly have to select a scope based on their budget.
- Automatic crawling and analysis takes place. Maybe as a single time event but to get it right it should be a continuous task.
- Analysis produces a report, ideally with priorities (based on end-user impact for sure) and at the same time the tool should group the problems that occur on same elements, to be able to provide error context – was it a single widget, part of template or maybe a third party dependency?
- Provider’s accessibility experts have a mandate to check the automatic results to first filter out any eventual false positives and then manually verify audit findings and if needed change priority. At the same time they provide also possible solutions. Depending on the pricing package selected they also conduct various manual tests. They can be based on WCAG evaluation methodology or simpler.
- People with disabilities check the pre-defined critical user journeys to detect usability and assistive technology support problems. This is then looped back to subject matter experts for them to provide relevant solution suggestions.
- Customer gets prioritized list of issues, provided together with solution recommendations and can import them directly into their product management tools like Jira or MS DevOps. When teams get them they can use some pre-defined time to consult with accessibility experts if needed but plan is that they have enough information to fix the problems and verify that they are really fixed.
- Provider is informed about task resolutions and can re-check the implementation to give a final confirmation or in case there are still issues return to re-auditing and improving the suggested solution recommendation.
I think that something like this would really make final product more accessible, but to be honest I think that this should be a fall-back solution when customers product is in production and has reached a point where it would not be feasible to recreate it.
Accessibility is cheaper when integrated from start to end
I’ve written about this concept before and I still think that is the best way to do it. Accessibility-as-a-Service should not come into product lifecycle at the end, it should not be a part of quality assurance loop after releases. It would make much more sense and it would be much more cost beneficial when it is integrated from the beginning – from wireframes and designs, before it even reaches code. Such service would be way better – as a proactive member of the team, not as a final check when everybody is nervous because of the product launches.
So the list that I brainstormed works only when doing accessibility at the end. Or when we have to check our products accessibility to create a statement or VPAT. When we start with accessibility at the start we save a lot of time and effort, so that the end product gets the accessibility integrated and not added-on.
It is never too late to start and I find Accessibility-as-a-Service that is present at the start way easier, cheaper and more effective as if we have to run it at the end.
