Plan to strip IDs from rich text editors

[laflannery]

Description

Editors often copy/paste text or manually specify IDs in rich text editors which lead to issues like duplicate IDs occurring on a page - this is an accessibility error. Removing the ability for editors to add these IDs in Drupal 10/CKeditor 5 would greatly reduce the number of accessibility issues that editors are creating within their content.

However, this was originally done for a specific reason, to solve a specific need, therefore we need to confirm if this need is no longer valid and therefore we are able to remove this functionality.

Background: This was allowed originally because the FE had no means of assigning IDs during the build. Once the FE added that, existing IDs were left, and the functionality lives on.

Notes

• Possible folks to discuss with to determine if any use cases are still existing/relevant:
  • Steve Wirt (historical context)?
  • SWCAIA team
  • PO
• Risks to keep in mind when thinking through process and change management:
  • Broken links: Anchor links have historically been created using these IDs. If an link has been created using one of these manually added IDs instead of an auto-generated one, the link will break once the ID is stripped out.

Acceptance Criteria

• Discuss with stakeholders and determine if there are any current use cases for editors to manually add IDs into rich text editors
• Create change management plan to strip IDs from all rich text editors

[laflannery]

Notes from Meeting with Randi and Megan 5/3:

• They do not edit/add IDs in rich text editors manually
• They only touch IDs when there are issues with copy/pasting and accidental duplicate IDs are added and need to be manually removed
• When adding anchor links they add their content, then allow the FE to auto add IDs which they then use for their anchor links
• We still have an unrelated issue that we should keep in mind for the SWCAIA team of how we could surface broken anchor links (when/if header text changes,, the auto ID also changes. This results in possible broken anchor links that they have no way of tracking down)
• Result: From the standpoint of the SWCAIA team, there is no issue with moving forward and stripping IDs from rich text, this would actually be helpful to prevent ID issues, like duplicates, and would not change their current workflow at all.

[productmike]

@laflannery do you know of ways that we could measure the scale of this issue and therefore measure the impact the change has? Maybe something obvious like the number of duplicate pages and seeing how that trends over time, but not sure if there are other less obvious things to measure?

[laflannery]

@productmike I think there are a few things we are talking about here so to clarify I'll break them out:

• The accessibility issue of duplicate IDs

  • Currently there are no duplicate IDs because my daily scan is clean (as of 5/4)
  • These don't occur on any sort of regular basis as they are sort of randomly occurring as editors add and update their content.
  • I don't have exact stats on how many/how often these occur but looking at JIRA I believe there were 12 instances since Jan 2023 if that gives you an idea.
  • I order to determine success, that stripping IDs is going to solve this particular accessibility violation, I plan on using my daily scan: I expect that this violation will never be reported again for manageable content and if it does happen to be flagged in the report, it would be in the code or a template error.

• IDs in rich text editors

  • Not all IDs added in rich text editors results in duplicate IDs. So there are probably many many more IDs in rich text fields that will get stripped out when/if this update goes into effect
  • Stripping these particular ID shouldn't cause any issues* so I don't think it's worth trying to find out how many there are existing
  • *Unless they are being used in anchor links which brings us to the next bullet...

• IDs for anchor links

  • This is the main risk that we are potentially making worse if we were to go ahead and strip IDs.
  • We don't currently have any stats for how many IDs are being used in anchor links but if we could do this or did have these stats, I would imagine it might be the start of solving this issue of how can we surface where these are in order to find/fix broken ones.

Does this information help answer your question at all?

[laflannery]

I talked to @timcosgrove to think about the issue of broken anchor links that this update may worsen - while it most likely would not be a simple lift, it wouldn't be impossible to figure out a way to find and surface these in some type of report.

[laflannery]

Change Management information

IDs will no longer be allowed in rich text editors. This means that:

1. If editors copy and paste content from other sources (i.e. emails, word documents, other sections, etc.) into a rich text editor, any ID that may accidently be pasted in will be stripped from the source code and will not be saved in the content.
2. IDs will no longer be allowed to be purposefully, manually added to the source code of the rich text editors.

The front end process of the site build automatically adds IDs to header elements based on the text of the header. The process has guardrails in place to ensure all these IDs are unique. However, when IDs are manually added into rich text editors these are not part of the automatic ID process and it causes duplicate IDs, which is an accessibility error.

By stripping IDs from rich text editors and only allowing these to be added automatically, we can avoid duplicate IDs and allow editors to create better, more accessible content within the CMS.

This change will impact all CMS editors.

We are alerted of duplicate ID errors when they occur with the daily accessibility scan report. We will be able to define and measure success for this change using this same report when we see that this particular error is no longer reported in the scan results.

The change should not require any updates to existing Knowledge Base articles, training videos or CMS UI. It also should not require any new KB articles, training videos or CMS UI.

This change will not be tested with users before release.

This change will occur at the same time that the update to CKEditor 5 occurs.

There is an existing risk that should be thought through - currently we have no way of surfacing broken anchor links. The SWCAIA team only fixes these when they happen upon them and are at that point able to go fix them. The risk of this update is:

1. By removing the ability to manually manage IDs in rich text editors, we are increasing the scope of this existing issue to now include content within rich text fields
2. If we strip out all existing IDs, there is a chance that we are going to break* more existing anchors - still without a way to surface and fix these proactively.

*To clarify, these broken anchor links should still work to direct the user to the proper page but they will not direct the user to the specific section on that page any longer.

Next steps

@productmike I think the next steps could be to discuss with Erika to see how she feels about this given all the information and if we can move forward with this update when we move to CKeditor5 or if she feels the potential issue of the anchor links would be any sort of blocker. Thoughts?

[productmike]

@laflannery

So as I read through this, it sounds as though we may see the duplicate IDs maybe 2-3/mo on average. In that case, it's difficult to rationalize a recommendation to move this forward due to the broken link risk. Essentially, the tldr here is that to address those 2-3/mo duplicate IDs, we can either (a) quickly put a fix into that will likely increase non-reportable bad UX or (b) can spend a person-sprint (assumption based on unknowns until digging) on this work.

I'm going to recommend to Erika that we create two tickets to address: (1) stripping out ID in rich text and (2) reporting on broken anchor links - with #1 being dependent on #2 so we're not moving forward in the dark.

[laflannery]

Talked with @EWashb and we are going to go forward with removing IDs from ckeditor