Discovery: Allow editors to easily produce accessible content from the CMS

[laflannery]

Background

In order to support an accessible front-end VA.gov experience, we need to make sure our editors are able to easily produce accessible content within the CMS.

Additional Context

This work will support ATAG 2.0 Part B: Support the production of accessible content

Acceptance Criteria

• Research & Identify areas within the CMS that consistently result in editor-produced accessibility errors
• Determine possible additions to the CMS to identify errors before they are published/introduced to the front-end website

[laflannery]

• Can we update/improve the inline guidance on link fields?
• Can we improve the link widget within the WYSIWWYG? Will CKEditor 5 provide any additional options for this?
• Dave and I have discussion editor training to assist with the heading violations issues and in my head I also envision including link creation in this training
  • Thismight actually be helpful for that training
• The KB has articles on link creation but I do not think the accessibility implications are prominent enough. We are already updating the KB so we just need to focus on the links sections when we get there.

[EWashb]

I think this would be the next step after we look through all the possibilities in SiteImprove

[laflannery]

I agree, and some small things we have done do apply to this (i.e. alt text, the discovery ticket we have to possibly improve the edit form for headings, etc.) but we can look at this more as a whole

[laflannery]

@EWashb I feel like I want to close this? I feel like all the other tickets we have in the backlog cover this - figuring out a way to handle headings, determining a pattern for phone numbers, SiteImprove Integration, Discovery into PDFs, etc. I don't think we need to very large and vague ticket when we have all those more specific, actionable ones. Thoughts?

[EWashb]

I agree @laflannery