RE: [Conformance] Third Party Draft Updated

I took the liberty to make an editorial pass on the wiki page.

Not only MUST we be careful with must and should, but also MAY (as in it could be possible, versus a requirements document giving optional permission).

I changed a couple MAYs to MIGHTs.  One stayed a MAY.  My other edits were more trivial than even that.

With regard to SHALL, please leave that word to the regulators.


From: Korn, Peter 
Sent: Friday, June 18, 2021 1:37 PM
To: Sajka, Janina <mailto:sajkaj@amazon.com>; mailto:public-silver@w3.org
Cc: mailto:janina@sajka.net
Subject: RE: [Conformance] Third Party Draft Updated

Colleagues,

I made a few mild edits, mostly at the typo level. 

Thanks, Peter.

I think all, or nearly all of our "musts" would be better as "shalls" (this is a change I have not made). There are two main reasons for this: 1) where we are talking about the start of each evaluation process (like doing an enumeration of third-party content), that's really only necessary when the content has accessibility issues - if I evaluate everything and there are no problems and it doesn't matter that it's third-party or not (see the language "the web content publisher must clearly identify each third party content category location (i.e. payment processing, shipping management, authentication, etc), and perform standard accessibility evaluation analysis for each"); 2) as we anticipate scoring this, that may mean that if the website author fails to do all of the enumerated things, their score would be lower, not that they would necessarily fail (see the language "then all of the following must be clearly indicated alongside the 3rd party content").

We had "should" until recently and then went to "shall." After I reviewed the current heartbeat and didn't find "shall" constructions," I moved to "must" with really no more thought than congruence with the containing document.

I believe RFC2119 supports both-though requires us to capitalize the word, which I didn't do!

Also, I think some of the four sub-steps of step two of third-party content are needlessly onerous.  As currently written:

2. Clearly identify: 
1. Whether the authoring environment for User Generated content is native to the claimant, or
2. Whether and which third party service is used to provide the authoring environment for User Generated content, or
3. Whether and which component libraries or Content Management Systems (CMS) are used to provide the authoring environment for User Generated content, or
4. Whether the content is submitted outside of an authoring environment (e.g., submitted via email).
It seems unnecessary to indicate whether the authoring environment comes from a third party service; simply indicate if it is the case (else presume it is native to the claimant). Similarly the question of the component libraries used for authoring third-party content feels inappropriate here, when we don't ask for this information for the rest of the site. Similarly for the case where content can be submitted outside of the authoring environment, I think something should be said only when that is the case, rather than stating every time that it is not the case when it is not the case.

I think there's an argument to be made both ways here, e.g. some clever e-librarian might publish listings of most cited platform tools meaning lists of most cited conforming and most cited nonconforming tools. That might be valuable to spur some competition to do better.

I do agree that WCAG 3 should be consistent throughout. At this point it's just an early draft option for consideration that's fairly easily discarded-or adopted more broadly.

I think what we see in the "Applying the proposal" section for use case B captures what we want the author to do. And in that example, as nothing is stated, we can assume that the authoring environment was developed by the claimant, and it doesn't matter whether third-party content management systems are used or not. Note that use of the third-party content management system that has accessibility errors is already covered elsewhere, and would be treated just like any other author provided inaccessible third-party content.
I noted that the example conformance statements are specifying less data than I'm accustomed to seeing when attempting to advance a specification from Candidate Recommendation (CR) to Proposed Recommendation (PR). It's, of course, far too early to worry about that, but I know we'll want to document very specific hardware, OS, browser, etc. versions when it comes time to claim we have documentation of two independent implementations of each normative requirement (the transition to PR). The reason is that the claim needs to be replicable.

Best,

Janina

Thanks

Peter


From: Sajka, Janina <mailto:sajkaj@amazon.com> 
Sent: Friday, June 18, 2021 7:55 AM
To: mailto:public-silver@w3.org
Cc: mailto:janina@sajka.net
Subject: [Conformance] Third Party Draft Updated


Colleagues:

I believe I've captured the edits we agreed during our teleconference of 17 June, namely:

. Added to the (introductory) Problem Statement to indicate our goals in this document up top;
. Added Wilco's language (and made a more definitive assertion) in the Editor's Note at the top of the Steps to Conform section;
. Added a phrase to the examples in the last step of User Generated to point to outcomes (rather than further enumerating types of content prompting).
Please provide additional edits and suggestions. I will monitor here over the next few days as we prepare for our presentation Tuesday.

For convenience our draft is at:

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FGL%2Ftask-forces%2Fsilver%2Fwiki%2FProposal_on_Third_Party_Content&data=04%7C01%7Cbailey%40access-board.gov%7Ce09ef451fd3a43bf3b0108d9328395dc%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637596363007161448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nIwMI0Mbzkf%2BSuiQBueFfzH59I5U6uy19Iq3KfbN2hM%3D&reserved=0

Best,

Janina



----------------------------------

Janina Sajka
Accessibility Standards Consultant
mailto:sajkaj@amazon.com

Received on Monday, 21 June 2021 17:53:56 UTC