Finding failures is easy, sometimes all that we need to do is run an automatic tool and it will show many, mostly code oriented, failures. Sometimes also contrast failures. Manual testing an application and finding out that button is missing role and name is also an often failure. So we can establish that WCAG failure discovery is pretty simple. But what about remediation?
WCAG is technology-agnostic, but failure remediation often needs technology-specific suggestions
WCAG tries it’s best to be technology agnostic – to support web technologies, native mobile applications, documents and more. That’s great, because it can be applied to wide digital medium surfaces. Otherwise we would have to have different standards.
But on the other hand – when we want to fix failures we would prefer technology specific methods. Otherwise we need to interpret the suggestions and translate them to our technology.
The value of accessibility audit lies in it’s remediation suggestions, otherwise customers just get a list of failures they need to decipher. So audits should not just serve end customers with vague suggestions but should provide technology specific recipes that would be easy to act on.
I’ve detected that auditing native mobile apps will often produce suggestions that are not very easy to act on as they don’t count in the platform’s specifics. So ideally we would need at least basic knowledge about technical solutions that would make the app accessible and this means that we should learn enough of Android and iOS to provide proper solutions.
Otherwise end customers that receive the audit would need somebody else to translate the suggestions to the technical solutions needed in design, code and content.
