SC 3.3.7 Accessible Authentication & conflict with legal and contractual obligations

[KimberleeD]

On behalf of Thomson Reuters:

Thomson Reuters regularly handles very sensitive information. In addition, some of our customers and third-party content providers have very rigorous privacy and security standards. To that end, we have developed security protocols that involve registration and setting up customer-created usernames and passwords. At the present time, we could not support 3.3.7 Accessible Authentication without further research into customer requirements and security review and tests of options listed in the “Understanding Accessibility Authentication” document to ensure security standards are at least as secure as the protocols we have in place today. We recognize, value, and are committed to making our products accessible to everyone, but need to have the following concerns addressed before we can support this Success Criterion.

Our concerns are

1. The cost in dollars, resources, and time to investigate and potentially completely overhaul our security/authentication protocols.
2. Continuing to meet our customers’ requirements and expectations regarding security
3. Honoring contracts and licensing agreements with third-parties regarding security/authentication protocols.
4. Resolving conflicts between this Success Criterion and legal, contractual relationships with have with customers and content providers.

Our suggestion:
• Provide an exemption that enables us to honor legal and contractual obligations.

[alastc]

Hi @KimberleeD,

The criterion allows for:

• username and password, so long as password managers are not blocked.
• 2nd factor authentication, so long as there is a non-transcription method. E.g. WebauthN, a USB token like Yubikey, or in-app authentication such as the Microsoft authentication.

Could you outline any methods of authentication that would require change?

Also, the exemption route is really about when WCAG 2.2 is taken on. WCAG 2.0 is still valid, and many locals will be using 2.0 or 2.1 for many years. That is why the standard doesn't have any "until" clauses, because you don't have to take it on until you are ready.

[patrickhlauke]

you don't have to take it on until you are ready

noting though that this may not be entirely in a company's hands if actual hard legislation adopts/cross-references a particular version of WCAG as its measure for accessibility. in those cases, companies that must abide by that legislation have no choice but to be ready.

[alastc]

True, but generally that's measured in years. That the EU took up 2.1 so quickly was exceptional, and required co-ordination between the commission & W3C. I'm not aware of any regulators that are ready to jump on a subsequent version, and (for example) a Section 508 update is likely to be years away.

My main point is that any current contracts would be based on 2.0/2.1, so 2.2 does not impact that.

[bruce-usab]

My own perspective is that WCAG 2.x A/AA is documenting the bare minimum, defining the floor. What are the current best practices that industry (and everyone else) should be expected to do everywhere and all the time? It is only with the AAA SC that we get to veer into advocacy!

[alastc]

We've had reviews from representatives from Microsoft, Google & Adobe, and (although I can't access the google one yet) it looks like we can modify the SC to an acceptable point for them, at least so far.

I.e. I don't think we're running ahead of industry now, although it would have been for 2.1.

However, I am interested in hearing from @KimberleeD if they have different constraints.

[alastc]

Draft response for the group to discuss:

---

The group respects the need to maintain security, and for organisations to continue current contracts. In this case there are many commonly available options for meeting the SC, at both the large and the small end of the scale. The timeline on when companies take up a new version is not something under the groups control, but WCAG 2.0 and 2.1 remain valid specifications for organisations to use. Something our process does require is multiple implementations for SCs, which will be the case for this criterion as well.

[alastc]

Hi @KimberleeD,

The group met today and agreed the response above. If you do not consider it addressed please to re-open the issue.