Third parties – we all use them – from cookie consents to chats, from Customer Relationship Management (CRM) systems to contact forms and maps. Sometimes just a tiny pixel tracker or a tag manager that lives in an iframe. So – basically every part of our app or webpage that’s not totally under our control.
As an app or webpage owner we are responsible that those third party elements are also accessible. There is no excuses. It’s our responsibility and sometimes it’s unfortunately not an easy task.
Don’t trust – verify before you use / buy
I’ve recently stumbled upon a third party plugin that was immediately flagged with some critical ARIA problems in my favorite automatic testing tool aXeSia. After checking the code out for myself they were using ARIA role of menu but didn’t take care of the needed children semantics. Quite a major barrier for screen-reader users and totally “invisible” for users that can see the screen. It was not a part of the basic chat functionality, but it was a part of help and privacy, so I guess somebody could argue that it was not so important to majority of end users.
Nevertheless – it was not conformant to WCAG 2.1 on level AA and therefore my customer’s site was not conformant as well.
I checked if they offered some info about accessibility and discovered that they actually made an accessibility statement or Voluntary Product Accessibility Template (VPAT). That was a nice surprise although it was also a disappointment, because they claimed that they are totally conforming to WCAG 2.1 on levels A and AA and even on AAA. They went even further and claimed that they are also conforming to WCAG 2.2 on level AAA (with a note that at the time of audit WCAG 2.2 was still a draft, which was fair enough).
So what is my problem? Well if I didn’t check them and blindly believed their latest accessibility statement I would be convinced that I am using a third party chat that has top notch accessibility built in. I am afraid that many customers of theirs don’t check if they really are so accessible as they claim to be and are just happy to check that checkbox (if they even care about it).
So – please – don’t trust, check. It’s the only possibility. And it’s also a fact that we have to check regularly as things change and sometimes break. I am sure that they invested some time and fixed the issues and I may even believe that they were totally conforming to WCAG on AA, but then somebody introduced a change a day after the audit and introduced at least one fail of WCAG (that fails the whole thing).
A product can be totally accessible and conformant to WCAG on the day before we publish our accessibility statement and then next release breaks a thing and we are not conforming anymore, but our statement still says we do.
My reflection on static nature of accessibility statements in this agile and dynamic world
So – once again – verify before you use and/or buy, but also verify when they do their upgrades. They should do it by themselves but it’s easy to have a stale accessibility statement and break something versions ago. So please be cautious and don’t believe – check.
