OK let's break it down.
Rule 981173 is the rule that's causing the problem. It is flagging because
"Restricted SQL Character Anomaly Detection Alert - Total # of special
characters exceeded"
It even tells you the field that is the problem:
[data "Matched Data: ] found within ARGS_NAMES:field_cl_address[0][format]: field_cl_address[0][format]"]
The way this rule runs is by running a very long regular expression on each field and it checks for 4 or more special characters (including [ and ]). Fields with lots of special characters can indicate that someone is trying to get around basic checks that servers or software might do, by obfuscating a bad pay load or escaping characters.
For you however your field names include 2 [ characters and 2 ] characters, which equals the 4 special character limit and hence every request gets blocked. This rule, as it stands, is of no use to you to protect that form because of this.
The OWASP Common Rule Set (CRS) is a set of rules is a set of suggested rules, that will not suit every site and do need to be tuned before you should switch them on in blocking mode.
In version 3 of the CRS, rule 981173 was renumbered to rule 942430 (the rules were renumbered as part of the move to version 3 for reasons I won't go into here) and they increased the number of special characters which had to match from 4 to 12 to avoid false positives like this. To be honest if you are just installing the CRS for the first time then you should move to version 3 first as they did a LOT of work in making it easier to install and avoid false positives like this.
If you want to stay on version 2.9 for now then your choices are:
Stop using this rule by including the following config:
SecRuleRemoveById 981173
Stop checking this particular field by including the following config:
SecRuleUpdateTargetById 959071 !ARG_NAMES:'field_cl_address[0][format]'
Manually edit the rule to change the {4,} it to {12,} so you need many more matches before this rule fires. Usually editing the rules directly is not recommended and instead it's better to have an override conf file, and use that to alter the rules - like in the first two examples. Unfortunately there is no way to alter a rule ids regular expression so manually editing is the only option (or turn that rule on, and copy it to a new rule with the tweaks in your override config).
It may seem odd at first to turn OFF rules, but that is exactly what fine tuning the rule set in ModSecurity means - turning off those rules that are not useful for you, or tweaking them not to fire on certain known fields. Does it reduce the security offered by ModSecurity and the CRS? Yes a bit, but a totally secure site that doesn't work isn't that useful, and some modificiations of the CRS (and in particular the SQL Injection rules) is needed for all but the simplest sites.
Rule 981173 is a rule I usually turn off completely because it's so prone to false positives. I wrote this post a while ago about other common tweaks I make to stop CRS 2.9 overly blocking:
https://stackoverflow.com/questions/33989273/modsecurity-excessive-false-positives#answer-34027786
Finally, I really recommend the ModSecurity Handbook (recently updated to second edition) to learn more about how this all works: https://www.feistyduck.com/books/modsecurity-handbook/
