Add information re wcag.json

[iadawn]

@netlify /standards-guidelines/wcag/

[netlify[bot]]

✅ Deploy Preview for wai-website ready!

Name	Link
🔨 Latest commit	ab8d8250b9958200cb7cd73f1b1ea51228ed1f65
🔍 Latest deploy log	https://app.netlify.com/projects/wai-website/deploys/68d3af2887b1400008707a74
😎 Deploy Preview	https://deploy-preview-1287--wai-website.netlify.app/standards-guidelines/wcag/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[iadawn]

@shawna-slh Just one suggested change to your re-write.

Also wondering how to incorporate Ken's point: "being provided as-is or being subject to change". I can't think of anywhere else that we do this and I was never certain that it was something that we should worry about. However, if you think so then something might be warranted such like:

[shawna-slh]

@iadawn missing text after "However, if you think so then something might be warranted such like:"

[iadawn]

Ah.. sorry... I thought I had an idea to put something in.. but I ran out of thoughts! It might be just something simple as:

This is provided as-is and will change in line with the latest WCAG document and supporting techniques.

[kfranqueiro]

Ah.. sorry... I thought I had an idea to put something in.. but I ran out of thoughts! It might be just something simple as:

This is provided as-is and will change in line with the latest WCAG document and supporting techniques.

"in line with the latest WCAG document and supporting techniques" sounds like content changes only; it downplays any risk of the format ever needing to change, which does not alleviate my concern:

Thus my concern remains that publicizing this is making maintainability promises that might paint us into a corner later.

[shawna-slh]

re:

will change in line with the latest WCAG document and supporting techniques

I think the text in the current draft already covers it:

These JSON files are updated monthly.

re:

making maintainability promises that might paint us into a corner later

Won't we always want this for ourselves anyway? Are we making any promises of maintainability?

[shawna-slh]

ftr, I don't have an opinion on publicizing or not, and am open to getting more input before developing an opinion

[shawna-slh]

I'm taking this off my To Do list until the issues are addressed. Feel free to add me back when ready.

[kfranqueiro]

I have added a paragraph linking to the history of structural changes to wcag.json, which resolves my issue of indicating that the structure may undergo changes.

I still think the "Permission to use with attribution" section pertaining specifically to the JSON data is weird:

• It says to link to the TR doc or techniques pages, neither of which have any direct relation or link to the JSON format. Should we tell people to link to this heading on this page which explains it instead?
• "Do not change the content" might be worth clarifying to allow for pruning fields the consumer is not intending to use? I do this for its usage in our own repos as well, to reduce how much content needs to be committed

[remibetin]

"Do not change the content" might be worth clarifying to allow for pruning fields the consumer is not intending to use? I do this for its usage in our own repos as well, to reduce how much content needs to be committed

If we say the files are governed by the Document license, it's probably already covered?

To facilitate implementation of the technical specifications set forth in this document, anyone may prepare and distribute derivative works and portions of this document in software, in supporting materials accompanying software, and in documentation of software, PROVIDED that all such works include the notice below

[kfranqueiro]

Based on a WAI discussion today, I created a PR to make a separate README regarding the generated JSON in the WCAG repo: https://github.com/w3c/wcag/pull/4635. It contains almost the same content as this PR, with the following changes:

• I used a bulleted list to describe the content of the JSON
• I accepted Shawn's suggestion of ordering the 2.2 link first
• I added "in full or in part" to the "You may use this data" line to resolve my issue regarding lack of clarity around ability to prune unneeded fields/items

I think we also resolved my other question RE whether to link to the Recommendation/Techniques or directly to the information about the JSON file; I can see the point of the former, since it's ultimately the source material, as long as we have ways to find the latter.

If we're OK with that PR, it should become available at https://github.com/w3c/wcag/tree/main/11ty/json#readme once it's merged.

So now the question is what do we want to reduce the content to in this PR? I think Kevin was still +1 to it getting its own heading; Shawn was interested in reducing the content to a single sentence.

[remibetin]

I've updated the PR with a new proposal. Instead of a dedicated H2 section, I am proposing a dedicated H3 section in the "WCAG 3 and more information" section to take into account that this information has a more specific audience. I've introduced H3s for "WCAG 3" and "FAQ" to make this H2 section clearer. I've kept the sentence introducing what's in the JSON files, and added a link to the readme file in GitHub for more information.

I've considered adding this information to the WCAG 2.0, 2.1, 2.2 section, but Ken noted that this section is mainly about the differences between the versions.

An alternative could be to add this information to the WCAG 2 Documents page. It is currently framed as describing "supporting documents and supplemental guidance" so it does not exactly fit though. Please let me know if you would prefer that I explore this option.

[shawna-slh]

@remibetin please publish and make sure the link to the JSON info works. Thanks!