Any serious effort towards Privacy or WCAG / ADA compliance should be an ongoing process. Both laws and guidelines might change, but even more frequent and disruptive are website changes, or some aspects of your website that directly affect compliance efforts.
In the case of Complianz, we are continuously working on compliance with WCAG and Privacy. Sometimes these guidelines intersect, leading to simultaneous interpretation by our users, developers, and experts and different outcomes. We have an example below.
There’s also a matter of growth in commercial offerings regarding WCAG services, including website scans. These scans rely on different technical methods and compile their findings so differently that the reporting outcome is not only commercially driven but unclear about the appropriate actions. An example below is how this could confuse customers and developers.
Lastly, and most importantly – an ongoing process means we’re open to suggestions and pull requests but offer a way for anyone to edit CSS and HTML to comply with your or your favorite WCAG / ADA compliance tooling standards with a simple MU plugin. A quick guide to get started is also below.
Interpretation: Which button gets the first focus?
We received comments and subsequent pull requests to change the first focusable button in the banner to ‘Accept’ as an appropriate button instead of the ‘x’ or Close Dialog option. This was made by a compliance professional, and the reasoning was that the first focusable element should be action. As the ‘x’ dialog is not a proper button and only relies on ‘role=button’ as an attribute (which is a discussion itself), the logical hierarchal follow-up would be the ‘Accept’ button.
However, there are approaches for WCAG, but definitely in Privacy as well, to look at which button might be the most ‘destructive’ and should not be considered a first focus. This would be the ‘accept’ button. It would fully consent to all categories before the focus switches to the information or dismissal of consent.
This brings you to a slippery slope where hierarchy in decision-making is forced upon the user by relaying focus in a dialog. With this in mind, we default to the first ‘button’ in the dialog; after that, pressed by enter or spacebar (by accident or purposeful), the state of the website will not change as it only closes a dialog; it doesn’t change the current consent status.
This conclusion was also reached by the intersection of privacy guidelines, whereby a dismissable dialog and continuing without consent should be easy and with minimal disturbance. This applies to any website visitor.
Website scans: An example of missed dynamic properties
We also use a website scan for quick reference called; WAVE Web Accessibility Evaluation Tools. But it is and will always be a reference point, as a scan will not be able to understand the technical approach, variability, or interpretive choices based on Privacy, for example.
Most (commercial) website scans we see, or when confronted with by customers, lack a contextual approach to technical choices made by the developer and will look at static HTML without dynamic elements and throw warnings on aria-labels without understanding the element or HTML property.
Example: Improper use of links
An error seen in a website scan is “Improper use of links” whereby our link below is an example. This link is improper but static and will be adjusted with javascript based on the consent settings needed for the website visitor. We cannot change our HTML loaded in the page source if we need to adapt it on the client side. Therefore, the errors shown in the image below are not errors but missing any context to the HTML scanned.
<a class=”cmplz-link cmplz-manage-vendors tcf cookie-statement” href=”#” data-relative_url=”#cmplz-tcf-wrapper”>Manage vendors</a>
In most cases, this link is not visible to website visitors, and in this test case, this link wouldn’t be accessible by the mere logic of not being available.
Example: Aria-hidden=”true”
An SVG can have an aria-hidden=”true” if the image has no additional meaning to the context where it is displayed. As this context is not parsed or understood by a scan, any attribute that needs context will get a ‘warning’ label by default.
These simplified WCAG / ADA scans are built for reference but mostly to push users to commercial offerings to ‘solve’ their ‘issue.’
The issues could not be solved programmatically in this case, only by understanding the context and use case.
DIY: How to edit the banner HTML for WCAG / ADA
If you suggest anything we could change for better WCAG improvement, that works in conjunction with Privacy here. Then we would be happy to adjust where necessary, as fast as possible.
If you’re willing to offer a pull request or want to speed up the process, you can always edit our banner HTML and CSS for your needs.
We have written an article with a couple of options on how to proceed; https://complianz.io/create-your-own-banner-from-scratch/
