ATAG: when having typed an all-caps word, CKEditor should ask the user whether it's an acronym or abbreviation and accept a definition

1. This can not live in the filter system, because the filter system cannot do any prompting.
2. Which means this would have to live in CKEditor.
3. But doing this in CKEditor means creating a GPL-licensed dictionary in many languages.

I don't see how this is doable in core. Would need to be at least experimented with/matured in contrib first.

Actually, this would be better solved using a filter that contains a list of all acronyms/abbreviations that you'd want to see explained. Then content editors wouldn't have to re-enter the same acronym/abbreviation explanations over and over again. Which also leads to better consistency.

Ideally, there would be a corresponding CKEditor plugin that detects acronyms/abbreviations and checks if they're not yet known, then asks the content editor to explain them, which would update the central list and then would cause all filtered text to have that acronym/abbreviation explained.

This clearly belongs in contrib though. There already is a D7 module for this: https://www.drupal.org/project/abbrfilter.

@mgifford Thanks for bumping this, I hadn't seen it before.

Note B3.1.1 "Checking Assistance" has varied ATAG priority, depending on which part of WCAG it it about. Now WCAG 3.1.4 Abbreviations is at level AAA, hence checking assistance for abbreviations is at ATAG level AAA. That means it's not crucial to our accessibility QA gate/goal at level AA, just nice to have though. The other parts of B3 all depend on whether a check has been provided or not - I think they would only apply to abbreviations if we actually provided a particular B3.1.1 check for abbreviations.

Automated and semi-automated checking could happen at various points in time - it doesn't have to be CKEditor that looks for potential abbreviations...

• In real time, while the user is typing content in the editor. This is a bit like the way a spell checker adds red underlines. Needs a JS solution like a CKEditor plugin.
• Nearly in real time, after saving content. E.g. save a node, server processes it in hook_node_update(), and sets a yellow warning message like "BBC looks like an acronym - consider using abbreviation markup".
• In periodic scans, e.g a cron job scans all published content, and stores reports for a content manager to review later.

I looked at Quail and aXe-core to see how they handled abbreviations. It doesn't seem like they do anything unless an ABBR tag is there already, and then assert they have an accessible text name (e.g. not just used for a CSS icon, say). They don't flag whenever a wherever a capitalized word is present, which is what @mgifford is suggesting here. Tenon.io doesn't address WCAG 3.1.4 Abbreviations yet - see What Tenon Tests.

For B2 "Authors are supported in producing accessible content", there is a D8 release of the CKEditor Abbreviation module. It seems to have similar functionality to the ABBR button sample code in the CKEditor SDK. I think this is something we could consider for core, but ideally it would be part of the default CKEditor build, instead of a custom plugin maintained by us. We could look at whether the contrib module is using the same code as the SDK sample.

Dictionary-based approaches are mostly of use in subject/domain-specific areas. It's not possible for a CMS framework, or even site-builders, to know how to pre-populate a dictionary. The best approach here would be to allow a content manager to maintain (or import) a dictionary, which is what the Abbreviations Filter module does. This belongs in contrib I think.