Anchor link plugin bugs/issues

[natebyerley]

Problem/Motivation

Issues discovered when testing this P/R: #3219

Describe the bug

• anchor links added using the CK editor add an <a> tag and append an id to the <a> element (rather than modifying the existing element (i.e. <p> or <h> tag
• anchor links added using the CK editor also add the following class="ck-anchor" to the <a> element, which doesn't appear to have the appropriate styles
• anchor links added using the CK editor appear red/underlined/hyperlinked on front end, and pointer cursor is not consistent with other links on site
• possible to add an anchor link to text that already has an anchor link
• possible to add multiple duplicate anchor links to a page (front end user will land on top-most anchor link element if there are multiple on a page)

To Reproduce

Examples:

https://212alpha1-azs-housing.pantheonsite.io/test#h2

https://212alpha1-azs-housing.pantheonsite.io/test#p

Inspecting the elements shows:

Proposed resolution

Style issues

• Inherit styles for class "ck-anchor"? This would allow uniquely styled anchor link text to remain styled with an anchor attached.
• Is it accessibility best practice to add id to an <a> element?

Duplicate anchor link issues

• This will likely be hard to fix/change. We may just need to let users know that each page should only have unique anchor links.
• Adding anchor links to text that already has anchor links in source might create confusion among users, but is easily revealed by viewing source. Again, this might best be addressed through documentation.

Expected behavior

• Adding an anchor link should not alter front-end style of anchor link text
• Add documentation that covers limitations of this feature (it does not verify if your anchor link is unique)

Additional context

Slack discussion:

https://uarizona.slack.com/archives/C9EDC2RDM/p1730752456244879

[danahertzberg]

@accesswatch did confirm the ID can be on any type of element. <a> is not required.

[bberndt-uaz]

I came across this issue with the CKEditor Anchor Link module:

• IDs are stripped from links

I confirmed that IDs could be added to <a> elements in 2.11 and that this is no longer possible with the main Quickstart branch. Since existing <a> elements with IDs could have those IDs deleted upon editing a page, we can consider this a regression with the potential for data loss. After discussion in the AZ Digital workshop today, we are proposing to revert our addition of the CKEditor Anchor Link module to Quickstart. Instead, we will create a new Quickstart issue with our requirements for an anchor links feature. We can also track the progress of the CKEditor Bookmarks initiative.

[bberndt-uaz]

Rather than creating a new issue about adding anchor link functionality to Quickstart, we have updated this existing issue:

• Add ability to create anchor links in text areas #3127

This issue (#3870) will remain to document what we have found with the current implementation in our 2.12 pre-release, which uses the CKEditor Anchor Link module. We are still proposing to revert our addition of this module to Quickstart.