Hiding colorpicker input from tab navigation

[blackbaud-conorwright]

Hid colorpicker input from tab navigation so that it can't be directly modified

Resolves: #1384

[codecov-io]

Codecov Report

Merging #1791 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #1791      +/-   ##
=========================================
+ Coverage   99.98%    100%   +0.01%     
=========================================
  Files         412     412              
  Lines        8610    8610              
  Branches     1271    1271              
=========================================
+ Hits         8609    8610       +1     
+ Misses          1       0       -1

Impacted Files	Coverage Δ
...modules/colorpicker/colorpicker-input.directive.ts	100% <100%> (+1%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 10c7905...afcc43d. Read the comment docs.

[Blackbaud-SteveBrush]

@Blackbaud-MattGregg This pull request, and #1788 could be in conflict with one another. If we cannot reach the native input element with a keyboard, will a screen reader be able to read out the input's aria-label? See: https://github.com/blackbaud/skyux2/pull/1788/files#diff-bd971b56c22172aefe158a92492c557cR137

[Blackbaud-MattGregg]

@Blackbaud-SteveBrush yes, that is an issue plus someone using a screenreader being able to understand this is an input field asking for color value input. They could also just type it in. It's pretty similar to our data/time pickers.
I'm not sure where the issue of someone being able to modify the input came from as it's not something called out in #1384. Is this problematic for some other reason?
It looks like the button to open the color picker now has visual focus indicated and the input field takes keyboard input but it's wonky or only takes 3 characters?
One suggestion for a different fix for this would be to use a readonly and aria-readonly attributes on the input field instead (both b/c I don't know browser/assistive tech support). This should restrict input and still allow it to be read out. It will still be in tab order and receive focus, but I think that would be fine. We'd just be restricting keyboard users to input using the picker modal and not being able to use the keyboard for direct input.

[blackbaud-conorwright]

@Blackbaud-MattGregg I believe the issue of someone not being allowed to modify the input field directly could have been a misunderstanding on my part. in #1384 the expected section says:

No visual indication occurs when on input element which can't take any direct input.`

Which I interpreted to mean that this field was expected to not be able to take any direct input.

[blackbaud-conorwright]

Instead of being hidden the input field is going to now be readonly